[Nut-upsdev] USB comms dropout not detected

[Daniel O'Connor]

On Mon, 1 Jun 2009, Arjen de Korte wrote:
> Citeren Daniel O'Connor <doconnor at gsoft.com.au>:
> > I have an MGE Ellipse 1000 connected to a FreeBSD 7.1 system and it
> > works well except that if I yank the cable it doesn't detect a
> > problem.. It seems to quite merrily read the old data (upsc reports
> > the same values).
>
> That means that the driver doesn't see this and assumes it is
> business as usual. Not so good.
>
> > There is nothing logged by NUT to indicate comms is lost
> > (usbhid-ups is still running).
> >
> > In the attached log I yanked the able at the 28 second mark and
> > plugged it back in at the 48 second mark.
> >
> > It seems that usbhid-ups should know the UPS is no longer present
> > but upsd doesn't seem to DTRT and mark the data stale (or perhaps
> > usbhid-ups is re-sending the old data structure to upsd?).
>
> The usbhid-ups driver doesn't know the 'Device not connected' error
> message means that the UPS is no longer connected. The libusb library
> is fairly verbose with error messages and not all of them are a sign
> of trouble. Therefor, we only assume the UPS is gone for specific
> ones and by default, they are disregarded.

OK fair enough.
libusb is a little slim it seems.. It would be much nicer if it hid this 
system specific detail :(

> If you add this error in the case statement around line 1350 in
> usbhid-ups.c that lists the conditions for reconnecting, you'll
> probably be fine. The driver will then tell the server that the data
> is stale after a couple of tries and reconnect once it is attached
> again.

Yep it works great now thanks!
(I just added case -ENXIO - I don't know if you want to wrap it in a 
#ifdef __FreeBSD__ or not)

> > Also, I think that usbhid-ups should either try reconnecting to the
> > UPS (ie search for a suitable device like it does when starting) or
> > exit after several failed attempts.
>
> It should indeed attempt to reconnect (which it will, if it knows
> this is needed). The latter suggestion is not a good idea, since we
> are not started by a hook in the kernel, so this would require
> operator intervention.

Well, it depends, if the USB devices were run on connection by a daemon 
(eg devd) then it would work fine..

> > I guess really if usbhid-ups exits on error then it should really
> > just be started by some system specific daemon on UPS connection
> > (eg devd in FreeBSD).
>
> We use that for the HAL enabled drivers, but these are more for
> desktop systems since they don't provide a socket for uspd to connect
> to (and therefor aren't much good in case multiple systems are
> connected to a single UPS).

Hmm OK, I would have thought it would run it and connect via upsd as 
normal. (I haven't looked at HAL + NUT yet :)

> PS  The logs you're posting seem to be gzipped twice. This is very
> confusing.

Odd, I did gzip them once before sending.. Maybe my mail client did it 
again?

-- 
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: 188 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20090601/c9ac5413/attachment-0001.pgp>