: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>Received on Thu Nov 24 2005 - 04:32:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:48 UTC