Re: [Xen-devel] pci-passthrough not working on 4.0.1-rc1-pre: mm.c:3847:d10 Bad page 00000000001beab4: ed=ffff830151210000(10), sd=ffff830151210000, caf=8000000000000002, taf=7400000000000001

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

For the fun of it, with the 2.6.33 and pvgrub
with kernel line iommu=soft of iommu=1 it fails to boot (no output from a 
kernel booting)
with kernel line iommu=off .. it boots fine.

Does something in the regular kernel around the iommu stuff get run that early 
in the boot that if it fails it doesn't give output, and could that be 
triggered by the handing over from mini-os to the actual kernel ?


Wednesday, April 21, 2010, 5:02:02 PM, you wrote:

> On Wed, Apr 21, 2010 at 03:58:29PM +0200, Sander Eikelenboom wrote:
>> Hi Konrad,
>> 
>> Only tested it today, but the 2.6.33 kernel i used from your tree a couple 
>> of weeks ago also gives the bad page in xm dmesg.

> This is with the new Xen version (4.1) or the older one? Can you send me
> your guest config file? What happens if you don't use pv-grub and
> instead plunk the kernel and initrd straight from the guest and
> set it them to 'kernel=blah' and 'initrd=blah2'

>> The domU doesn't even boot, on console it reports the things below in this 
>> case it seems to go wrong on domain creation allready.
>> I think port 5 refers to pci device 5 i'm trying to passthrough, without the 
>> pci=['0000:05:00.0'] line the domain boots fine.

> There  is  a bug in the pv-grub (or py-grub?) where extra
> arguments (such as iommu=soft) choke the loader. Somebody else saw this
> some time ago and as a work-around referenced the kernel and initrm
> directly. 

>> 
>>   Booting 'Debian GNU/Linux, vmlinuz-2.6.33'
>> 
>> lock
>> root            (hd1)
>>  Filesystem type is ext2fs, using whole disk
>> kernel          /boot/vmlinuz-2.6.33 root=/dev/xvda2 ro iommu=soft 
>> swiotlb=forc
>> e
>> initrd          /boot/initrd.img-2.6.33
>> 
>> close blk: backend=/local/domain/0/backend/vbd/21/51713 node=device/vbd/51713
>> close blk: backend=/local/domain/0/backend/vbd/21/51714 node=device/vbd/51714
>> port 5 still bound!
>> 
>> 
>> in xm dmesg:
>> (XEN) mm.c:3847:d21 Bad page 000000000013ea83: ed=ffff8301f3a70000(21), 
>> sd=ffff8301f3a70000, caf=8000000000000002, taf=7400000000000001
>> (XEN) mm.c:3847:d21 Bad page 000000000013ea83: ed=ffff8301f3a70000(21), 
>> sd=ffff8301f3a70000, caf=8000000000000002, taf=7400000000000001
>> (XEN) mm.c:3847:d21 Bad page 000000000013ea83: ed=ffff8301f3a70000(21), 
>> sd=ffff8301f3a70000, caf=8000000000000002, taf=7400000000000001
>> (XEN) mm.c:3847:d21 Bad page 000000000013ea83: ed=ffff8301f3a70000(21), 
>> sd=ffff8301f3a70000, caf=8000000000000002, taf=7400000000000001
>> (XEN) mm.c:3847:d21 Bad page 000000000013ea83: ed=ffff8301f3a70000(21), 
>> sd=ffff8301f3a70000, caf=8000000000000002, taf=7400000000000001
>> (XEN) mm.c:3847:d21 Bad page 000000000013ea83: ed=ffff8301f3a70000(21), 
>> sd=ffff8301f3a70000, caf=8000000000000002, taf=7400000000000001
>> 



-- 
Best regards,
 Sander                            mailto:linux@xxxxxxxxxxxxxx


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel