On Fri, 29 Nov 2013, Kristian Evensen wrote: > Hi, > > Thank you very much for the quick reply. > > On Fri, Nov 29, 2013 at 4:13 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > The most common reason for -71 errors is that the device failed to send > > a reply or handshake packet back to the host. Generally this is caused > > by a bug in the device's firmware (it can also be caused by unplugging > > the USB cable, but obviously that didn't happen here). Ideally, if you > > knew what caused the device to go into this buggy state, you could > > avoid the situation. > > Thanks for the pointer. I have to admit I am a little bit unsure about > what you refer to by device, do you mean the modem or the SoC USB hub? > As it seems like most of the retransmitted packets are the big ones > (1514 bytes), I guess it is the hub that does not ACK? By "device", I mean the piece of hardware that is supposed to reply to the host. In your case that would be the modem (the hub does not make up replies to packets that were sent to the modem). On the other hand, it is true that in some circumstances, problems in the hub could mess up communications between the host and the modem. This could happen if the hub communicates at high speed (480 Mb/s) and the modem communicates at full speed (12 Mb/s). > > It would not help. Once the device stops replying to the host, it > > pretty much doesn't matter what you do on the host. The only way to > > address the problem is to do some sort of error recovery on the device. > > One interesting observations is that the modems seems to work fine > after this happens. They reattach to the network, switch between > UMTS/LTE and so forth. This may indicate the problem is in the hub. But if it is, there isn't much you can do about it. > > You could try doing a USB reset of the device. Of course, this is > > likely to cause the device to lose all its settings, so it may end up > > being worse than the original problem. > > Thanks, this is what we are currently experimenting with. Since it > seems to be a bug in the device, we made a quick hack where we monitor > the output from the kernel and reset USB as soon as -71 is seen. We > have also patched the qh_completions()-functions to drop packets where > qtd->length - QTD_LENGTH(token) == 0, to shorten the wait for the usb > reset to be detected. After a reset, the USB hub + modems work fine. > > One thing I have noticed is that when this error occurs with > option_serial, a usb reset (by using gpio) is detected immediately. > This is not the case with qmi-modems, which use cdc_wdm, they hang > until packets on the queue have been retransmitted (and we have > disconnected the devices). Is this expected behavior? I have no idea. I don't know how the various CDC drivers work. 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
