Re: [Nut-upsuser] Support for Online Yunto and Zinto
What can I do next? Thanks, Mario ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC SmartUPS 3000VA LCD not connecting
2012/2/6 Zach La Celle lace...@roboticresearch.com: On 02/03/2012 08:51 PM, Charles Lepple wrote: On Feb 3, 2012, at 3:10 PM, Arnaud Quette wrote: On the USB side of things, something seems fishy with the APC usb connection: it's been incrementing the Device ID, up to 124 from 004. this is not a big issue, and probably due to the 2.4.3 driver. I tend not to agree - the device ID should not increase because of anything the driver is doing. New device IDs are assigned after the kernel gives up while trying to request the standard USB descriptors from the device. Check your USB cable, and also see if there are messages in the kernel log which match the increasing device ID. After looking into it more, it seems that running the usbhid-ups driver is actually causing the device ID to increment. that's what I was suspecting. If I just look at the device under dmesg, I see it sitting in /dev/bus/usb/005/deviceID. Here's an example dmesg output: [252368.035392] usb 5-1: new full speed USB device using uhci_hcd and address 53 [252368.188270] usb 5-1: New USB device found, idVendor=051d, idProduct=0003 [252368.188274] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [252368.188277] usb 5-1: Product: Smart-UPS 3000 FW:UPS 06.5 / ID=18 [252368.188280] usb 5-1: Manufacturer: American Power Conversion [252368.188282] usb 5-1: SerialNumber: IS1134004019 [252368.221312] generic-usb 0003:051D:0003.0037: hiddev96,hidraw4: USB HID v1.00 Device [American Power Conversion Smart-UPS 3000 FW:UPS 06.5 / ID=18] on usb-:00:1d.0-1/input0 When I try to start the driver, I get this message: Network UPS Tools - Generic HID driver 0.35 (2.6.0) USB communication driver 0.31 interrupt pipe disabled (add 'pollonly' flag to 'ups.conf' to get rid of this message) Using subdriver: APC HID 0.95 libusb_get_report: error sending control message: Invalid or incomplete multibyte or wide character I've never seen that one before, though! At this point, the process is running: root@www:/dev/bus/usb/005# ps aux | grep hid nut 6290 0.0 0.0 14820 880 ? Ss 13:47 0:00 /lib/nut/usbhid-ups -a rack1ups And the device ID is incrementing: [252551.896567] usb 5-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 512 ret -71 (lots of these, about 25) [252552.004304] usb 5-1: USB disconnect, address 64 This keeps happening forever, until I kill the process manually. Any ideas on how to debug this further? I believe I'm using all of the correct binaries. To recap, I manually installed the 2.6.0 nut and libupsclient on 10.04, but it seemed to be fine. I'm using the amd64 build. a driver debug output, Ie: $ /lib/nut/usbhid-ups -D -a rack1ups please, compress the result or sent in a reference to the file. I would also be interested in a 2nd run, calling export USB_DEBUG=3, before starting usbhid-ups. we should get some visibility from libusb. cheers, Arnaud -- Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] No shutdown on empty battery
Hi Gerhard, 2012/2/4 Gerhard Strangar g...@arcor.de: Arnaud Quette wrote (2012-02-02 14:13): I did a test with an older version of my UPS, same model, but no USB connector. This time, everything worked fine: Feb 4 12:01:37 b1 upsmon[1494]: UPS upsb1@localhost on battery Feb 4 12:18:52 b1 upsmon[1494]: UPS upsb1@localhost battery is low Feb 4 12:18:52 b1 upsmon[1494]: Executing automatic power-fail shutdown Feb 4 12:18:52 b1 upsmon[1494]: Auto logout and shutdown proceeding [...] Feb 4 12:19:06 b1 upsd[1480]: mainloop: Interrupted system call [...] Feb 4 12:19:10 b1 syslogd: exiting on signal 15 /etc/killpower is cleared at upsmon startup, in case it exists. It was this time, but not when the shutdown had failed. you have not answered to my question on where upsdrvctl shutdown is called in the process? as told, on Debian, it's handled by the halt script. It's in /usr/local/etc/rc.d/nut, which is called when entering shutdown runlevel. I watched the upsc output during that test. It started with do you mean the battery test, or the procedure to test a shutdown sequence, without having your computer powered by the UPS? ups.alarm: INPUT_AC_UNDER_VOLTAGE INPUT_UNDER_OR_OVER_FREQ UTILITY_NOT_PRESENT BATTERY_TOTALLY_DISCHARGED LOAD_DUMPED ups.beeper.status: enabled ups.status: ALARM OB I disabled the beeper with the button at the fron panel, but it still said enabled. The LOAD_DUMPED output is nonsense, this UPS cannot dump load (except for dumping everything, which it didn't) and the battery was not totally discharged when I started the test. LOAD_DUMPED should be mapped to ups.status = OFF, which means that output are not powered anymore. was there any power on the output so? Later on it said: battery.charge: 70 battery.runtime: 95 battery.voltage: 10.49 ups.alarm: INPUT_AC_UNDER_VOLTAGE INPUT_UNDER_OR_OVER_FREQ UTILITY_FAIL UTILITY_NOT_PRESENT BATTERY_TOTALLY_DISCHARGED LOAD_DUMPED ups.status: FSD ALARM OB LB So finally, the utility which was not present (see above) now failed. :-) if this was not the battery test, how long has it take to reach this state? if it was the battery test, it should not cause this with a 30 seconds discharge. I'm still thinking about depleted batteries. I guess, Ill configure that timer thing, just to be sure shutdown works. beware that timer has a static approach that may work for some time... but then fail if your total runtime decrease over time. it's always better to understand the issue, and actually fix it. I would need a debug output of the driver for the above test, Ie: $ /path/to/bcmxcp_usb -D -a upsb1 and an upsc output, to get the general context (ups.load, base battery.runtime, ...). cheers, Arnaud -- Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC SmartUPS 3000VA LCD not connecting
On 02/07/2012 10:41 AM, Arnaud Quette wrote: 2012/2/6 Zach La Celle lace...@roboticresearch.com: On 02/03/2012 08:51 PM, Charles Lepple wrote: On Feb 3, 2012, at 3:10 PM, Arnaud Quette wrote: On the USB side of things, something seems fishy with the APC usb connection: it's been incrementing the Device ID, up to 124 from 004. this is not a big issue, and probably due to the 2.4.3 driver. I tend not to agree - the device ID should not increase because of anything the driver is doing. New device IDs are assigned after the kernel gives up while trying to request the standard USB descriptors from the device. Check your USB cable, and also see if there are messages in the kernel log which match the increasing device ID. After looking into it more, it seems that running the usbhid-ups driver is actually causing the device ID to increment. that's what I was suspecting. If I just look at the device under dmesg, I see it sitting in /dev/bus/usb/005/deviceID. Here's an example dmesg output: [252368.035392] usb 5-1: new full speed USB device using uhci_hcd and address 53 [252368.188270] usb 5-1: New USB device found, idVendor=051d, idProduct=0003 [252368.188274] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [252368.188277] usb 5-1: Product: Smart-UPS 3000 FW:UPS 06.5 / ID=18 [252368.188280] usb 5-1: Manufacturer: American Power Conversion [252368.188282] usb 5-1: SerialNumber: IS1134004019 [252368.221312] generic-usb 0003:051D:0003.0037: hiddev96,hidraw4: USB HID v1.00 Device [American Power Conversion Smart-UPS 3000 FW:UPS 06.5 / ID=18] on usb-:00:1d.0-1/input0 When I try to start the driver, I get this message: Network UPS Tools - Generic HID driver 0.35 (2.6.0) USB communication driver 0.31 interrupt pipe disabled (add 'pollonly' flag to 'ups.conf' to get rid of this message) Using subdriver: APC HID 0.95 libusb_get_report: error sending control message: Invalid or incomplete multibyte or wide character I've never seen that one before, though! At this point, the process is running: root@www:/dev/bus/usb/005# ps aux | grep hid nut 6290 0.0 0.0 14820 880 ?Ss 13:47 0:00 /lib/nut/usbhid-ups -a rack1ups And the device ID is incrementing: [252551.896567] usb 5-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 512 ret -71 (lots of these, about 25) [252552.004304] usb 5-1: USB disconnect, address 64 This keeps happening forever, until I kill the process manually. Any ideas on how to debug this further? I believe I'm using all of the correct binaries. To recap, I manually installed the 2.6.0 nut and libupsclient on 10.04, but it seemed to be fine. I'm using the amd64 build. a driver debug output, Ie: $ /lib/nut/usbhid-ups -D -a rack1ups please, compress the result or sent in a reference to the file. I would also be interested in a 2nd run, calling export USB_DEBUG=3, before starting usbhid-ups. we should get some visibility from libusb. cheers, Arnaud I've put up two files: one without USB_DEBUG=3, and one with USB_DEBUG=3. Without: http://db.tt/55mUqzJA With: http://db.tt/Rcf2Phv6 I hope this helps! -Zach ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] No shutdown on empty battery
Arnaud Quette wrote (2012-02-07 16:56): I watched the upsc output during that test. It started with do you mean the battery test, or the procedure to test a shutdown sequence, without having your computer powered by the UPS? The shutdown test as you suggested. Except for a little modification: I pulled the RS-232 cable from the original UPS to keep everything running and connected it to a spare one - same model though. LOAD_DUMPED should be mapped to ups.status = OFF, which means that output are not powered anymore. was there any power on the output so? The lamp connected to the UPS was lit all the time. So finally, the utility which was not present (see above) now failed. :-) if this was not the battery test, how long has it take to reach this state? First I ran with something that consumed too little power for about five minutes. Then I added load up to 80 VA and ran with that load for another five and a half minutes. The spare UPS was stored disconnected for at least half a year, it was cold and it said 90% battery when I connected the RS-232 cable. it's always better to understand the issue, and actually fix it. The issue is that I had to switch from Solaris to FreeBSD because of increased license costs; I don't think I can fix that. ;-) I would need a debug output of the driver for the above test, Ie: $ /path/to/bcmxcp_usb -D -a upsb1 and an upsc output, to get the general context (ups.load, base battery.runtime, ...). I'll try to do that in about 2 weeks. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
