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. 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.
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.
-- Garrett
> ---- Randy
> _______________________________________________
> driver-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
