Citeren Alexey Loukianov <[email protected]>:
1. megatec_usb and blazer_usb both read up data in 8-byte chunks.
Winpower do it in one large chunk.
This depends on what the interrupt endpoint supports. Both megatec_usb
and blazer_usb can be used for widely different UPS makes and models.
Not all support reading more than 8 bytes at a time (in fact, most
don't). See the output of 'lsusb -vvv' for your UPS and lookup the
following:
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
The collection of data when reading from the interrupt endpoint is
possibly dealt with through some libusb implementations, but it is
safer to do this in the driver itself.
2. blazer_usb tries to flush read buffer of controller before
sending a command.
This is needed by some devices supported through this driver.
In the end I've got working blazer_usb on CentOS4 with stock libusb
(0.1.8). Key
point was to read up data in one 64 byte chunk. It is still unclear
why does the
data got corrupted in megatec_usb when read up in 8-bytes chunks,
and why does
the device hang when using original blazer_usb with buffer-flush and 8-byte
chunks read.
Most likely, the interrupt endpoint stalls. Since the flushing so far
didn't clear stall conditions, it may hang. Improved now, thanks for
the hint.
1. blazer_usb driver from SVN HEAD works correctly with USB Ippon UPSes on
CentOS4, but require libusb version update. Version 0.1.12 from
CentOS5 will do.
Good. Thanks for the report.
2. megatec_usb driver somehow fails to read up correct data from USB
device. The
cause of data corruption is unclear for me as it seems that the steps
megatec_usb driver takes to read up data are almost the same as
blazer_usb take.
There is an error in the way how the megatec_usb driver deals with
replies shorter than the 8 bytes it asks for.
3. It is possible to make blazer_usb work with RHEL4 version of
libusb (0.1.8),
but it require modifications to the way it work. The patch that works on my
setup is attached to this message.
Thanks for the patch, but that will badly break other devices with the
same VID:PID combination. Therefor, this is not an option.
Best regards, Arjen
--
Please keep list traffic on the list
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev