Nut upsuser - Jan 2008 - Working platform with FreeBSD + USB + MGE Ellipse (usbhid-ups)

Hi,

I've have had some difficulties to run NUT on freebsd, but I finally managed
to
have something that work reliably enough. For those who may be interested,
here is what I did.

Os: FreeBSD 6.2-RELEASE-p7, nut: 2.2.0, libusb: 0.1.12

First, I had to patch libusb with the changes submitted by Nevil Thatcher
in the nutups forum in may 2006. Without this change, nothing works.
(http://lists.alioth.debian.org/pipermail/nut-upsuser/2006-May/000992.html)

At this point, I had something that more or less works, but the USB connection
drops occasionaly for some reasons, and won't recover. I did not trace it
enough
to see what happens, but it seems that something occurs in freebsd kernel
layers that bubbles to the reading process as an "IO error"
(errno=EIO=5).

The reason why it does not recover is still somehow obscurs to me, but
I'm pretty much convinced it is related to the way the libusb layer
deal with re-initialization. I'm new to this library, but it looks like
the function usb_init(); (and friends) is not designed to run more than
once in the process lifetime.

Instead of "fixing" those parts, which would have taken a lot of time,
I used another approach: I implemented a "respawn" option for the
driver
process, which automatically restarts the process when it exits. I also
did a few changes in the driver code so that it exits whenever a USB
connection problem occurs.

At this point, I have something that works reliably enough. Using my
UPS (MGE ellipse 750), I see about 20 losses of connection per day,
and the system takes between 5 and 10s to recover.

I did another change which is more cosmetic than anything else. In order
to keep short reconnections silents (in my logging system), I added a
grace period that delays the COMMBAD event. If the system recovers before
this period, no event is issued.

- Herv?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: nut.patches.shar
Type: application/x-shar
Size: 16812 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20080107/f4c8cbab/attachment.shar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libusb.patches.shar
Type: application/x-shar
Size: 2255 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20080107/f4c8cbab/attachment-0001.shar

> -----Original Message-----
> From: 
> nut-upsuser-bounces+support=ocg.ca at lists.alioth.debian.org 
> [mailto:nut-upsuser-bounces+support=ocg.ca at lists.alioth.debian
> .org] On Behalf Of herve-nut at mindstep.com
> Sent: Monday, January 07, 2008 5:21 AM
> To: nut-upsuser at lists.alioth.debian.org
> Subject: [Nut-upsuser] Working platform with FreeBSD + USB + 
> MGE Ellipse(usbhid-ups)
> 
> Hi,
> 
> I've have had some difficulties to run NUT on freebsd, but I 
> finally managed to have something that work reliably enough. 
> For those who may be interested, here is what I did.
> 
> Os: FreeBSD 6.2-RELEASE-p7, nut: 2.2.0, libusb: 0.1.12
> 
> First, I had to patch libusb with the changes submitted by 
> Nevil Thatcher in the nutups forum in may 2006. Without this 
> change, nothing works.
> (http://lists.alioth.debian.org/pipermail/nut-upsuser/2006-May
> /000992.html)
> 
> At this point, I had something that more or less works, but 
> the USB connection drops occasionaly for some reasons, and 
> won't recover. I did not trace it enough to see what happens, 
> but it seems that something occurs in freebsd kernel layers 
> that bubbles to the reading process as an "IO error"
(errno=EIO=5).
> 
> The reason why it does not recover is still somehow obscurs 
> to me, but I'm pretty much convinced it is related to the way 
> the libusb layer deal with re-initialization. I'm new to this 
> library, but it looks like the function usb_init(); (and 
> friends) is not designed to run more than once in the process 
> lifetime.
> 
> Instead of "fixing" those parts, which would have taken a lot 
> of time, I used another approach: I implemented a "respawn" 
> option for the driver process, which automatically restarts 
> the process when it exits. I also did a few changes in the 
> driver code so that it exits whenever a USB connection problem occurs.
> 
> At this point, I have something that works reliably enough. 
> Using my UPS (MGE ellipse 750), I see about 20 losses of 
> connection per day, and the system takes between 5 and 10s to recover.
> 
> I did another change which is more cosmetic than anything 
> else. In order to keep short reconnections silents (in my 
> logging system), I added a grace period that delays the 
> COMMBAD event. If the system recovers before this period, no 
> event is issued.
> 
> - Herv?
> 
> 
>