[Nut-upsuser] FreeBSD usbhid-ups problem

[Daniel O'Connor]

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

Sounds good!

> 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
> itself)
> 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
Type: application/pgp-signature
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