Re: [Xen-devel] IO-APIC interrupts getting stuck

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Roger Pau MonnÃ<roger.pau@xxxxxxxxxx> 12/22/14 7:44 PM >>>
>OK, this was misleading. The ASSERT I've added triggers on Linux also
>but it doesn't lead to the irr=1 mask=0 blocked state, so I think
>returning from end_level_ioapic_irq_new with irr=1 and mask=0 is a valid
>state, is this right?

Afaict this is not an invalid state at that point, i.e. if another IRQ arrived
quickly.

>I've also tested with the following patch applied:
>
>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01816.html
>
>To make sure FreeBSD was not playing tricks behind Xen's back, and
>AFAICT FreeBSD is not touching the IO APIC at all. Also Xen doesn't show
>any pending EOI timers ('a' debug key).

Good - at least one less possibility to worry about.

>> And you're also apparently not seeing this on a system where
>> Linux'es IO-APIC re-route workaround might come into play (see
>> drivers/pci/quirks.c:quirk_reroute_to_boot_interrupts_intel()),
>> which then I would have suspected FreeBSD to not have such a
>> workaround...
>
>No, the same box I have with Linux doesn't use the IO-APIC re-route
>quirk. I've also tested this on different hardware and when using
>FreeBSD with the new IO APIC Ack method I always end up in this stuck
>state, so I don't think it's a hardware errata/issue.

Understood. I'm afraid there's not much we can do here without you gathering
more data - one particularly useful thing would be kind of a trace of states for
the first respective IRQ delivery inside Xen, allowing to then compare the
progress with PVH Linux and FreeBSD. There must be a difference after all.

Jan


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