In message <200010171625.JAA27508@Pescadero.DSG.Stanford.EDU>,
Jonathan Stone writes:


>>Usually, sc->sc_enabled and IFF_RUNNING almost syncs, so the problem
>>won't appear unless interrupts aren't shared.
>
>Yep.  I ran into this on a laptop.  After running the PCIbios fixups,
>*all* PCI devices are on irq9.  USB speakers generate an interrupt on
>irq9 every 20 msec.  So 50 times a second, any enabled interrupt
>fuction would be called; that includes the pccard slots.  That gives
>good opportunity for triggering race conditions with shared interrupt.
>
>
>>By the way, with wi driver, when IFF_RUNNING is set while sc_enabled
>>is false?  I believe IFF_RUNNING isn't set unless device is enabled.
>
>The initial patch i tested just checked sc_enabled;
>it seemed safer to just leave that check in.

Oops... something I forgot to mention is the other drivers for pc-card
NICs interrupt routines dont check for IFF_RUNNING.  Both
sys/dev/ic/dp8390.c:dp8390intr() and sys/dev/ic/elink3:epintr() check
for DVF_ACTIVE and a device-softc "enabled" flag, but not IFF_RUNNING.

I think both have a race: when sharing an already-busy interrupt, the
pc-card can power the card up, but not set IFF_RUNNING; and a
subsequent interrupt will result in the interrupt-hanlder frobbing
card registers before it should (sc_enabled set, but IFF_RUNNING not set).