[Nut-upsuser] USBDEVFS_CONTROL failed cmd usbhid-ups

[Arjen de Korte]

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

> I've done that and included the syslog output in the same file. The
> logfile is attached and contains about 15 minutes worth of information,
> which is how long it took for the first re-connect event to appear.
>
> Hope it helps,

It sure does, thanks! There seems to be a collision between reading of  
an interrupt report and a feature report. Normally we would expect  
something like the following:

    upsdrv_updateinfo...
    Report[int]: (6 bytes) => 06 64 dc 05 00 00
    Got 2 HID objects...
    Report[get]: (6 bytes) => 06 64 dc 05 00 00
    Path: UPS.PowerSummary.RemainingCapacity, Type: Input, ReportID:  
0x06, Offset: 0, Size: 8, Value: 100.000000
    Report[buf]: (6 bytes) => 06 64 dc 05 00 00
    Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input, ReportID:  
0x06, Offset: 8, Size: 32, Value: 1500.000000

Here we receive report 06 via the interrupt pipe (Report[int]).  
Because there have been some issues with broken interrupt reports in  
the past (mostly Belking devices, if memory serves), we ignore the  
contents of this report and instead request feature report 06  
(Report[get]). In this case, we get the same answer and it is  
processed as usual.

The next time we receive an interrupt report, something odd happens:

    upsdrv_updateinfo...
    Report[int]: (6 bytes) => 06 64 dc 05 00 00
    Got 2 HID objects...

This is still looking good.

    Can't retrieve Report 6: Value too large for defined data type

Oops. We attempt to read feature report 06 again, but now somehow the  
UPS is sending us *more* than the 6 bytes we expect. This makes the  
driver ignore the report (and apparently, the UPS chokes on this too).

    Report[buf]: (6 bytes) => 06 64 dc 05 00 00
    Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input, ReportID:  
0x06, Offset: 8, Size: 32, Value: 1500.000000

And here we see the buffered report, that apparently is still good.

There are several things to try out now:

1) Upgrade to the latest version from the trunk. Previously, we would  
ignore reports that are larger than expected. We no longer do that and  
instead trim off any excess bytes. This in order to be able to better  
debug if things go wrong. It would be helpful to see what the UPS is  
returning if it is sending us more data than expected.

2) We might also want to skip the step of reading the feature report  
after reading an interrupt report. In order to do that, change line  
773 in usbhid-ups.c from

	if (HIDGetDataValue(udev, event[i], &value, (i > 0) ? poll_interval :  
0) != 1)
to
	if (HIDGetDataValue(udev, event[i], &value, poll_interval) != 1)

This will use the interrupt report as we receive it. In both cases,  
run the driver in debug mode 3 (like you did before).

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