My isr copies hw int status to global, clears hw, queues dpc on non-zero status.
DPC reads and clears status.
Under sleep stress, about 1 in 1000 DPCs find a zero status, hence race condition and corruption.
Also, code relies on interrupt enable/disable to make this MT safe, but that seems to be
buggy, especially on shared interrupts.
Short of using KeSycnronizeExecution, I’d like to know if I can use an interlocked queue api
to queue the int sttatus in isr and dequeue in dpc.
thanks,
Massoud
Why is this indicative of corruption. You realize that if you can have multiple I/O requests outstanding simultaneously, that there’s not a one-to-one relationship between calls to WdfInterruptQueueDpcForIsr / IoRequestDpc, right? So you can therefore be called at your DpcForIsr entry point with nothing to do, right?
Why don’t you like KeSynchronizeExecution?
The Interlocked Queue APIs *will* work, but you’ll have to be sure you use them EVERYWHERE you refer to the Queue. And, you should note that the Interlocked Queue APIs *do* disable interrupts to allow them to operate correctly. So… if you ask me… you’re probably better off just using KeSynchronizeExecution.
Peter
OSR
@OSRDrivers
Why is this indicative of corruption.
Int status is only set in isr and cleared in dpc, so if dpc finds it cleared, it means a previous instance of
dpc cleared it. It really needs a queue of int status not just one.
OK so I use KSE.
Thanks.
xxxxx@yahoo.com wrote:
Int status is only set in isr and cleared in dpc, so if dpc finds it cleared, it means a previous instance of
dpc cleared it.
Not necessarily. Consider:
Interrupt
ISR runs, sets the bit, fires the DPC.
DPC #1 starts to run.
Interrupt
ISR runs again, sets bits again, queues the DPC again.
DPC #1 continues to run, fetches and clears status, handles it, returns
DPC #2 starts, finds status is zero
If you’ve done your design correctly, none of this matters at all,
because DPC #1 handled all of the bits that were outstanding. If there
are no bits set, then there is nothing for the DPC to do. It’s not an
error condition.
It really needs a queue of int status not just one.
That’s a bad idea. You can’t count on 1-to-1-to-1 correspondence. If
the machine is busy for some reason, it’s possible for your hardware to
issue multiple interrupts before the ISR gets a chance to run. The
guarantee is that “the ISR will run after an interrupt”, not that “every
interrupt will result in one ISR”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>Consider:
Interrupt
ISR runs, sets the bit, fires the DPC.
DPC #1 starts to run.
Interrupt
…
Assuming that the OP disables interrupts on his device in ISR and re-enables them in DPC shortly before returning, the above scenario is simply infeasible…
Anton Bassov
Sure. But why would you assume he does that?
His OP isn’t clear on this point…
Peter
OSR
@OSRDrivers
> But why would you assume he does that?
I dunno - probably, being of a naturally optimistic character, I just assigned a “conventional wisdom” meaning to the following OP’s statement
Anton Bassov