> Note that the USB-2.0 spec says (section 9.2.6.3, Set Address > Processing): > > After the reset/resume recovery interval, if a device receives a > SetAddress() request, the device must be able to complete > processing of the request and be able to successfully complete > the Status stage of the request within 50 ms. > > These devices' 9.6 seconds to process a Set-Address request is a _lot_ > longer than 50 ms. No wonder they don't work properly. Why on earth do > they take so long? The device can't actually respond as it's no longer present on the bus. The hardware is taking this long to complete the TRB when the device disappears in the middle of the transaction (at least this is the theory). I'm not trying to argue that these devices aren't crappy. However, it does seem like there are quite a lot of crappy devices in the field. It would be nice if the driver didn't die when encountering these devices. > Of course, xHCI controller drivers should be able to cancel an > Address-Device TRB without waiting for it to complete. Agreed. Is there some way I could try to cancel this command ring TRB? The hardware seems hung enough that it's not responding to whatever we're trying to do in the cleanup routine when the timeout handler fires though. > > Alan Stern
