em interrupt storm
dillon at apollo.backplane.com
Thu Nov 24 05:32:00 GMT 2005
: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.
<dillon at backplane.com>
More information about the freebsd-net