[Nut-upsuser] FreeBSD usbhid-ups problem
doconnor at gsoft.com.au
Tue Jan 27 12:11:20 UTC 2009
On Tuesday 27 January 2009 20:32:55 Arnaud Quette wrote:
> > I think that the '#ifdef SUN_LIBUSB' should change to "#ifndef linux" -
> > it seems logical to close it before potentially reopening it and it's a
> > Linux bug
> > that this can cause a problem (mitigated by the fact you seem to be able
> > to 'double open' :)
> thanks for this feedback. we can now broaden the above to non linux...
> I've just applied it for the upcoming 2.4.0...
> I still get this every update..
> > USB error: error reading from interrupt endpoint /dev/ugen0.1: Resource
> > temporarily unavailable
> this is for the notifications (aka interrupts, ie data sent by the UPS
> if the control pipe work (for polling), that's fine for the moment.
> btw, which release of libusb are you using?
It is version 0.1.12, although the bsd code is patched.. The code in bsd.c
doesn't look very savoury to my eye though (very poor error handling).
> > Also, I don't understand the underlying problem of the IO error when
> > reading, and the EBUSY the first time it tries to reconnect.
> I don't understand too. maybe a bug in ugen or libusb on FreeBSD?!
> EBUSY might be due to resources not freed quickly enough somewhere.
> the IO error itself has to do with ugen, and I've no clue there.
Yeah.. I suspect there is some impedance mismatch between the libusb API and
FreeBSD's ugen interface..
There is a new USB stack going into FreeBSD although it won't be back ported
so I guess there is reason to make the libusb code less ugly :)
> > usb_set_debug: Setting debugging level to 3 (on)
> > usb_os_find_busses: Found /dev/usb0
> > usb_os_find_busses: Found /dev/usb1
> > usb_os_find_busses: Found /dev/usb2
> > usb_os_find_busses: Found /dev/usb3
> > usb_os_find_busses: Found /dev/usb4
> > usb_os_find_devices: Found /dev/ugen0 on /dev/usb0
> > usb_control_msg: 128 6 512 0 0xbfbfd204 8 1000
> > usb_control_msg: 128 6 512 0 0x8105910 34 1000
> apart from the above, does the communication appears to be somehow stable
> in the time?
Yes, it does cause errors, but it recovers so it is usable.
It does detect when the power goes away although I haven't tried a full
shutdown or anything yet.
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20090127/1f19a764/attachment.pgp
More information about the Nut-upsuser