[Nut-upsdev] Cyberpower 900AVR/BC900D newhidups problem
Peter Selinger
selinger at mathstat.dal.ca
Mon Apr 17 16:17:41 UTC 2006
Hi Lincoln,
I agree that it might be a low-level communications problem. So far,
the problem is not whether newhidups supports this device; rather, you
don't seem to be getting any useful information from it.
On Feb 9, I sent a program "get_descriptor" to Gordon Rowell on this
Nut-upsdev mailing list. Could you run that program (as root), to try
to get the low-level info from the device? I need the output of stuff
like the following:
get_descriptor 002 002 1 0 0 128 0x21 0
get_descriptor 002 002 1 0 0 128 0x22 0
(substitute the device's bus/device address instead of 002 002). You
might also try 129 instead of 128.
-- Peter
Lincoln Turner wrote:
>
> > > HID descriptor too short (expected 8, got 0)
> >
> > What does 'lsusb -vvv' say after the kernel usbhid driver is detached?
> > (i.e. if you unplug and replug the device, make sure that you re-run
> > newhidups once before running lsusb).
>
> Well I detached it thoroughly by rmmoding usbhid altogether. Then
> running lsusb -vvv gives (the relevant bits anyway):
>
> Bus 002 Device 002: ID 0764:0005 Cyber Power System, Inc. Cyber Power UPS
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 1.10
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 8
> idVendor 0x0764 Cyber Power System, Inc.
> idProduct 0x0005 Cyber Power UPS
> bcdDevice 4.00
> iManufacturer 3
> iProduct 1
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 41
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0x80
> MaxPower 20mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 3 Human Interface Devices
> bInterfaceSubClass 0 No Subclass
> bInterfaceProtocol 0 None
> iInterface 0
> HID Device Descriptor:
> bLength 9
> bDescriptorType 33
> bcdHID 1.10
> bCountryCode 33 US
> bNumDescriptors 1
> bDescriptorType 34 Report
> wDescriptorLength 90
> Report Descriptors:
> ** UNAVAILABLE **
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0008 1x 8 bytes
> bInterval 10
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0008 1x 8 bytes
> bInterval 10
>
> But I get this sort of thing from the kernel:
>
> usb 2-2: lsusb timed out on ep0in len=0/255
> usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 6 len 255 ret -110
> usb 2-2: lsusb timed out on ep0in len=0/255
> usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 128 rq 6 len 255 ret -110
> usb 2-2: lsusb timed out on ep0in len=0/90
> usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd lsusb rqt 129 rq 6 len 90 ret -110
>
> And lsusb waits for a second or so timeout at the 'Report Descriptors'
> bit, before reporting unavailable.
>
> > > usb 2-2: Product: CPS RS232 USB BRIDGE for UPS
> >
> > This makes me wonder if it is just a USB-to-serial bridge. If that
> > were the case, newhidups would not know how to communicate with it -
> > the cyberpower serial driver would have to be adapted instead.
>
> Yeah, I feared the same thing. But the CPS tech I spoke to was adamant
> that it has the same protocol as the 685avr which is newly supported
> by newhidups.
>
> I have to say I am unimpressed by cyberpower's refusal to release its
> protocol details and disinterest in writing a UPS driver. They said
> they'd be happy to give free UPSs to 'nut people' to reverse engineer,
> just not provide the data. This seems very stupid. I'm inclined to
> take this UPS back and buy an APC ES series. But the cyberpower is
> cheap, so will maybe try one more round of fiddling with it if there
> is anything else you'd suggest.
>
> > > Oh, and I had to comment out these lines in libhid.h to get it to
> > > compile:
> > > /* ensure these exists (required for Solaris 10) */
> > > //#ifndef u_int16_t
> > > // typedef uint16_t u_int16_t;
> > > //#endif
> > > //
> > > //#ifndef u_int8_t
> > > // typedef uint8_t u_int8_t;
> > > //#endif
> > >
> > > ... but I assume these were only relevant to solaris? Or is this a
> > > problem?
> >
> > What was the compilation error? It needs the types on the right-hand
> > side, but they may not have been preprocessor defines. (The proper
> > solution involves some autoconf magic, and I won't have time to fix
> > this myself - any volunteers?)
>
> gcc -I../include -O -Wall -Wsign-compare -c newhidups.c
> In file included from newhidups.c:25:
> libhid.h:46: error: syntax error before "u_int16_t"
> libhid.h:46: warning: useless keyword or type name in empty declaration
> libhid.h:46: warning: empty declaration
> libhid.h:50: error: syntax error before "u_int8_t"
> libhid.h:50: warning: useless keyword or type name in empty declaration
> libhid.h:50: warning: empty declaration
> make: *** [newhidups.o] Error 1
>
> sstreet drivers # gcc -v
> Reading specs from /usr/lib/gcc/i386-pc-linux-gnu/3.4.5/specs
> Configured with: /var/tmp/portage/gcc-3.4.5-r1/work/gcc-3.4.5/configure --prefix=/usr --bindir=/usr/i386-pc-linux-gnu/gcc-bin/3.4.5 --includedir=/usr/lib/gcc/i386-pc-linux-gnu/3.4.5/include --datadir=/usr/share/gcc-data/i386-pc-linux-gnu/3.4.5 --mandir=/usr/share/gcc-data/i386-pc-linux-gnu/3.4.5/man --infodir=/usr/share/gcc-data/i386-pc-linux-gnu/3.4.5/info --with-gxx-include-dir=/usr/lib/gcc/i386-pc-linux-gnu/3.4.5/include/g++-v3 --host=i386-pc-linux-gnu --build=i386-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
> Thread model: posix
> gcc version 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)
>
> libusb is version 0.1.11
>
> Cheers,
>
> Lincoln
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>
More information about the Nut-upsdev
mailing list