Hi Massimo and Greg,<br><br><div class="gmail_quote">2012/8/9 Massimo Gais <span dir="ltr"><<a href="mailto:simosagi9@gmail.com" target="_blank">simosagi9@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Aug 8, 2012 at 1:32 PM, Greg Vickers <<a href="mailto:daehenoc@iinet.net.au">daehenoc@iinet.net.au</a>> wrote:<br>
> Fantastic Massimo, thank you! I have yet to replace my 5110, so if there is<br>
> anything I can contribute, I will do.<br>
><br>
> It looks like the only difference between our systems is the kernel version<br>
> (I've put the latest rasbian image on, which has kernel 3.2.0-3-rpi).<br>
><br>
</div>Maybe the problem is specific to the RPi USB.<br>
<br>
This is the debug from my UPS plugged to old faithful NSLU2, when I<br>
launch the command "/lib/nut/bcmxcp_usb -DDD -a ups":<br>
(...)<br>
0.812160 get_answer: block_number = 1<br>
0.812220 get_answer: data length = 121<br>
0.812281 get_answer: need to read 6 more data<br>
0.814929 get_answer: (128 bytes) => ab 01 79 01 02 50 00 50 01 00<br>
0e 00 01 00 10 50<br>
0.815110 4f 57 45 52 57 41 52 45 20 55 50 53 20 20 20 5c 00 00 00<br>
00 00 00 00 00 00<br>
0.815237 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51<br>
51 00 00 00 00 51<br>
0.815357 00 00 00 00 00 00 00 f0 00 f0 00 00 00 f0 00 00 00 00 00<br>
00 00 00 f0 00 00<br>
0.815475 00 00 00 00 00 00 51 00 00 51 00 00 00 00 00 00 00 00 00<br>
f0 00 00 00 00 00<br>
0.815561 00 00 00 00 00 00 00 f0 18 3b ab 01<br>
0.815611 get_answer: block_number = 1<br>
0.815673 get_answer: data length = 121<br>
0.815721 get_answer: sequence number (1) is ok<br>
0.815777 get_answer: checksum is ok<br>
0.815852 get_answer: block_number = 1<br>
0.815915 get_answer: data length = 0<br>
0.815975 Communications with UPS lost: get_answer: not the right<br>
sequence received 0!!!<br>
...<br>
(then the driver tries a few more times to repeat the operation, but<br>
it fails the same way, and then about by timeout)<br>
<br>
It seems that for some reason the call to usb_interrupt_read()<br>
function is able only to 'nibble' 8 bytes at a time,</blockquote><div><br>not an issue, since I've modified the loop to be able to receive as many frames as needed.<br>but the condition to continue receiving is not suitable for your case.<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> instead of<br>
receiving the whole 171 bytes transfer in one single gulp.<br></blockquote><div><br>thus, the data of the 2nd sequence is missing (after "3b ab 01"):<br>28 82 c0 01 00 02 00 00 80 0f 00 00 00<br>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<br>
00 00 0b 00 6b<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Looking at dmesg, I see that on RPi the USB is handled by dwc_otg<br>
driver, instead of the usual ohci_hcd, and on RPi forums they noticed<br>
that there is some issue with it, like... that dwc_otg generates on<br>
idle 8000 interrupts per second!<br>
I'm not too expert on USB things, but I wonder if that may affect the<br>
communication with the UPS.<br clear="all"></blockquote></div><br>it will not help, but should not be a big issue for us.<br><br>would you be able to compile code for testing patches?<br>you will then just need to replace the driver on the RPi.<br>
<br>cheers,<br>Arnaud<br>-- <br>Linux / Unix / Opensource Engineering Expert - Eaton - <a href="http://opensource.eaton.com" target="_blank">http://opensource.eaton.com</a><br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org" target="_blank">http://www.networkupstools.org</a><br>
Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>Free Software Developer - <a href="http://arnaud.quette.fr" target="_blank">http://arnaud.quette.fr</a><br><br>