| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH][FIX] Possible fix for spurious interrupts
>Arun Sharma pointed out its the same problem that FreeBSD has been
>having (they also mask interrupt lines when the ISR is scheduled in an
>interrupt thread). The problem is caused *by design* on many chipsets
>-- the idea is that if the bootloader or OS does not know about ACPI
>and cannot find the IO-APICs then interrupt lines routed to those
>IO-APICs should have their interrupt fired on a legacy line (it so
>happens that this usually is also the line used by the USB
>controllers). They detect this by seeing if the IO-APIC RTE is masked.
>Many chipsets have no way to disable this mode of operation (no need
>for Linux and Windows -- when they detect and enable IO-APICs, they
>never mask active RTEs). So, basically, we're screwed and have to work
>around by delaying the EOI.
Hmm, I read that mail, but it seemed to indicate that this would affect only a
single line. We had been seeing this on
multiple lines, however. Also, to me lines 16 and above aren't really 'legacy',
so the implication might rather be for
routing in systems with multiple IO-APICs where older software only finds one.
As this would then seem to be
deterministic, the question would be if there is a way to know which IO-APIC
triggers which line (this must be possible,
or else the 'older software' wouldn't be able to know where the interrupts
arrive at the first IO-APIC), and use this
knowledge, or at least restrict the fix currently in use to all but the first
('legacy') IO-APIC (which should improve
things namely on single-IO-APIC systems).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home