I had a BUG in the application.
In SendDeviceIoctl (line 92) , if the timeout is 0, rc=WAIT_TIMEOUT and the event is not inserted back to the pool.
After fixing it, I’m not getting STATUS_NO_MORE_ENTRIES from WdfIoQueueRetrieveNextRequest in IsrDpc.c
The cause to the miss:
The time from one interrupt to another is 20msec.
But the time required to process this event in the application can take more than 20msec.
Thank you very much for the detailed answers.
I really appreciate your help.
you do understand that you can certainly get this failure again even after you have fixed whatever bug you had. It is inherent in the nature of the system and you should have some kind of strategy to deal with it. many times, the strategy is simply ‘i need 4 buffers pended to handle normal load, so i’ll, pend 4,000 and if things go that far bad then i’ll just raise an error’. that is a valid strategy. It is not valid to say I need 4 and so i’ll pend 8 and cross my fingers
At the current design, application is using IOCTL to block till interrupt is received in kernel.
The IOCTL coming from application is immidiately sent to internal queue.
When the interrupt is handled in the DPC stage, the IOCTL request is pulled from this queue and answered.
I would like to suggest an alternative:
Upon interrupt, a small descriptor will be written to internal queue during DPC stage.
IOCTL handler will try to pull a descriptor from the internal queue.
In case the internal queue is empty, the pull will be blocked.
Can you please tell is this alternative can work better ?
consider how you propose to block in your DPC in a way that will allow UM code a chance to run and send down a new IRP. If there are ‘enough’ cores, one of them might be available for the UM code to execute while you hog this one. But what if there aren’t? An what about the huge security hole where a misbehaving UM process can starve the system of resources and possibly lock it up completely
having a bounded length queue of data that has been received from hardware but did not have a ready IRP to complete is a valid strategy to deal with this kind of problem. But it has to have a maximum length and can’t block the DPC when it overflows. Many flow control algorithms exist to handle this problem, but the much better answer is to always have an IRP pending for completion
the much better answer is to always have an IRP pending for completion
Or even mix of two. Depends on the OP"s actual h/w design and requirements, of course.
For example if the requirement is just not to miss interrupts (but each interrupt by itself does not carry any data) the driver can simply count the interrupts and pass the count.