BIOS Usb 3.0 Key Behavior In Deep S3

Aswe known, In BIOS side Deep S3 and Normal S3 are almost the same(BIOS only setpower policy and send a cmd to notify EC to support deep S3). 

Itseems the usb controller(Core/High Speed IO)and ports are powered off in deep S3, So maybe usb 3.0 host driver or device FWmay think it’s in Suspend mode during deep S3 but in fact the power of thedevice has been turned off after deep s3 done.  During deep s3 resume, usb3.0 host driver or device FW may want to switch from suspend mode to activemode. may be It failed.

According to  “Microsoft Windows USB Core Team Blog”  seems the phenomenon is the common known issues in USB 3.0 devices of OS USB3.0 inbox driver. 

4.10 Device disappearing on system resume

When the system goes to sleep, some controllers or platformswill cut the VBUS off and cause the downstream devices to disconnect from thebus. When the system resumes and VBUS is reapplied, these devices will connectback. If the device is bus powered, then it will also need to power back onbefore connecting on the bus.

If the driver stack reads the port status during system resumeand finds that the device is back, the driver will re-enumerate the device andre-store its configuration without letting the operating system know that thedevice re-connected. As a result, this re-enumeration is transparent toapplications. Any operations in progress before the system went to sleep cancontinue without interruption.

However, if the driver stack finds that the device has notconnected back, it will report the device as missing to the operating system.When the device connects back, there will be a new instance created for thedevice and the device will start working. However, the surprise removal of theold instance of the device will interrupt any applications that were using thedevice before the system went to sleep. For example if a file copy was inprogress for a storage device, it will fail. Also, creating a new instance willtake some time and the user might see a delay in device becoming availableafter resume.

To mitigate this issue, we implemented a heuristics in ourWindows 8 driver stack. When the driver stack finds that the device is notconnected on system resume, it gives a grace period (which is currently set toone second) to the device to connect back before reporting the device missing.However, we observed that some devices take longer than this to connect back,leading to surprise removal and a poor end user experience.

In the USB hardware verifier output, this failure can beidentified by the tagHubHwVerifierPortDeviceDisconnected.However, please note that this tag will appear whenever the device isdisconnected. So if you did indeed remove the device, then ignore this tag.