> It's entirely possible that the stall packets are created by the hub. > When a full-speed device is connected to a USB-2 hub, and the device > fails to respond to a packet sent by the host, the hub reports this > failure as a stall. Here I don’t think device fails to respond to a packet sent by the host. I verified this by connecting Ellisys USB analyser in between host and devices. For example Look at the attached(Sample_HciEvt.png) HCI event captured by Ellisys USB analyser. It is a valid HCI event from device to Host. IN transaction 96 1 ACK FS 16 bytes (FF 2F C2 01 00 17 00 DF 00 01 10 00 00 A9 EE 0F) IN transaction 96 1 ACK FS 16 bytes (00 00 00 5A 06 9D 39 00 00 66 00 00 00 00 00 00) IN transaction 96 1 ACK FS 16 bytes (00 00 00 00 00 00 00 00 00 00 00 8E 05 28 00 01) IN transaction 96 1 ACK FS 1 byte (00) Due to spurious stall packets , sometimes btusb driver is not receiving this full event , instead it got STALL packet instead of first 16 bytes plus rest of other 33 bytes. > When the device is connected to an OHCI controller, such failures would > be reported in a different way, such as a -EPROTO or -EILSEQ status. > I did not observed -EPROTO or -EILSEQ status in OHCI controller scenario. Thanks, Naveen
Attachment:
Sample_HciEvt.png
Description: PNG image
