On Thu, 16 Oct 2014, Naveen Kumar Parna wrote: > > 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) This doesn't prove anything. All it means is that the device responded properly on these four occasions. What if the device failed to respond on some other occasion? You have to compare the output of the analyzer with the output from usbmon. If usbmon shows a STALL and the analyzer shows a valid reply for the very same packet, then you'll know the device isn't at fault. You should also run a similar test when you connect the device through a USB-2 hub. In fact, you should run two tests. In one test, connect the analyzer to the cable segment between the computer and the hub; in the other test, connect the analyzer to the cable segment between the hub and the device. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
