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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.09.12 at 09:08, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
>> This one
> 
>>>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> 
> ffff82c480224b13
> 
>> also worries me. While Xen gracefully recovers from it, these
>> messages still generally indicate a problem somewhere. Could
>> you resolve the addresses to file:line tuples? And, assuming
>> this happens in the context of doing something on behalf of
>> the guest in the context of a guest vCPU, could you also
>> check what guest side action triggers this (e.g. by adding a
>> call to show_execution_state() alongside the printing of the
>> message)?
> 
> Hope i have done it right:

Yes.

> Gives (complete dmesg attached:
> 
> (XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 
> 0x0700, fault address = 0xa8ee82c0
> (XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 
> 0x0700, fault address = 0xa8ee8320
> (XEN) [2012-09-04 03:00:34] traps.c:3156: GPF (0060): ffff82c48015c9ee -> 
> ffff82c480224b73
> (XEN) [2012-09-04 03:00:34] traps.c:3157:  show_execution_state(regs): 
> (XEN) [2012-09-04 03:00:34] ----[ Xen-4.2.0-rc4-pre  x86_64  debug=y  Not 
> tainted ]----
> (XEN) [2012-09-04 03:00:34] CPU:    3
> (XEN) [2012-09-04 03:00:34] RIP:    e008:[<ffff82c48015c9ee>] 
> context_switch+0x394/0xeeb

Now that - in the middle of context switch code - almost certainly
wants to be fixed, but we first need to understand what it is (and
how it gets triggered by the guest). I.e. once again this requires
resolving to file/line - care to do the conversion yourself, or send
(or make available somewhere) the very xen-syms?

Jan


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