We have a proprietary PCIe board that runs a KMDF based driver that interrupts every 60ms when running.
After running overnight we detected that WdfInterruptQueueDpcForIsr, at the end of our ISR, returns false.
My interpretation of this is that the DPC queue/list already has a queued DPC for our PCIe device and the queue can only have one queued DPC per device?
Which leads me to the following question what can cause this to occur? The processing times for our interrupt and DPC are fairly quick and nowhere near 60ms.
Also what action should a driver take, if any, when WdfInterruptQueueDpcForIsr returns false?
Thank you.
It’s not an error, it is just as you suspect: the dpc is already queued. It has nothing specific to do with how long or short your isr duration is. Typically all this means is that your dpc routine hasn’t run yet. Note that your dpc routine cannot assume that the number of interrupt events = 1, it has to process all events (0 - infinity) that have occurred.
@Mark_Roddy said:
It’s not an error, it is just as you suspect: the dpc is already queued. It has nothing specific to do with how long or short your isr duration is. Typically all this means is that your dpc routine hasn’t run yet. Note that your dpc routine cannot assume that the number of interrupt events = 1, it has to process all events (0 - infinity) that have occurred.
Yes I can update the DPC to handle all interrupt events.
I agree it is not an error however why would it take so long (>60ms by the look of it) to start executing this devices DPC at the end of the interrupt?
Is it likely caused by the DPCs or ISRs of other devices hogging processor(s) time?
Is it likely caused by the DPCs or ISRs of other devices hogging processor(s) time?
No. It’s “just the way Windows works” – and it depends on how frequently your device interrupts.
As Mr. Roddy correctly explained, it simply means that your DpcForIsr hasn’t run yet. That’s not bad; That’s not good; That’s just the way it is. It’s not necessarily caused by anything else bad on the system.
Peter
@“Peter_Viscarola_(OSR)” said:
Is it likely caused by the DPCs or ISRs of other devices hogging processor(s) time?
No. It’s “just the way Windows works” – and it depends on how frequently your device interrupts.
As Mr. Roddy correctly explained, it simply means that your DpcForIsr hasn’t run yet. That’s not bad; That’s not good; That’s just the way it is. It’s not necessarily caused by anything else bad on the system.
Peter
Yeah thanks. Looks like we need a strategy to be able to cope with this scenario.