Sleeping device

We encountered yet another problem with the USB device and selective suspend. On one computer there are interesting race conditons. Application closes device and after some time idle callback suspends device. Completion routine for D2 IRP is called and few ms later app decides to open device again and driver in turn sends D0 IRP to wake device up. After some time (~ 300 ms) completion routine for this IRP is called with success status so driver believes device is ready. But it isn’t. It doesn’t work and all requests return error (STATUS_UNSUCCESSFUL or STATUS_DEVICE_DATA_ERROR).

It seems as device wasn’t really awaken. It recovers when desperate app closes device, drivers suspends it and later wakes it up again. Since then device works. Also, WAIT_WAKE IRP queued before the first D2 doesn’t complete until the second (recovering) D0 completion. USB analyser logs confirm device is suspended for whole time when it doesn’t work. Great.

There is Intel HC in this machine. I tried to reproduce this scenario on different machines and everything worked with no problem. The time between the first D2 completion and D0 request was between 3 - 40 ms in cases which caused problem.

My question is if somebody ever encountered such problem and if there is a chance to do something with it. Next question is how to find what causes this behaviour; it can be both hw or software (XP SP2).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

I reproduced it on another computer with different hw. It seems as OS bug. On the first one there is OS UHCI driver and critical interval between D2 completion and D0 request is about 0 - 6 to 15 ms (not 40 ms as I wrote previously). At the second one there is OS OHCI driver and critical time is less than 15 ms which is timer resolution. Surprisingly, on the second one port reset helps and device recovers without power down/up.

The easiest way how to reproduce bug is to send D0 directly from D2 completion routine. Waiting before it there even for a long time (when called at PASSIVE_LEVEL) doesn’t help so it seems OS has to do something after power IRP is completed. When a work item is planned instead, KeDelayExecutionThread() in worker routine for non-zero interval before D0 avoids problem because it is 15 ms in reality. But KeStallExecutionProcessor() for any time doesn’t so it is evident CPU has to do something. Problem can’t be reproduced at SMP machine (which isn’t surprising).

To be quite accurate, here is a way how to reproduce bug:

  • send IDLE IRP down the stack whend device is idle
  • when callback is called, send D2 IRP to power device down
  • in power dispatch handler set completion routine
  • when completion routine is called, queue work item
  • from work item worker routine send D0 IRP immediatelly the same way as D2 before
  • wait until D0 completion routine is called

I believe above scenario doesn’t break any rule and device should be functional after it. It isn’t. Device remains suspended and is unusable, at least on two single CPU computers I used for test. Is there any way how to report bug to MS?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Michal Vodicka[SMTP:xxxxx@upek.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, October 21, 2005 11:01 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Sleeping device

We encountered yet another problem with the USB device and selective suspend. On one computer there are interesting race conditons. Application closes device and after some time idle callback suspends device. Completion routine for D2 IRP is called and few ms later app decides to open device again and driver in turn sends D0 IRP to wake device up. After some time (~ 300 ms) completion routine for this IRP is called with success status so driver believes device is ready. But it isn’t. It doesn’t work and all requests return error (STATUS_UNSUCCESSFUL or STATUS_DEVICE_DATA_ERROR).

It seems as device wasn’t really awaken. It recovers when desperate app closes device, drivers suspends it and later wakes it up again. Since then device works. Also, WAIT_WAKE IRP queued before the first D2 doesn’t complete until the second (recovering) D0 completion. USB analyser logs confirm device is suspended for whole time when it doesn’t work. Great.

There is Intel HC in this machine. I tried to reproduce this scenario on different machines and everything worked with no problem. The time between the first D2 completion and D0 request was between 3 - 40 ms in cases which caused problem.

My question is if somebody ever encountered such problem and if there is a chance to do something with it. Next question is how to find what causes this behaviour; it can be both hw or software (XP SP2).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com