[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Wednesday, September 5, 2012, 1:41:25 PM, you wrote:

>>>> On 05.09.12 at 12:48, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:

>> Wednesday, September 5, 2012, 12:40:31 PM, you 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?
>> 
>> Nope this machine is running without any keyboard/mouse, the USB controller 
>> at present has only one device connected to it:
>> in the pv guest lsusb:
>> Bus 007 Device 002: ID 10cf:5500 Velleman Components, Inc. 8055 Experiment 
>> Interface Board (address=0)

> And this is not by chance hanging off the controller that the fault
> was reported for?

Yes but i also get faults for the 07:00.0 later on booting.

>> And as i said, the hardware didn't change between my switch from xen-4.1.3 
>> to xen-4.2.

> I understand that, but the problem here showed up only after
> toggling the page table sharing option iirc.

You mean that the fault occurring this early during boot, only happened after 
enabling the "iommu=no-sharept" ?
That's correct although it's not clear if that is coincidence or not.

> Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.