Consider also a couple of very common non-telecom EMI sources: vehicle engines and lifts starting up. Both of them have a typical duration which I suppose is of 1, 2 or at most 3 seconds (although I do not have exact figures or references to them). What would really help here is an ad-hoc study on typical duration of EMI inside buildings... In the meanwhile, I believe 1000 milliseconds (plus configurability) to be safe. Regards, Guido Il 21 marzo 2016 16:42:14 CET, Guido Trentalancia <guido@xxxxxxxxxxxxxxxx> ha scritto: >Hello Alan, > >thanks for getting back on this... > >Il 21 marzo 2016 16:01:17 CET, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> >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 majordomo@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
