[Nut-upsuser] 2 different APC UPS using USB get in power off recoverable state

[Bendtsen, Jon]

On 03/01/2012, at 14.15, Charles Lepple wrote:
> On Jan 3, 2012, at 8:03 AM, Bendtsen, Jon wrote:
> 
>> Hi
>> 
>> Yesterday I had 2 different APC UPS using USB get in power off recoverable state.
>> 
>> dmesg said:
>> 
> [...]
>> [7706011.117044] usb 2-1: new low speed USB device using uhci_hcd and address 9
>> [7706011.529059] usb 2-1: device not accepting address 9, error -71
>> [7706011.529104] hub 2-0:1.0: unable to enumerate USB device on port 1
> 
> Unfortunately, there is nothing that NUT will be able to do to recover from that state, since the kernel has not fully recognized the USB device at that point.

I know. I just posted incase others run into this problem.


> It is possible that we are sending an unexpected command, though. Did this happen as a result of a power-down command from NUT, or did they just drop off the bus on their own? If it was a commanded power-down, do you have anything in your shutdown scripts other than the normally suggested NUT commands (i.e. upsdrvctl shutdown, or calling the driver with "-k")?

I am unsure how it got into this state, but it is quite possible that the UPSes and/or USB received some strange commands, because the microSD card that I used for the NUT installation (and nagios) was strange. I had to insert a different microSD card and restore from the same old microSD card inserted into a x86 linux server (because the backup server was running fsck.ext3 for 14 hours (pick some other filesystem, like XFS))


>> The machine is a guruplug server plus, running debian lenny on armtel. Linux dkplugbab9 2.6.32-00007-g56678ec #1 PREEMPT Mon Feb 8 03:49:55 PST 2010 armv5tel GNU/Linux
>> 
>> I have hand installed Network UPS Tools upsstats 2.4.3 from source.
>> 
>> ups.conf:
>> [apc1500]
>> driver = usbhid-ups
>> port = auto
>> serial=AS0535132782
>> # powers switches and routers
>> 
>> [Smart-UPS_3000]
>> driver = usbhid-ups
>> port = auto
>> serial=JS1030003421
>> 
>> [R3000XR]
>> port = /dev/ttyUSB0
>> driver = bcmxcp
> 
> Interesting that the USB-to-serial unit (R3000XR) was not affected. But I imagine that the units monitored by usbhid-ups are fairly different inside.

I think they are different, since the R3000XR is an HP UPS.


>> The R3000XR did work, but neither apc1500 nor Smart-UPS_3000. I tried restarting nut, I tried in other linux servers (just plugging in and seeing dmesg).
> 
> Did you happen to try on any non-ARM servers? (I'm generally suspicious of the USB controllers on ARM hardware, but I have nothing substantial to back that up.)

Yes I did try with both the 1500 and 3000 in a x86 running debian squeeze, dmesg gave similar output. Motherboard in that machine is probably an asus desktop style motherboard and the CPU a P4 3GHz 4GB ram.



JonB