Re: Potential source of interrupt aliasing

Matthew Dillon wrote:
>     Sheesh Scott, you don't have to be nasty about it.  I'm just trying to
>     help.  I've seen billions of interrupt routing related problems but
>     not one interrupt aliasing issue.

Yes, uncalled for, please accept my apologies.  Definitely a case of 
hitting the Send button too soon.

> 
>     What I/O APIC chipset and stepping does Doug have on that motherboard?
>     Intel has a ton of errata for their I/O APICs.  I see a mention of
>     having to turn off earlier revs of the chip and revert to legacy 
>     'boot interrupt' operation, but that's the only mention I see,
>     and it's only for old versions (< B-0 stepping) of the 80332.  
> 
>     Still, perhaps the BIOS is doing this even with later revs of the chip
>     in the MB.

This is the motherboard chipset, mainly i7501, 7520, and 440GX (not so 
sure on the last one since that doesn't involve hardware I own).  The 
7520 documents a register to turn off the 'boot interrupt' routing, but
the 7501 doesn't.  Since it might be a more general problem, we want to
figure out a general way to handle it.  It only happens on FreeBSD 
5.x/6.x with the full IOAPIC handling (there are 3 IOAPICs on the 7501 
and 7520).  4.x (and presumably DFly) doesn't see it because it doesn't 
enable more than the first IOAPIC.  In fact, what allows routing to
work at all on 4.x is that the interrupts on the second and third APICs
are masked by default in the IOAPIC and magically re-routed to irq16 on
the first via this 'boot interrupt' feature.  I have no idea how this 
applies to non-Intel chipsets with more than one IOAPIC, like the 
ServerWorks GC series.  It doesn't appear to be a problem on Opteron
chipsets, but that might be a whole different ball of wax.

An interesting datapoint is that Linux RH9 and FC2 don't seem to have
any aliasing issues on the same exact hardware.  Or, maybe they lie
very well about it.  So either they know the secret handshake with the
chipset, or they don't mask at the APIC while the interrupt is being
serviced (which is very hard for FreeBSD to emulate because interrupts
are handled in ithreads).  Just to review, the sequence of events:

- ahd fires irq50
- low-level handler runs
   - vector decoded
   - ahd ithread scheduled
   - EOI
   - write the mask to the APIC for irq50
- source is masked, boot interrupt feature activated in chipset
- irq50 remains asserted, so is aliased to irq16 (uhci)
- low-level handler runs
   - vector decoded
   - uhci ithread scheduled
   - EOI
   - write the mask to the APIC for irq16
-- time passes --
- ahd ithread runs
   - quench ahd hardware
   - irq50 de-asserted
   - irq16 also de-asserted by association
   - ithread completes
   - irq50 unmasked in the APIC
-- time passes --
- uhci ithread runs
   - nothing to quench
   - ithread completes
   - irq16 unmasked in the APIC
- repeat
> 
>     There's a reference to the '80332 I/O Processor' developers manual which
>     implies a more detailed explanation of 'boot interrupt' operation.

Since the 80331 and 80332 include a PCI bridge, it wouldn't surprise me 
that there is a similar mechanism at work in them.  But again, we are 
only talking about Intel motherboard chipsets here, not IOPs.

Scott