Citeren Daniel O'Connor <[email protected]>:

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.

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.

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.

I found when I was using libusb I could not detect if a device went away
directly, in the end I settled for trying to read a string descriptor -
since this is a mandatory operation a device always supports if it
fails it indicates a catastrophic problem. (The lack of decent error
codes in libusb [or maybe the FreeBSD version] is rather irritating).

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

Best regards, Arjen

PS  The logs you're posting seem to be gzipped twice. This is very confusing.
--
Please keep list traffic on the list


_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

Reply via email to