El 02/01/15 a les 17.20, Jan Beulich ha escrit: >>>> Roger Pau Monné<roger....@citrix.com> 12/22/14 7:44 PM >>> >> 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.
What I said above was not completely true, the other box I've used for testing was also a Nehalem with two IO-APICs. Now I've tested on a Nehalem (X3450) with a single IO-APIC and it works fine. I'm still not sure if this issue is limited to the Nehalem family with two IO-APICs, or if newer families also have the same issue if more than one IO-APIC is present. Switching to the "old" IO-APIC ack mode seems to solve the problem (or at least mitigate it). This is quite bad on those systems because as soon as one of the IO-APIC IRQs gets stuck everything starts falling apart and MSI interrupts also get stuck. Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
