[Nut-upsuser] Crash when I start driver

Arjen de Korte nut+users at de-korte.org
Wed Dec 5 08:21:02 UTC 2007


> When I run the command
> # ../bin/usbhid-ups -a igor -DD -u root
> it produces the long output which is attached below.
> Then the machine crashes.  I think the UPS just turns off
> the power.  The log file contains the line
> Dec  4 16:05:26 computer kernel: usb 2-2: USB disconnect, address 2
> As you might guess, I am out of favor with the guy who uses the
> machine.  I won't get to touch it again unless I can convince him
> that I know what I'm doing.
> Can anyone explain this?

I'll give it a try.


> Using subdriver: TrippLite HID 0.1 (experimental)
> Path: UPS.PowerSummary.iProduct, Type: Feature, ReportID: 0x28, Offset:
> 0, Size: 8, Value: 1.000000
> Path: UPS.PowerSummary.iSerialNumber, Type: Feature, ReportID: 0x29,
> Offset: 0, Size: 8, Value: 2.000000
> Path: UPS.PowerSummary.iManufacturer, Type: Feature, ReportID: 0x2b,
> Offset: 0, Size: 8, Value: 3.000000

The above parameters are all indexes to string descriptors in the UPS. The
i<ParaMeter> indicates that. These are all defined by the HID Power
Devices specification, so no surprises here.

> Path: UPS.PowerSummary.Input.ConfigVoltage, Type: Feature, ReportID:
> 0x30, Offset: 0, Size: 8, Value: 120.000000

Nominal input voltage as reported by the UPS is 120V. Good.

> Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature, ReportID:
> 0x11, Offset: 0, Size: 8, Value: 2.000000

The alarm value is currently 2, which means the audible alarm is enabled
(sound when an alarm is present).

> Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature, ReportID: 0x2a,
> Offset: 0, Size: 8, Value: 24.000000

Uh oh, this is probably the cause of the problem. The UPS is possibly
trying to tell that the nominal battery voltage is 24V. However, what it
is actually reporting, is the index of a string descriptor containing the
battery’s chemistry (see the values above). Since we don't read the string
descriptor now, this is not a problem (yet).

The remaining messages are all fine, until we reach the next line

> upsdrv_updateinfo...
> - Unable to fetch string 24

Here 'usbhid-ups' tries to read the string desciptor from the
'UPS.PowerSummary.iDeviceChemistry' path, which we explained above is
likely not what is intended. I wouldn't be surprised that attempting to
read a parameter way out of the range of possible string descriptors might
confuse the heck out of the UPS firmware and from that moment on, the UPS

The safest way to verify the above assumption, is to run the UPS without
load and see if it shuts off if you attempt to run it with an unmodified
'usbhid-ups' driver. If it still does, comment out the line 117 as follows
in 'drivers/tripplite-hid.c' and build the driver again.

	/* { "battery.type", 0, 0, "UPS.PowerSummary.iDeviceChemistry", NULL,
"%s", HU_FLAG_OK, stringid_conversion }, */

I think it will work then, since we no longer attempt to read this HID
path anymore. The root of the problem is a firmware bug of the UPS. If you
can confirm that it works if you comment out the above line, we'll put a
fix in the 'tripplite-hid' subdriver, so that it will treat this value as
the nominal battery voltage for the AVR 550U.

Best regards, Arjen
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57

More information about the Nut-upsuser mailing list