Re: em interrupt storm

:You're seeing the same aliasing.  Here's exactly what happens:
:irq64 generates an interrupt and the APIC routes it to the CPU.
:FreeBSD services the interrupt, masks irq64 in the APIC, and schedules
:the interrupt thread for em2.  When that ithread runs, the driver
:will take action to turn off the interrupt at the card, and then
:irq64 will be unmasked when the ithread completes.  PCI interrupts are
:level driven, so they stay active until the driver tells the hardware to
:turn them off.  However, as soon as the interrupt get masked, the APIC
:re-routes the signal to irq16.  Since irq16 is an interrupt that freebsd
:cares about, it's enabled, so FreeBSD gets interrupted again.  It then
:masks irq16 and schedules the em0/uhci0 ithread.

    I'm a little confused as to what 'irq16' really means in this
    context.   Are we talking about pin 16 on the IOAPIC (i.e. the
    'irq16' cannot be distinguished from an interrupt on pin 16),
    or is it generating an actual BASE+16 vector to the LAPIC whenever
    some other pin is masked, or is it generating a fixed vector?

    It should be possible to work around the problem by using the trick
    that Linux uses, which is to 'mask' the IOAPIC interrupt by programming
    the pin from level to edge triggered (and then back to level triggered
    when the interrupt thread is finished with it), instead of masking
    the pin.  This trick can result in a double interrupt, but it will
    stop the continuous interrupts.

					-Matt
					Matthew Dillon 
					<dillon_at_backplane.com>