[Nut-upsdev] blazer_usb: compatibility with Ippon BackPro UPSes (Phoenix Power Co., Ltd usb-to-serial controller)

Thu Jan 7 05:13:23 UTC 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

06.01.2010 23:04, Arjen de Korte wrote:
>> 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:

Well, that is true and false in the same time. The trouble is that usb-to-serial
implementations that are used in UPSes are totally messed up when it comes to
the compliance with USB standards regarding to HID. So it might be either true
or not that the real MAX_READ_WRITE for device equals to reported 8 bytes.
Winpower software on linux does reads in a chunks larger than 8 bytes and it is
proven to work.

> 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.

Inspecting libusb 0.1.12 sources shows that interrupt reads and control channel
writes are done trough URB queries, and MAX_READ_WRITE is in fact set as a
define to 16KB:

#define MAX_READ_WRITE (16 * 1024)

In case of libusb-0.1.12 reading data in 8-bytes chunks works normally with
Ippon UPSes (unsure about other brands - it should be tested before doing any
commits to SVN), but when using libusb-0.1.8 that is the stock version for RHEL4
reading in 8-bytes chunks makes phoenix usb-to-serial device in Ippon UPSes
hang. I've done some more tests today and it looks like that the real output
buffer size for this UPSes is 64 bytes, and the cause for hang is an attempt to
read from buffer when it hadn't been filled yet. I.e., this UPSes fill output
buffer in 64-byte chunks after receiving commands Q1 and F and they expect it to
be read in one chunk.

>
>> 2. blazer_usb tries to flush read buffer of controller before
>> sending a command.
>
> This is needed by some devices supported through this driver.
>

Sure. With libusb-0.1.12 it is also needed for Ippon UPSes to return correct
replies. Unfortunately this flushing hangs device when using libusb 0.1.8 :-(.

> 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.

If you're thinking about usb_clear_halt as a measure to un-hang the device then
this is not an option. I've tried it in a first place without success. The only
way to bring device back to life in a software way was to do usb_reset and then
reenumerate usbfs and reopen device again.

>> 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.
>

Hmm. That's strange. I've been playing with megatec_usb sources for quite a long
time for now and I'm pretty sure that the data got corrupted somewhere outside
of megatec_usb. Looks like that it happens to be already messed up just after
the usb_interrupt_read call so megatec_usb has nothing to do with it. Am I
missing something? I've been thinking about spending some time with GDB to make
things more clear but I don't like to do gdb debugs off-site (i.e. over SSH,
being far away from the server on the other side of the Moscow) and I'm going to
visit that office on the next week.

>> 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.
>

Well, for now it is possible to add this kind of behavior as an additional usb
subdriver that is not selected by default for this VID:PID combination. People
who need it may activate its usage manually in configs while other will happily
use original phoenix subdriver. If you want I may redo patch in that way. But in
any case before doing this I'm going to make some additional tests as while it
is proven to be working with Q1 and F commands the rest wasn't tested yet. Some
good hopes gives that fact that issuing command upsupported by Ippon UPS  like
"I\r" didn't break anything (device didn't stall) so I hope that the rest will
work as expected also. But I will check it just to be sure.

- -- 
Best regards,
Alexey Loukianov                          mailto:mooroon2 at mail.ru
System Engineer,                            Mob.:+7(926)218-1320
*nix Specialist

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLRW1zAAoJEPB9BOdTkBUL1KYIAJdCdPrv/LtP+NOOh06MY+h8
Lph0hruHKvAlMSTtbDvs4DcGmH19ro8WQklbPZHta5UHWFTyrhgrHIh0FbeXFXzD
tfSnBFJNiKYXP5eZpp3orp7cKpyR8ZsaFl918EakXKFNKi4gbhXLt5xMSP6PIkcb
seRQURrUtW+K0Xf0zxlxxmZB4/28Kf4o8ednuBGvXIDkRKAZYb1ZLV444Mly4ynY
I2Fh6Ce80BUu2y9r6Orxu+CmacDl5Ys43Rj3DmWRBtdtsr8W6YRT/PncJRnQ6Rbt
3LFbFNwMEirPWk5IsC2JrqCvZpeVsFRNGR0yZbJKi800Eq4+RsM5yCi7aqX34x0=
=CUjb
-----END PGP SIGNATURE-----