Hi,
I've seen this issue with brand name PC's containing the Intel USB3.0 eXtensible Host Controller (Dell, Lenovo, etc) and generally running Win7 Pro. Essentially if an HID device (does not have to be a keyboard or mouse and typically is not) ACKs the Host IN data requests on Interrupt IN Endpoints then the host hangs on reboot somewhere before the OS takes over. It "seems" the BIOS is waiting for the HID device to NAK on the IN Endpoint before it will release "something" and allow the OS to boot. The hang is indefinite. Only unplugging the device will allow the boot to proceed.
I believe the device is operating within the broad spec that HID paints. The device has data that it wishes to pass on to the host on each and every IN transaction that the host doles out to it. It does not matter if the device Stalls the HID Set Idle command or not. The PC still hangs.
I can provide a device for testing and I have seen a smattering of similar complaints online, usually gamer HID devices but not exclusively. I have run this issue by a few people I consider to be USB experts and they agree the host is creating the issue.
To reproduce, the Full Speed HID device should have at least one Interrupt IN Endpoint and the faster the bInterval value the worse the problem is, so set it to 2ms for testing. When the host issues an IN transaction on the Interrupt Endpoint in question, have the HID device always ACK that request by returning a data packet that matches the report for the device. If you want to use a keyboard then a standard keyboard report like 00 00 00 00 00 00 00 00 will suffice. The situation where the PC reboots is the worst case.
Since this is such a nasty failure mode I think Intel should look at this issue. There may be other scenarios that create a similar failure but I have not tested them yet. I did test a CDC (Virtual COM) device that has an Interrupt IN Endpoint at 2ms ACKing alll the time and it does NOT exhibit the same failure. So it seems the host is penalizing only HID in this manner.
Thanks,
GB