On Thu, 19 Oct 2017, Lukasz Majewski wrote: > > > Problem: > > > > > > I do observe that the USB transfers are truncated - for example > > > "Get Configuration Descriptor", which length is 34B only gets 16B > > > from the device. > > > > > > I do get the "Invalid PID sequence" error and despite the > > > > How do you know the error is "Invalid PID sequence" and not something > > else, like CRC error or timeout? > > I'm using TotalPhase USB 480 Analyzer. It shows only "Invalid PID > sequence" as the error. When I "unroll" the GetConfigurationDescriptor, > then all data is the same as for correct transmission. > > > > > > DATA1 Packet received by host - the EHCI controller is not sending > > > ACK. > > > > The DATA1 packets are the ones containing bytes 9-16, 25-32, and so on > > (low speed always uses maxpacket size = 8). Since you received 16 > > bytes, this means the host controller accepted the DATA1 packet but > > didn't send an ACK -- that certainly would be a hardware bug. > > I do receive 16B, but those are "comprised" of two separate IN > transactions (8 B each). > One such transaction is built with SETUP -> DATA1 -> ACK packets. > > [Please see the attached screen] According to the screen dump, the device sent a DATA1 packet which the host controller did not ACK. That's a bug in the host controller. In the next transaction, the device sent an empty DATA1 packet instead of resending the previous data. That's a bug in the device. > > Anyway, > > this should have caused the device to retransmit the DATA1 packet in > > response to the next IN packet (if there was one). > > There is IN packet sent afterwards, but it is empty. The whole > GetConfigurationDescriptor ends with OUT ZLP.... That part is normal. > I'm wondering if it is feasible to manually check the XactErr bit and > then for example order the soft USB reset (from the root hub)? > > Or is there any other acceptable in upstream solution? Not in general. For this one particular case (a short transfer for a Get-Configuration-Descriptor request), it would be easy enough to retry the transfer. Just put a short retry loop around the second usb_get_descriptor() call in usb_get_configuration() in drivers/usb/core/config.c. But similar failures at other times would be harder to recover from. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
