[9fans] 386 interrupts

[9fans] 386 interrupts

[erik quanstrom]

i've been taking a careful look at interrupts recently
because i had a number of machines that just didn't
work.  that problem turned out not to be too hard,
and was easily fixed.  it turns out that one needs to
do a dance for lapic apic ids > 7.  (this code is already
in 9atom.)

along the way, i found that it was quite easy to turn
on msi interrupts, but that has not been as problem-free.
in case you're wondering why that would be interesting,
there are three problems with i/o apics: they're slow,
chained and error-prone[1].

while most devices/machines just work, there are a few that
just make the machine go nuts.  by go nuts, i mean
panic after taking a number of machine check interrupts.
wiring the interrupt to 1 ap fixes the problem.  and by
"fixes," i'm pretty sure i mean papers over.

here's what i think may be happening.  in trap(),
valid vectors are processed and then the eoi is processed.
after the eoi, a new trap may be taken before we exit
trap().  normally this isn't a problem since we're splhi().

unfortuantely there are a 3 places we spllo()
from trap().

- fault386 does this to handle page faults in line
(this might be a reason that swapping on x86 is not
reliable)

- if the vector is the clock handler and up->delaysched
is set

- notify to acquire the debug qlock().

so if you're keeping score at home, i think the reason
the machine "goes nuts" is that trap never returns.
it spllos and eventually calls sched().  i think this
comment in the notify/kexit case may be telling

		/* moderately dangerous; can stack arbitrarily */

clearly, if you believe intel, the reason this is much more likely
with msi interrupts is that they're faster, and don't require an
eoi cycle to the i/o apic to rearm the interrupt.

so is this analysis mistaken?  and if not, what to do about it?
wake a cleaner process that can run in non-trap context?

- erik

[1]
- you need to get a correct interrupt mapping for the
i/o apic to set up routing.  this is one extra step to go wrong.
- many bus interrupts map to the same output vector.  worse,
the bus irq table can't tell you which one belongs to your device.
- intel claims a 3?s advantage on atom machines.
(ftp://download.intel.com/design/intarch/PAPERS/321070.pdf)
due to cutting out the i/o apic from the interrupt path, and
elimiating the eoi message to the i/o apic.