Re: [Xen-devel] cpuidle and un-eoid interrupts at the local apic

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.08.13 at 11:28, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 12/08/13 09:20, Jan Beulich wrote:
>>>>> On 09.08.13 at 23:27, "Thimo E." <abc@xxxxxxxxxx> wrote:
>>> (XEN) **Pending EOI error
>>> (XEN)   irq 29, vector 0x24
>>> (XEN)   s[0] irq 29, vec 0x24, ready 0, ISR 00000001, TMR 00000000, IRR 
> 00000000
>>> (XEN) All LAPIC state:
>>> (XEN) [vector]      ISR      TMR      IRR
>>> (XEN) [1f:00] 00000000 00000000 00000000
>>> (XEN) [3f:20] 00000010 76efa12e 00000000
>>> (XEN) [5f:40] 00000000 e6f0f2fc 00000000
>>> (XEN) [7f:60] 00000000 32d096ca 00000000
>>> (XEN) [9f:80] 00000000 78fcf87a 00000000
>>> (XEN) [bf:a0] 00000000 f9b9fe4e 00000000
>>> (XEN) [df:c0] 00000000 ffdfe7ab 00000000
>>> (XEN) [ff:e0] 00000000 00000000 00000000
>>> (XEN) Peoi stack trace records:
>> Mind providing (a link to) the patch that was used here, so that
>> one can make sense of the printed information (and perhaps
>> also suggest adjustments to that debugging code)? Nothing I
>> was able to find on the list fully matches the output above...
> 
> Attached

Thanks. Actually, the second case he sent has an interesting
difference:

(XEN)   s[0] irq 29, vec 0x26, ready 0, ISR 00000001, TMR 00000000, IRR 00000001

i.e. we in fact have _three_ instance of the interrupt (two in-service,
and one request). I don't see an explanation for this other than
buggy hardware. Sadly we still don't know what device it is that is
behaving that way (including the confirmation that it's a non-
maskable MSI one).

Jan


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