Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine

[Wei Wang <wei.wang2@xxxxxxx>]

On 09/05/2012 12:40 PM, Jan Beulich wrote:
> > > > On 05.09.12 at 12:25, Sander Eikelenboom<linux@xxxxxxxxxxxxxx>  wrote:
> > Wednesday, September 5, 2012, 12:14:02 PM, you wrote:
> > > > > > On 04.09.12 at 18:43, Sander Eikelenboom<linux@xxxxxxxxxxxxxx>  wrote:
> > > > ...........................<0>AMD-Vi: IO_PAGE_FAULT: domain = 0, device id =
> > > > 0x0a06, fault address = 0xc2c2c2c0
> > > Looks like use of uninitialized memory (assuming you're using a
> > > debug hypervisor, that's the pattern scrub_one_page() puts
> > > there). But it's unclear to me what device should be doing any
> > > I/O at that point (and even if one does, how it would get the
> > > bad address loaded). What is 0a:00.6?
> > since 4.2-rc4 is still unstable it has debug=y for what i know, so yes.
> > This particular IO_PAGE_FAULT happened before the kernel loads, so the
> > kernel and pciback shouldn't be causing the issue one would say.
> > With pciback i'm hiding 03:06.0, 04:00.*, 05:00.0, 0a:00.* and 07:00.0 at
> > boot.
> >
> > Is there any code i could add to get more info where it comes from ?
> Hardly, since those accesses are asynchronous to what the CPUs
> do. But ...
>
> > 0a:00.6 USB controller: NetMos Technology MCS9990 PCIe to 4ÃPort USB 2.0 Host 
> > Controller
> ... are your keyboard/mouse perhaps connected to this one? In
> which case I'd suppose the 1:1 tables set up for Dom0 might not
> be complete. Wei?
I checked this on my machine using 'o' key and it has been mapped as a 
2MB frame see: gfn: 000c2c00  mfn: 000c2c00. But maybe I have no device 
access to this address... Another possibility is interrupt message. 4.1 
does not show IO_PAGE_FAULT for interrupts, but 4.2 does (changeset 
23199:dbd98ab2f87f). I will send a patch to dump flags from IO_PAGE_FAULT.
Thanks,
Wei

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel