[Nut-upsdev] USB comms dropout not detected
Arjen de Korte
nut+devel at de-korte.org
Mon Jun 1 08:27:16 UTC 2009
Citeren Daniel O'Connor <doconnor op 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.
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
> 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
> 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
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
More information about the Nut-upsdev