One is what this chip does, which is pretend all USB 2 devices behind it are USB 3. I will never forgive the USB-IF for this gaffe, it is ridiculous. There is no way to implement it that works as you would expect. The USB standard for some inexplicable reason refused to specify USB 3 to USB 2 transaction translation.
I would absolutely split my bets on it being a controller or kernel issue. We clearly have very different intuitions here. > Basic intuition tells us it’s a hardware issue, either controller, hub, or device. Once you're having controller-global issues that could be caused by either of those, usbmon is not useful because that assumption no longer holds. Usbmon was invented for debugging USB issues with a single device, under the assumption that there is no fault with the kernel's USB stack and the controller. > Usbmon was invented for this exact use case: debugging usb issues under the assumption that there is no fault in the kernel’s usb stack. Is it likely? very much not.Īs someone who works with USB regularly, I very much disagree with your assessment. > Is it technically possible that usbmon will say that it sent proper data to the device when in fact it didn’t due to a bug in the kernel XHCI stack? Yes it is. USB is an overcomplicated standard and extremely difficult to implement properly.
I wouldn't, because I've found and fixed bugs in the kernel's xHCI implementation, and I still regularly panic or oops my kernel with dodgy USB devices, which is by definition a kernel bug (and a security one at that). I’d be willing to bet my life that the kernel’s more than a decade old and globally deployed XHCI implementation is not the cause of his USB issues.
0 kommentar(er)
