asynchronous I/O problem with KMDF
- From: lorenzoff <lorenzo.fracassi@xxxxxxxxxx>
- Date: Tue, 25 Sep 2007 10:19:38 -0700
Hello to all,
I'm developing a device driver for a gaming usb scanner and, normally,
it works quite well (thanks
Eliyas Yakub). There is something that I can't understand with the
asynchronous i/o; the scanner may block several time due to its
internal workflow or due to known firmware bugs.
I've used this approach (can someone evaluate it?).
The device supports two kind of ioctl (no read nor write): requests
that do not require a firmware work (versioning and so on) and
requests that require firmware work.
The deviceadd callback creates the default queue as parallel and an
ausiliary queue as sequential. The sequential queue is used to manage
these request that need firmware work because that firmware can manage
only a command once.
WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&_def_queue_config,
WdfIoQueueDispatchParallel);
_def_queue_config.EvtIoDeviceControl = OnIoDeviceControl;
_status = WdfIoQueueCreate(_device, &_def_queue_config,
WDF_NO_OBJECT_ATTRIBUTES, &_def_queue);
WDF_IO_QUEUE_CONFIG_INIT(&_fwcmd_queue_config,
WdfIoQueueDispatchSequential);
_fwcmd_queue_config.EvtIoDeviceControl = OnFWCommandIoDeviceControl;
_status = WdfIoQueueCreate(_device, &_fwcmd_queue_config,
WDF_NO_OBJECT_ATTRIBUTES, &(_dev_context->FwCommandQueue));
When the framework deliver a new request to my default
EvtIoDeviceControl (OnIoDeviceControl on the snippet above), it is
immediately completed if it belongs to a ioctl that not requires
firmware; it is requeued to the sequential queue otherwise. In this
second case, my default EvtIoDeviceControl returns immediately after
an WdfRequestForwardToIoQueue.
At the beginning of my ausiliary EvtIoDeviceControl
(OnFWCommandIoDeviceControl on the snippet above) I use
WdfRequestMarkCancelable to be notified about request cancellation.
After, i have to write the firmware command using
WdfUsbTargetPipeWriteSynchronously, and receive the response by
WdfUsbTargetPipeReadSynchronously before complete the user ioctl
request.
When the firmware works, all this appear to work fine. One of the
known firmware bugs is that it miss the response in certain
circumstances. When this happen, WdfUsbTargetPipeReadSynchronously
block undefinitely (I known about timeout, but I prefer that is the
application to choose its timeout).
And, finally, there is the problem.
When I reproduce the situation due to the firmware blocks, my test
consolle application cannot use CancelIo beacuse it bloks into the
DeviceIoControl call (I've verified using same printf).
Application side I use this code:
HANDLE Hnd=CreateFile("\\\\.\\MyDevice", GENERIC_READ | GENERIC_WRITE,
0, NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL);
OVERLAPPED _overlapped;
BOOL _result=FALSE;
HANDLE _event;
memset(&_overlapped, 0, sizeof(OVERLAPPED));
_event = CreateEvent(NULL,TRUE,FALSE,NULL);
_overlapped.hEvent = _event;
_result=DeviceIoControl(Hnd, Code, InBuffer, InBufferSize, OutBuffer,
OutBufferSize, BytesReturned, &_overlapped);
if (!_result) {
if (GetLastError() == ERROR_IO_PENDING) {
switch (WaitForSingleObject(_event, 5000)){
....
....
The most strange (for me) thing is that if I open a new process of my
test application, it works as expected; DeviceIoControl fails and
WaitForSingleObject wait until the timeout expires.
But, why the first DeviceIoControl does not return? Using the debugger
I can see that the second request is delivered to my default
EvtIoDeviceControl; it is forwarded to the sequential queue and its
callback is NOT invocked (this is right). User mode DeviceIoControl
exit immediately. Why the first call blocks?
.
- Follow-Ups:
- Re: asynchronous I/O problem with KMDF
- From: lorenzoff
- Re: asynchronous I/O problem with KMDF
- Prev by Date: Could I get the signed logo if only INF and property page provided?
- Next by Date: Re: asynchronous I/O problem with KMDF
- Previous by thread: Could I get the signed logo if only INF and property page provided?
- Next by thread: Re: asynchronous I/O problem with KMDF
- Index(es):
Relevant Pages
|
|
