Long USB device resume

One of our customers (notebook manufacturer) has a problem with our USB device. They used BootVis utility to measure resume time from S3 state and our driver takes 3 sec (3.03 - 3.05) in the log. From driver traces driver receives S0 IRP, sends it down and in completion routine sends D0 IRP to wakeup device from D3 state. D0 IRP is completed after 3 sec; this is where delay occurs.

From traces it is visible device is surprisely removed after D0 completion and new device arrives soon. Well, the device is turned off during S3 because of S3 -> D3 mapping. I observed the same problem when device attached USB too late after power on but in this case we already accelerated fw boot and now it attaches USB after 58 ms and the limit from USB specs is 100 ms.

The customer already found the problem occurs only if they add USBBIOSx value to the registry (http://support.microsoft.com/default.aspx?scid=kb;[LN];841858). False device removal and arrival is one of symptoms listed in the article. However, customer probably has a reason why needs it there although I don’t know it. Without it all works as expected and there is no device removal and arrival and BootVis shows about 200 ms spent in our driver (which is OK).

I’d need to solve the problem somewhat. Unfortunately, I don’t have their computer here so testing and debugging is a bit limited. Has anybody an idea what to do or check? I already tried to complete S0 IRP before sending D0 IRP down. The driver disappeared from BootVis logs but total resume time was equal which makes sense as D0 was also completed after 3 sec.

Does anybody know what exactly USBBIOSx does? The description in above mentioned article is a bit vague. The driver behaves exactly the same way in both cases because power capabilities don’t change. I already asked them to try to change power mapping to S3 -> D2 as they verified it works with our device attached to different USB port.

BTW, I observer similar behaviour on different computer. It has S3 -> D2 mapping and all works correctly when remote wakeup is enabled. When disabled i.e. wait wakeup is cancelled on S0 -> S3 transition, D2 IRP turns of device power (?!) and after resume device removal/arrival occurs. Of course, only if USBBIOSx is in the registry. However, there is no D0 completion delay on this computer.

Any suggestion or explanation welcome.

Best regards,

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

>Does anybody know what exactly USBBIOSx does? The description in above

mentioned article is a bit vague.

According to my understanding of the description, the USB stack patches the
system-to-device mappings in DEVICE_CAPABILITIES in a way so that no wake from
S3 will be allowed.

USBBIOSx value turns this off.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, November 23, 2005 11:05 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Long USB device resume

>Does anybody know what exactly USBBIOSx does? The description in above
>mentioned article is a bit vague.

According to my understanding of the description, the USB stack patches the
system-to-device mappings in DEVICE_CAPABILITIES in a way so that no wake from
S3 will be allowed.

USBBIOSx value turns this off.

System to device mapping for our device is equal in both cases (S3 -> D3). However, if it influences HC mappings too, it could change things.

Best regards,

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

>System to device mapping for our device is equal in both cases (S3 -> D3).

However, if it influences HC mappings too, it could change things.

Yes, HC mappings for sure.

BIOS knows nothing on USB devices, but knows about HC.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, November 23, 2005 9:16 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Long USB device resume

>System to device mapping for our device is equal in both cases (S3 -> D3).
>However, if it influences HC mappings too, it could change things.

Yes, HC mappings for sure.

So if HC is turned off in S3, there is no problem but if it isn’t, it sees device going to and from D3 as device removal and arrival, right? However, it should be normal scenario, what can be wrong in this case?

BIOS knows nothing on USB devices, but knows about HC.

From where are device mappings coming from? I expected it is configured in BIOS per USB port. At least some customers were able to change it in BIOS configuration; per port.

Best regards,

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

> BIOS knows nothing on USB devices, but knows about HC.

From where are device mappings coming from?

From the ACPI table entry for the onboard HC.

I don’t think BIOS knows about the USB-connected devices.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, November 24, 2005 1:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Long USB device resume

> BIOS knows nothing on USB devices, but knows about HC.
>
>From where are device mappings coming from?

From the ACPI table entry for the onboard HC.

I don’t think BIOS knows about the USB-connected devices.

Sure but default mappings have to be created some way. Driver for USB device receives them from system.

It is strange. I used Device Manager to display devices by connection and examined Power State Mappings. Without USBBIOSx all HCs and USB devices have S3 -> D3 mapping. But with USBBIOSx = 0 “Standard OpenHCD USB Host Controller” device has S3 -> D3, attached “USB Root Hub” device S3 -> D2 and attached USB device also S3 -> D2. Confused.

Best regards,

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

An update. In the meantime I found problem isn’t specific to our devices and driver. Now I have a machine where it can be reproduced and reproduced it also with our devices and usbscan.sys OS supplied driver. But also with other USB hardware: NEC external floppy drive using usbstor.sys and Eizo LCD monitor using hidusb.sys. It seems the problem is only reproducible with full speed (1.1) devices; it can’t be reproduced with low speed or high speed devices.

Well, it is related to BIOS configuration but customer resists on it. They have a device which has to be able to wakeup notebook from S3 and this device is probably connected to the same internal USB hub as our one. It means hub is powered on and wait wake armed in S3. On the contrary, our device is turned off. They already verified if our device is turned on (suspended), problem doesn’t occur.

I installed USB drivers from checked build, turned on traces and quickly saw what causes 3 sec delay:

00001240 37.01413345 USBHUB: Warning **************************************************************
00001241 37.01413727 USB device failed first reset attempt in USBH_RestoreDevice
00001242 37.01414490 ******************************************************************************
00001243 37.01414871 USBHUB.SYS: 'Wait for 1000 ms
00001556 38.02881622 USBHUB.SYS: 'Wait done
00001579 38.02902603 USBHUB.SYS: 'Wait for 1000 ms
00001767 39.04456329 USBHUB.SYS: 'Wait done
00001790 39.04487228 USBHUB.SYS: 'Wait for 1000 ms
00001791 40.06018066 USBHUB.SYS: 'Wait done
00001792 40.06018829 USBHUB.SYS: 'Warning: device/port restore failed

Device removal and arrival follows. I also found why USBBIOSx makes the difference. Without it the hub is turned off and there is no problem.

Has anybody an idea what can I do with it? Or what is the root of problem? It doesn’t seem to be in function driver as it has no chance to influence it and it is reproducible with different drivers. Also, the device shouldn’t be a problem as it is reproducible with quite different devices. No problem with connect time, too, as NEC device connects in 750 us.

So what remains? HC (Intel 82801FB/FBM UHCI - 2659), BIOS and OS USB drivers. Has anybody an idea what can be wrong in the BIOS or what they could try?

Thanks.

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: Wednesday, November 23, 2005 12:08 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Long USB device resume

One of our customers (notebook manufacturer) has a problem with our USB device. They used BootVis utility to measure resume time from S3 state and our driver takes 3 sec (3.03 - 3.05) in the log. From driver traces driver receives S0 IRP, sends it down and in completion routine sends D0 IRP to wakeup device from D3 state. D0 IRP is completed after 3 sec; this is where delay occurs.

From traces it is visible device is surprisely removed after D0 completion and new device arrives soon. Well, the device is turned off during S3 because of S3 -> D3 mapping. I observed the same problem when device attached USB too late after power on but in this case we already accelerated fw boot and now it attaches USB after 58 ms and the limit from USB specs is 100 ms.

The customer already found the problem occurs only if they add USBBIOSx value to the registry (http://support.microsoft.com/default.aspx?scid=kb;[LN];841858). False device removal and arrival is one of symptoms listed in the article. However, customer probably has a reason why needs it there although I don’t know it. Without it all works as expected and there is no device removal and arrival and BootVis shows about 200 ms spent in our driver (which is OK).>

I’d need to solve the problem somewhat. Unfortunately, I don’t have their computer here so testing and debugging is a bit limited. Has anybody an idea what to do or check? I already tried to complete S0 IRP before sending D0 IRP down. The driver disappeared from BootVis logs but total resume time was equal which makes sense as D0 was also completed after 3 sec.

Does anybody know what exactly USBBIOSx does? The description in above mentioned article is a bit vague. The driver behaves exactly the same way in both cases because power capabilities don’t change. I already asked them to try to change power mapping to S3 -> D2 as they verified it works with our device attached to different USB port.

BTW, I observer similar behaviour on different computer. It has S3 -> D2 mapping and all works correctly when remote wakeup is enabled. When disabled i.e. wait wakeup is cancelled on S0 -> S3 transition, D2 IRP turns of device power (?!) and after resume device removal/arrival occurs. Of course, only if USBBIOSx is in the registry. However, there is no D0 completion delay on this computer.

Any suggestion or explanation welcome.

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

BTW, I accidentally observed problem disappears if I disable EHCI device in device manager. It of course isn’t s solution because there is one for all ports but it is interesting.

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: Tuesday, November 29, 2005 7:29 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Long USB device resume

An update. In the meantime I found problem isn’t specific to our devices and driver. Now I have a machine where it can be reproduced and reproduced it also with our devices and usbscan.sys OS supplied driver. But also with other USB hardware: NEC external floppy drive using usbstor.sys and Eizo LCD monitor using hidusb.sys. It seems the problem is only reproducible with full speed (1.1) devices; it can’t be reproduced with low speed or high speed devices.

Well, it is related to BIOS configuration but customer resists on it. They have a device which has to be able to wakeup notebook from S3 and this device is probably connected to the same internal USB hub as our one. It means hub is powered on and wait wake armed in S3. On the contrary, our device is turned off. They already verified if our device is turned on (suspended), problem doesn’t occur.

I installed USB drivers from checked build, turned on traces and quickly saw what causes 3 sec delay:

00001240 37.01413345 USBHUB: Warning **************************************************************
00001241 37.01413727 USB device failed first reset attempt in USBH_RestoreDevice
00001242 37.01414490 ******************************************************************************
00001243 37.01414871 USBHUB.SYS: 'Wait for 1000 ms
00001556 38.02881622 USBHUB.SYS: 'Wait done
00001579 38.02902603 USBHUB.SYS: 'Wait for 1000 ms
00001767 39.04456329 USBHUB.SYS: 'Wait done
00001790 39.04487228 USBHUB.SYS: 'Wait for 1000 ms
00001791 40.06018066 USBHUB.SYS: 'Wait done
00001792 40.06018829 USBHUB.SYS: 'Warning: device/port restore failed

Device removal and arrival follows. I also found why USBBIOSx makes the difference. Without it the hub is turned off and there is no problem.

Has anybody an idea what can I do with it? Or what is the root of problem? It doesn’t seem to be in function driver as it has no chance to influence it and it is reproducible with different drivers. Also, the device shouldn’t be a problem as it is reproducible with quite different devices. No problem with connect time, too, as NEC device connects in 750 us.

So what remains? HC (Intel 82801FB/FBM UHCI - 2659), BIOS and OS USB drivers. Has anybody an idea what can be wrong in the BIOS or what they could try?

Thanks.

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: Wednesday, November 23, 2005 12:08 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Long USB device resume
>
> One of our customers (notebook manufacturer) has a problem with our USB device. They used BootVis utility to measure resume time from S3 state and our driver takes 3 sec (3.03 - 3.05) in the log. From driver traces driver receives S0 IRP, sends it down and in completion routine sends D0 IRP to wakeup device from D3 state. D0 IRP is completed after 3 sec; this is where delay occurs.
>
> From traces it is visible device is surprisely removed after D0 completion and new device arrives soon. Well, the device is turned off during S3 because of S3 -> D3 mapping. I observed the same problem when device attached US> B too late after power on but in this case we already accelerated fw boot and now it attaches USB after 58 ms and the limit from USB specs is 100 ms.
>
> The customer already found the problem occurs only if they add USBBIOSx value to the registry (http://support.microsoft.com/default.aspx?scid=kb;[LN];841858). False device removal and arrival is one of symptoms listed in the article. However, customer probably has a reason why needs it there although I don’t know it. Without it all works as expected and there is no device removal and arrival and BootVis shows about 200 ms spent in our driver (which is OK).>
>
> I’d need to solve the problem somewhat. Unfortunately, I don’t have their computer here so testing and debugging is a bit limited. Has anybody an idea what to do or check? I already tried to complete S0 IRP before sending D0 IRP down. The driver disappeared from BootVis logs but total resume time was equal which makes sense as D0 was also completed after 3 sec.
>
> Does anybody know what exactly USBBIOSx does? The description in above mentioned article is a bit vague. The driver behaves exactly the same way in both cases because power capabilities don’t change. I already asked them to try to change power mapping to S3 -> D2 as they verified it works with our device attached to different USB port.
>
> BTW, I observer similar behaviour on different computer. It has S3 -> D2 mapping and all works correctly when remote wakeup is enabled. When disabled i.e. wait wakeup is cancelled on S0 -> S3 transition, D2 IRP turns of device power (?!) and after resume device removal/arrival occurs. Of course, only if USBBIOSx is in the registry. However, there is no D0 completion delay on this computer.
>
> Any suggestion or explanation welcome.
>
> 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
>


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