On Mon, 1 Jun 2009, Arjen de Korte wrote: > 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.
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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
