Hello Alan, thanks for getting back on this...
Il 21 marzo 2016 16:01:17 CET, Alan Stern <st...@rowland.harvard.edu> ha scritto: >On Sun, 20 Mar 2016, Guido Trentalancia wrote: > >> Hello. >> >> Considering that EM interference can last for a while (generally up >to >> seconds), I am currently testing the following patch for module >usbcore >> so that it is possible to specify an amount of time to wait before >> trying to re-enable a port that has been previously disabled by the >hub >> (supposedly because of EM interference). >> >> Hopefully, setting the right positive value (for example, 2000 >> milliseconds) would help overcome situations such as the following: >> >> [ 1295.575679] usb 6-2: FTDI USB Serial Device converter now attached >> to ttyUSB1 >> [ 1302.204285] usb usb6-port2: disabled by hub (EMI?), re-enabling... >> >> *** NOTE: EMI is probably still present here *** >> >> [ 1303.205202] usb 6-2: USB disconnect, device number 6 >> [ 1303.205907] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now >> disconnected from ttyUSB1 >> [ 1303.205950] ftdi_sio 6-2:1.0: device disconnected >> [ 1303.414089] usb 6-2: new full-speed USB device number 7 using >> uhci_hcd >> [ 1303.526226] usb 6-2: device descriptor read/64, error -71 >> [ 1303.894228] usb 6-2: new full-speed USB device number 8 using >> uhci_hcd >> [ 1304.006185] usb 6-2: device descriptor read/64, error -71 >> [ 1304.219089] usb 6-2: device descriptor read/64, error -71 >> [ 1304.422107] usb 6-2: new full-speed USB device number 9 using >> uhci_hcd >> [ 1304.640020] usb 6-2: device not accepting address 9, error -71 >> [ 1304.752024] usb 6-2: new full-speed USB device number 10 using >> uhci_hcd >> [ 1305.160020] usb 6-2: device not accepting address 10, error -71 >> [ 1305.160038] hub 6-0:1.0: unable to enumerate USB device on port 2 >> >> *** NOTE: Device is permanently disabled at this point *** >> >> I don't know whether my analysis is correct (and therefore the >proposed >> solution appropriate), as reproducing the problem is very >difficult... > >Would it be better instead to provide a mechanism for re-enabling the >port after it has been "permanently" disabled? After all, you don't >know how long the EMI is going to last, and so the kernel has to give >up at some point. This means increasing the delay will make problems >more infrequent but won't eliminate them completely. > >Alan Stern It should be automatic (e.g. for servers). The manual solution doesn't need a patch: it's hardware, i. e. unplug then plug-again ;) In some cases it is possibile to predict how long interference lasts (for example, the source is co-located and known). This is not that uncommon, I suppose... When the source is not known then only statistical assumptions can be made regarding the duration of the interference: a value between 1000 and 2000 would probably suit most cases and also seems in line with other hard-coded waiting times in the driver. As you correctly noted, further increasing the value will make problems more infrequent but not necessarily would eliminate them completely (consider, for example, a very long USB cable picking up interference from a long wireless phone call lasting minutes, although even in such case there will usually be fades of the order of several milliseconds or 1-2 seconds). There is no "one fits all" solution, I suppose: only statistical assumptions and optimal solutions based upon them (and/or full configurability such as in a kernel parameter). Consider at the moment, we have least reliability against such EMI issues, as they all have finite duration. Regards, Guido -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
