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

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Andrew Cooper wrote on 2013-08-12:
> On 12/08/13 14:54, Thimo E wrote:
> 
> 
>       Hello Yang,
> 
>       and attached the next crash dump which occured today, only some
> minutes after I've created the logfiles I've sent in the mail just before.
>       Perhaps together with the logfiles of the former mail it gives you a
> better understand of what is going on.
> 
>       I've disabled Interrupt remapping now.
> 
>       > 4.....
>       > can you add some debug message in the guest EOI code path(like
> _irq_guest_eoi())) to track the EOI?
>       @Andrew: Is it possible for you to integrate the requested changes
> from Yang into your Xen debugging version ?
> 
> 
> 
> I already have.  That would be "Marked {foo} ready" debugging in the
> PEOI stack section.
I didn't find your debug patch that add PEOI stack tracing. Could you resend 
it? thanks.

> 
> ~Andrew
> 
> 
> 
> 
>       Best regards
>         Thimo
> 
>       Am 12.08.2013 10:49, schrieb Zhang, Yang Z:
> 
> 
>               Hi Thimo,
> 
>               From your previous experience and log, it shows:
> 
>               1.       The interrupt that triggers the issue is a MSI.
> 
>               2.       MSI are treated as edge-triggered interrupts nomally,
> except when there is no way to mask the device. In this case, your
> previous log indicates the device is unmaskable(What special device
> are you using?Modern PCI devcie should be maskable).
> 
>               3.       The IRQ 29 is belong to dom0, it seems it is not a HVM
> related issue.
> 
>               4.       The status of IRQ 29 is 10 which means the guest 
> already
> issues the EOI because the bit IRQ_GUEST_EOI_PENDING is cleared, so
> there should be no pending EOI in the EOI stack. If possible, can you
> add some debug message in the guest EOI code path(like _irq_guest_eoi())) to 
> track the EOI?
> 
>               5.       Both of the log show when the issue occured, most of 
> the
> other interrupts which owned by dom0 were in IRQ_MOVE_PENDING status.
> Is it a coincidence? Or it happened only on the special condition like
> heavy of IRQ migration?Perhaps you can disable irq balance in dom0 and
> pin the IRQ manually.
> 
>       |6.       I guess the interrupt remapping is enabled in your machine.
> Can you try to disable IR to see whether it still reproduceable?
> 
>               Also, please provide the whole Xen log.
> 
> 
> 
>               Best regards,
> 
>               Yang
> 
> 
>


Best regards,
Yang



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