It think that you might misunderstand the physical realities of interrupts
and the contracts that Windows puts on them.
If your device is a PCI device, it either uses level-triggered interrupts in
“legacy” mode by asserting line-based INTA# (or, in PCI-Express, this is
done equivalently through packet protocol.) Or you can use
“Message-Signaled Interrupts” where your device triggers an interrupt by
doing write transaction on the bus to an address supplied by the OS with
data also supplied by the OS. MSI (or MSI-X) use a protocol that amounts to
“latched” or “edge-triggered.” The symptom you describe can only really
occur if you are using legacy level-triggered interrupts.
Line based interrupts route through an interrupt controller, like an 8259
PIC or, more commonly, an I/O APIC. Each input on that interrupt controller
is called an IRQ, and it may be shared with lots of devices. Because the
signal is level-triggered, it must be de-asserted before the interrupt can
be cleared. If it is not de-asserted, the interrupt controller will just
interrupt the processor again after the End-Of-Interrupt causes the
controller to re-sample the input.
With PCI, the only sure way to de-assert a line-based interrupt* is to run
code from the driver for that device, which masks the signal at the device.
This code is called an “Interrupt Service Routine.” You supply it.
Now, if your driver calls IoDisconnectInterrupt[Ex] (or allows WDF to do
that on its behalf) it must guarantee that the device has masked all
interrupt sources, because your ISR will no longer be registered and it will
no longer have an opportunity to clear the interrupt from your device.
This is what has happened here. Your driver has torn down without masking
the interrupts from your device first. What you’re seeing is often referred
to as an “interrupt storm.”
–
Jake Oshins
former interrput guy
Windows Kernel Team
This post implies no warranties and confers no rights.
“Wayne Gong” wrote in message news:xxxxx@ntdev…
> Hi folks,
>
> I am developing a virtual scsi miniport driver. When I try to unplug a
> heave load device, I can get a notify in my scsi miniport driver that
> device need to remove. Then I call IoInvalidateDeviceRelations to notify
> my pci driver to remove the child PDO which my scsi miniport driver
> services. But before my pci driver receive IRP_MN_QUERY_DEVICE_RELATIONS
> IRP, my scsi miniport driver receive lots of interrupt. It seems that PnP
> manager has no time to send such IRP to my pci driver. First of all, as a
> virtual miniport driver, now I cannot get any properly approach to disable
> the virtual device interrupt. So I want to know is there any approach to
> notify scsi port driver not to send interrupt to my scsi miniport driver.
> Another problem is that why my pci driver cannot receive
> IRP_MN_QUERY_DEVICE_RELATIONS IRP when I call IoInvalidateDeviceRelations
> in my scsi miniport driver when it get a heave load. If such device
> doesn’t get heave load, my drivers works fine for unplug devices.
>
> Thanks
> Wayne
>