Psudo Driver code:
StartIo: //DISPATCH_LEVEL
…
case Read:
case Write:
SendCmd();
…
break;
Dispatch routine: //PASSIVE_LEVEL
…
case TouchMem:
…
AcquireSpinLock(); //touch HW memory
…//some hw related stuff here…
ReleaseSpinlock();
…
break;
case SendCommand:
…
KeRaiseIrql(DISPATCH_LEVEL,…);
SendCmd();
KeLowerIrql(…);
…
break;
…
SendCmd()
{
if (HW is ready){
AcquireSpinLock(); //touch HW memory
…//some hw related stuff here…
ReleaseSpinlock();
//signal HW by writing some HW register
…
}
else DbgPrint(“HW is not ready”);
}
I open 3 consoles to run the same application; basically one is for R/W, and
one is for sending commands and another is to check HW memory. One HW
register is used as a binary semaphore to denote the HW readiness. The
driver can only read it to check, and it will be reset by the FW in the HW
once it gets signaled by the driver.
The console application that does R/W from StartIo always fails after some
time because HW is not ready. But, actually HW is ready. My original
suspecision was it was caused by Dispatch routine. It ran at PASSIVE_LEVEL
and once it read the hw semaphore register and before it’d signal the FW,
the StartIo came in. Consequently, I wrap around the Dispatch routine with
KeRaiseIrql() and KeLowerIrql() in the hope that whoever calls SendCmd()
would run through.
Well, it still fails with the same reason. That makes me wonder could it be
involved with the spinlock I use for the memory access?! Or anything else?
I hope I have given enough infomation to ask for the help. Any ideas will
be welcome and appreciated!
Thanks
AH
Express yourself instantly with MSN Messenger! Download today - it’s FREE!
hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/