Re: [PATCH v4] USB: HID: random timeout failures tackle try.

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

 



On 4.2.2020 16.57, Alan Stern wrote:
> On Tue, 4 Feb 2020, Lauri Jakku wrote:
>
>> -- v1 ------------------------------------------------------------
>> send, 20ms apart, control messages, if error is timeout.
>>
>> There is multiple reports of random behaviour of USB HID devices.
>>
>> I have mouse that acts sometimes quite randomly, I debugged with
>> logs others have published that there is HW timeouts that leave
>> device in state that it is errorneus.
>>
>> To fix this I introduced retry mechanism in root of USB HID drivers.
>>
>> Fix does not slow down operations at all if there is no -ETIMEDOUT
>> got from control message sending. If there is one, then sleep 20ms
>> and try again. Retry count is 20 witch translates maximium of 400ms
>> before giving up.
>>
>> NOTE: This does not sleep anymore then before, if all is golden.
> How do other operating systems handle these problems?  Perhaps we 
> should use the same approach.
>
> Also, if this problem only affects USB HID devices, why not put the 
> fix in the usbhid driver rather than the USB core?
>
> Alan Stern

hmm, i investigate, what i know now is few mentions about mouse

acting up etc.


I do more research, tomorrow.


I think in my mind, that the core is good place, the thing ppl are forgetting

that it does not make any unnecessary sleeps and when it does it it is

about 70-100ms max per loop, and they are restricted to 20.


The patch does not enforce any different use, in non-timeout case it is

as fast as without the patch.


I can easilly debug, cause my mouse acts up and that 5 loop version that

I tried on my PC+ usb keyboard + usb mouse. It was way better.


And now i got confirmation from my dad (Suse user) that with latest kernel,

there have been acting up.


The timeout retry loop done in patch within the USB core activates only

when the timeout happens, and latest version adapts the 5000ms (common)

to 50ms timeout, and sleeps 20ms per loop.


But, keep comments coming & suggestions .. and if someone could test too,

so I do not be only one to test this :) ..



-- 
Br,
Lauri J.




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux