[Nut-upsuser] bcmxcp_usb can not communicate with Eaton Powerware 5110

[Arnaud Quette]

Hi Massimo and Greg,

2012/8/9 Massimo Gais <simosagi9 at gmail.com>

> On Wed, Aug 8, 2012 at 1:32 PM, Greg Vickers <daehenoc at iinet.net.au>
> wrote:
> > Fantastic Massimo, thank you!  I have yet to replace my 5110, so if
> there is
> > anything I can contribute, I will do.
> >
> > It looks like the only difference between our systems is the kernel
> version
> > (I've put the latest rasbian image on, which has kernel 3.2.0-3-rpi).
> >
> Maybe the problem is specific to the RPi USB.
>
> This is the debug from my UPS plugged to old faithful NSLU2, when I
> launch the command "/lib/nut/bcmxcp_usb -DDD -a ups":
> (...)
>    0.812160     get_answer: block_number = 1
>    0.812220     get_answer: data length = 121
>    0.812281     get_answer: need to read 6 more data
>    0.814929     get_answer: (128 bytes) => ab 01 79 01 02 50 00 50 01 00
> 0e 00 01 00 10 50
>    0.815110      4f 57 45 52 57 41 52 45 20 55 50 53 20 20 20 5c 00 00 00
> 00 00 00 00 00 00
>    0.815237      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51
> 51 00 00 00 00 51
>    0.815357      00 00 00 00 00 00 00 f0 00 f0 00 00 00 f0 00 00 00 00 00
> 00 00 00 f0 00 00
>    0.815475      00 00 00 00 00 00 51 00 00 51 00 00 00 00 00 00 00 00 00
> f0 00 00 00 00 00
>    0.815561      00 00 00 00 00 00 00 f0 18 3b ab 01
>    0.815611     get_answer: block_number = 1
>    0.815673     get_answer: data length = 121
>    0.815721     get_answer: sequence number (1) is ok
>    0.815777     get_answer: checksum is ok
>    0.815852     get_answer: block_number = 1
>    0.815915     get_answer: data length = 0
>    0.815975     Communications with UPS lost: get_answer: not the right
> sequence received 0!!!
> ...
> (then the driver tries a few more times to repeat the operation, but
> it fails the same way, and then about by timeout)
>
> It seems that for some reason the call to usb_interrupt_read()
> function is able only to 'nibble' 8 bytes at a time,


not an issue, since I've modified the loop to be able to receive as many
frames as needed.
but the condition to continue receiving is not suitable for your case.


> instead of
> receiving the whole 171 bytes transfer in one single gulp.
>

thus, the data of the 2nd sequence is missing (after "3b ab 01"):
28 82 c0 01 00 02 00 00 80 0f 00 00 00
00 00 00 00 00 00 00 00 00 00 01 00 80 40 00 00 00 00 00 00 03 00 08 16 00
00 00 0b 00 6b


> Looking at dmesg, I see that on RPi the USB is handled by dwc_otg
> driver, instead of the usual ohci_hcd, and on RPi forums they noticed
> that there is some issue with it, like... that dwc_otg generates on
> idle 8000 interrupts per second!
> I'm not too expert on USB things, but I wonder if that may affect the
> communication with the UPS.
>

it will not help, but should not be a big issue for us.

would you be able to compile code for testing patches?
you will then just need to replace the driver on the RPi.

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20120810/6b77d2d8/attachment.html>