[Nut-upsuser] FreeBSD usbhid-ups problem

[Arnaud Quette]

Hi Daniel,

2009/1/27 Daniel O'Connor <doconnor at gsoft.com.au>

> On Thursday 25 September 2008 17:56:43 Daniel O'Connor wrote:
> > > you might want to have libusb debug trace also, to see more low level
> > > things. use "export USB_DEBUG=3" before launching usbhid-ups.
> > > you might also have a look at your kernel output for ugen to see if
> > > there is a problem here.
> >
> > Hmm..
> > I get this..
> > usb_control_msg: 161 1 769 0 0x813310c 2 4000
> > USB error: error sending control message: Input/output error
> > Can't retrieve Report 1: Input/output error
> > upsdrv_updateinfo...
> > Got to reconnect!
> >
> > 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: couldn't open device /dev/ugen0: Device busy
> > No appropriate HID device found
> > upsdrv_updateinfo...
> > Got to reconnect!
> >
> > Sorry for the late reply.. :(
>
> I finally got off my arse and tried to fix this today.
>
> I found that enabling the libusb_close (as for Sun) in drivers/libusb.c
> helps
> - it can now reconnect.
>
> 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
itself)
if the control pipe work (for polling), that's fine for the moment.
btw, which release of libusb are you using?

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.

upsdrv_updateinfo...
> USB error: error reading from interrupt endpoint /dev/ugen0.1: Resource
> temporarily unavailable
> Got -35 HID objects...
> Quick update...
> Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, ReportID:
> 0x01, Offset: 0, Size: 1, Value: 1.000000
> Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Feature, ReportID:
> 0x01, Offset: 2, Size: 1, Value: 0.000000
> Path: UPS.PowerSummary.PresentStatus.Charging, Type: Feature, ReportID:
> 0x01, Offset: 1, Size: 1, Value: 1.000000
> Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type:
> Feature, ReportID: 0x01, Offset: 3, Size: 1, Value:
> 0.000000
> upsdrv_updateinfo...
> USB error: error reading from interrupt endpoint /dev/ugen0.1: Resource
> temporarily unavailable
> Got -35 HID objects...
> Quick update...
> usb_control_msg: 161 1 769 0 0x8130100 2 4000
> USB error: error sending control message: Input/output error
> Can't retrieve Report 1: Input/output error
> upsdrv_updateinfo...
> Got to reconnect!
>
> 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: couldn't open device /dev/ugen0: Device busy
> usb_os_close: closing endpoint 5
> No appropriate HID device found
> upsdrv_updateinfo...
> Got to reconnect!
>
> 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?

Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer -
http://people.debian.org/~aquette/<http://people.debian.org/%7Eaquette/>
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20090127/d2ba07a3/attachment.htm