Garrett D'Amore wrote: > Randy Fishel wrote: >>> Yes, I understand this scenario. But I was thinking more about the race >>> condition, when the driver is *being* suspended, the hardware generates >>> interrupt before interrupt generation is disabled and the driver >>> interrupt routine was not called yet. >>> Such window may be very small, but I would think it is possible. >>> Rejecting such interrupt with DDI_INTR_UNCLAIMED would cause continuous >>> interrupt calls. >>> >>> -Pawel >>> >> This is an interesting question, would this actually occur. Or put >> another way, if I have a broken (or maybe not broken) driver that >> returns a DDI_INTR_UNCLAIMED even though it should/could have >> processed the interrupt. Will it continue to be called, till it (or >> some other isr) claims the interrupt? Or will it just be tossed? >> > > It gets tossed as a "spurious" interrupt.
I don't think this works this way much on Sx86, these days anyway. Yes, multiple interrupts can arrive, but unless the EOI has been sent and the possibly-level source deasserted, they'll be hidden behind the active one... and... > This happens normally with a > lot of NIC drivers, for example. Servicing multiple interrupt sources > without waiting for the actual interrupt to arrive is a common > practice. (Think of an rx routine that detects the interrupt, starts > processing, and then a second packet is received. The interrupt for the > second packet will arrive only after the RX routine has already > processed it.) > > But if the device still has the interrupt source asserted, then things > get very very bad. ....this results in most of the "false UNCLAIMED" cases. > On certain SPARC hardware this condition is detected, and the interrupt > source is killed off, but I think on x86 the system basically locks up > (well, that cpu anyway) processing an infinite stream of interrupts. Right. We've discussed some attempt at heuristic for diagnosing this condition and turning off the interrupt, but it's tricky, as you might imagine, and hard to figure out what to do when the interrupt is shared with a device that is still in working order. _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
