Re: [PATCH] usb: Wait before re-enabling a port that has been disabled due to EMI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux