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-0000: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 -DDDDD -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 R&D - 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
