usbhid-ups not behaving with Tripplite UPS

Bug #239025 reported by Gavin Hurlbut
10
Affects Status Importance Assigned to Milestone
nut (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: nut

I am currently running gutsy on my server (pending enough time for a full upgrade to hardy), but have upgraded nut to the hardy deb package (2.2.1-2.1ubuntu7).

I have a TrippLite UPS that says on the box: OMNIPLUS1000LCD. Linux sees it fine as a HID device, and this version of nut will recognize it when using usbhid-ups. However, upsd can't use it, and manually running the usbhid-ups driver at debug level 1 showed me something that led me to a conclusion... It's stuck in an infinite loop.

lsusb reports:
Bus 001 Device 003: ID 09ae:2007 Tripp Lite

/etc/nut/ups.conf:
[tripplite]
        driver = usbhid-ups
        port = auto
        vendorid = 09ae
        productid = 2007

when running /lib/nut/usbhid-ups -D -a tripplite :

debug level is '1'
upsdrv_initups...
Using subdriver: TrippLite HID 0.2 (experimental)
Path: UPS.PowerSummary.iProduct, Type: Feature, ReportID: 0x28, Offset: 0, Size: 8, Value: 1.000000
<<SNIP TO END OF SECTION>>
Path: UPS.OutletSystem.Outlet.DelayBeforeReboot, Type: Feature, ReportID: 0x17, Offset: 0, Size: 16, Value: 65535.000000
Detected a UPS: Tripp Lite /TRIPP LITE UPS
upsdrv_initinfo...
upsdrv_updateinfo...
Got 8 HID objects...
NUT doesn't use this HID object
NUT doesn't use this HID object
NUT doesn't use this HID object
Got 1 HID objects...
Got 1 HID objects...
Got 8 HID objects...
<<SNIP>>

It goes on like this indefinitely. It also doesn't seem to reach line 755 in usbhid-ups.c (line number from 2.2.1 tagged in svn in case it has moved):

 upsdebugx(1, "took %.3f seconds handling interrupt reports...\n", interval());

I noticed in the change logs for 2.2.2:

Tue Apr 22 17:58:12 UTC 2008 / Arjen de Korte <email address hidden>

 - drivers/usbhid-ups: only check once for input reports in
   upsdrv_updateinfo() to prevent lockups if the UPS floods the
   driver (some Tripplite units will generate one each time you
   ask them) [ backported r1450 ]

So I guess the end result is: this bug may be fixed in the upstream, but ubuntu doesn't have the fix in yet? I also noticed that intrepid is so far using the same version as hardy.

Related branches

Revision history for this message
Arnaud Quette (aquette) wrote : Re: [Bug 239025] [NEW] usbhid-ups not behaving with Tripplite UPS

2008/6/11 Gavin Hurlbut <email address hidden>:

> ...
> Tue Apr 22 17:58:12 UTC 2008 / Arjen de Korte <email address hidden>
>
> - drivers/usbhid-ups: only check once for input reports in
> upsdrv_updateinfo() to prevent lockups if the UPS floods the
> driver (some Tripplite units will generate one each time you
> ask them) [ backported r1450 ]
>

I don't recall the exact history, and Arjen will soon be on paternity
vacation, so I don't want to bother him too much. But it seems you found the
solution.

To validate this, you can try the sid package:
http://packages.debian.org/sid/nut

only x86 and amd64 are available ATM.

So I guess the end result is: this bug may be fixed in the upstream,
> but ubuntu doesn't have the fix in yet? I also noticed that intrepid is
> so far using the same version as hardy.
>

nut 2.2.2 is entering Sid.
a sync has to be requested for Intrepid...

Arnaud

Revision history for this message
Chuck Short (zulcss) wrote :

Hi,

Thanks for the bug report. Can you try the package from my archive? (http://launchpad.net/~zulcss/+archive.

Thanks
chuck

Changed in nut:
status: New → Incomplete
Revision history for this message
Chuck Short (zulcss) wrote :

Any feedback would be great.

Thanks
chuck

Revision history for this message
Doug Minderhout (doug-minderhout) wrote :

I have the same problem with the same ups. The link to the issue on the mailing list is here: http://<email address hidden>/msg03559.html

I will try and install your package and see of that fixes it. I also just downloaded the source for 2.2.2 which seems to have the fix as well. An updated package for 2.2.2 would be really nice....

Revision history for this message
Arnaud Quette (aquette) wrote : Re: [Bug 239025] Re: usbhid-ups not behaving with Tripplite UPS

2008/7/5 Doug Minderhout

> ...

An updated package for 2.2.2 would be really nice....
>

2.2.2-3 is in Debian, so you should request a sync.
note that I have a -4 upload scheduled later this week or the next.

Revision history for this message
Doug Minderhout (doug-minderhout) wrote :

Chuck, I tried your package, but I don't have a usbhid-ups file in my drivers directory. Am I missing something? I installed nut_2.2.1-2.1ubuntu7.2~ppa1_amd64.deb but I get this instaling nut-hal-drivers_2.2.1-2.1ubuntu7.2~ppa1_amd64.deb

root@leviathan:/usr/src/nut# dpkg -i nut-hal-drivers_2.2.1-2.1ubuntu7.2~ppa1_amd64.deb
dpkg: regarding nut-hal-drivers_2.2.1-2.1ubuntu7.2~ppa1_amd64.deb containing nut-hal-drivers:
 nut-hal-drivers conflicts with nut
  nut (version 2.2.1-2.1ubuntu7.2~ppa1) is present and installed.
dpkg: error processing nut-hal-drivers_2.2.1-2.1ubuntu7.2~ppa1_amd64.deb (--install):
 conflicting packages - not installing nut-hal-drivers
Errors were encountered while processing:
 nut-hal-drivers_2.2.1-2.1ubuntu7.2~ppa1_amd64.deb

Also, this seems to be for 7.2, is there a different version for 8.04?

Arnaud, you are correct in that I should request a sync. Unfortunately I had to google what that is :) I am really loaded up right now and I barely have time to get this working. If no one else had requested it by the time my business settles down (perhaps another week) I will go through the process of figuring out how to do that and request a sync.

Revision history for this message
R. C. Pao (rcpao) wrote :

Chuck Short:

dget http://launchpadlibrarian.net/15690206/nut_2.2.1-2.1ubuntu7.2~ppa1.dsc does not get the orig.tar.gz or diff.gz correctly. Of course, it's not really a repository, so the directory paths being different from the *.dsc file may be unavoidable.
rcpao@bun:~/pub/inet/Linux/networkupstools.org$ sh 01-dget.sh
dget: retrieving http://launchpadlibrarian.net/15690206/nut_2.2.1-2.1ubuntu7.2~ppa1.dsc
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
100 1023 100 1023 0 0 2687 0 --:--:-- --:--:-- --:--:-- 0
dget: retrieving http://launchpadlibrarian.net/15690206/nut_2.2.1.orig.tar.gz
  % Total % Received % Xferd Average Speed Time Time Time Current
                                 Dload Upload Total Spent Left Speed
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404
dget: curl nut_2.2.1.orig.tar.gz http://launchpadlibrarian.net/15690206/nut_2.2.1.orig.tar.gz failed
rcpao@bun:~/pub/inet/Linux/networkupstools.org$

I successfully downloaded nut_2.2.1-2.1ubuntu7.2~ppa1.dsc, the orig.tar.gz, and the diff.gz from https://launchpad.net/~zulcss/+archive manually.

dpkg-source -x *.dsc
cd nut-2.2.1
dpkg-buildpackage -rfakeroot
cd ..

successfully built nut-2.2.1/drivers/usbhid-ups. Copying it into /lib/nut/ and replacing the existing file from Ubuntu 8.04.1, works:

...
Path: UPS.OutletSystem.Outlet.DelayBeforeReboot, Type: Feature, ReportID: 0x17, Offset: 0, Size: 16, Value: 65535.000000
Detected a UPS: Tripp Lite /TRIPP LITE UPS
upsdrv_initinfo...
upsdrv_updateinfo...
Quick update...
upsdrv_updateinfo...
Quick update...
upsdrv_updateinfo...
...

root@bun:/etc/nut# upsc bunups@localhost ups.status
OL CHRG
root@bun:/etc/nut# upsc bunups@localhost battery.charge
100
root@bun:/etc/nut#

Installing the nut and nut-cgi*_i386.deb from my recompile also works.

Bottom line: I can say your PPA fixes the infinite loop problem on this UPS.

Revision history for this message
R. C. Pao (rcpao) wrote :

Chuck Short:

One thing I noticed with your PPA is that the battery.charge alternates between 100 and 0 quite often:

upsc bunups@localhost battery.charge
0
root@bun:/etc/init.d# upsc bunups@localhost battery.charge
100
root@bun:/etc/init.d# upsc bunups@localhost battery.charge
100
root@bun:/etc/init.d# upsc bunups@localhost battery.charge
0
root@bun:/etc/init.d# upsc bunups@localhost battery.charge
0
root@bun:/etc/init.d# upsc bunups@localhost battery.charge
0

Revision history for this message
Dimitrios Symeonidis (azimout) wrote :

marking as "fix committed", since the new version of nut fixes this. however, I see that jaunty will have the same 2.2.2 version of nut as intrepid, instead of the newer 2.4.0 one... (http://www.networkupstools.org/)

Changed in nut:
status: Incomplete → Fix Committed
Revision history for this message
Arnaud Quette (aquette) wrote :

2009/2/19 Dimitrios Symeonidis <email address hidden>

> marking as "fix committed", since the new version of nut fixes this.
> however, I see that jaunty will have the same 2.2.2 version of nut as
> intrepid, instead of the newer 2.4.0 one...
> (http://www.networkupstools.org/)
>

I've released and uploaded 2.4.1 to Debian, but since it adds a new package
(nut-powerman-pdu ; I've left aside the 3 other nut-clients, python-pynut
and python-nut-gui to speed up the process...), its inclusion in Debian is
delayed.

I've forwarded the source to Dustin to be in time for jaunty freeze, but the
timezone lag doesn't help.

-- Arnaud

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nut - 2.4.1-2ubuntu1

---------------
nut (2.4.1-2ubuntu1) jaunty; urgency=low

  * Acknowledge closed bugs in upstream and Debian: LP: #1568, LP: #221737,
    LP: #239025, LP: #278495, LP: #332030, LP: #332032
  * Merge from debian unstable, remaining changes:
    + debian/control:
      - Update maintainer field as per spec.
      - Add Breaks on nut-hal-drivers to ensure we have correct udev version.
    + debian/{nut-cgi,nut}.postinst: add nut to the dialout and nut groups
      unconditionally, to handle the upgrade from the hardy release (simply
      uncommented).
    + debian/rules: pre merge the changes for Ubuntu (udev path and version),
      (simply uncommented).

 -- Arnaud Quette <email address hidden> Fri, 27 Feb 2009 12:49:24 +0100

Changed in nut:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.