[Nut-upsuser] USBDEVFS_CONTROL failed cmd usbhid-ups

[Arjen de Korte]

Citeren Thomas Gutzler <thomas.gutzler op gmail.com>:

> Are there any thoughts, comments or suggestions for this problem or
> should I just ignore it?

There are some thoughts, but they are not much different from what you  
may have already found in the archives.

>> I keep getting the following messages (or similar) in my syslog:
>> Nov 23 11:38:08 io kernel: [763936.921566] usb 3-2: usbfs:
>> USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 5 ret -110

ETIMEDOUT       110     /* Connection timed out */

>> Nov 23 11:38:08 io kernel: [763936.972569] usb 3-2: usbfs:
>> USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 5 ret -75

EOVERFLOW       75      /* Value too large for defined data type */

>> Nov 23 11:38:08 io kernel: [763936.976568] usb 3-2: usbfs:
>> USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 2 ret -71

EPROTO          71      /* Protocol error */

This is a typical chain of events for a USB device that doesn't  
respond anymore (locked up). We attempt to read something, it doesn't  
answer, we retry and end up with in complete mess. The only thing that  
can be done to get out of that, is to reconnect. Older devices  
(actually, USB implementations in the UPS) seem to suffer more from  
the above than newer ones.

One thing you could try, is to see if increasing 'pollfreq' to 120 for  
this driver instance reduces the number of occurrences in the log.  
Chances are, the UPS chokes on the large amount of data it needs to  
process when we poll for all variables every 'pollfreq' seconds. It  
will still poll for the most important status bits every  
'pollinterval' anyway, so you don't risk missing out on critical  
events. Note that this won't fix the problem, it just limits the impact.

Best regards, Arjen
-- 
Please keep list traffic on the list