[Nut-upsdev] tripplite_usb.c reconnection

Charles Lepple clepple at gmail.com
Sat Jun 23 03:46:54 UTC 2007

On 6/21/07, Arjen de Korte <nut+devel at de-korte.org> wrote:
> >> The same remarks as for the reconnect_ups() patch for usbhid-ups.c go
> >> for
> >> the function with the same name in tripplite_usb.c. This is also
> >> blocking
> >> and thereby locking up the communication between driver and server. I
> >> don't think this is intentional, since the MAX_RECONNECT_TRIES in
> >> usb_comm_fail() is effectively a no-op then. I also seems to duplicate
> >> some things in usb_comm_fail(), like upsdrv_cleanup().
> >
> > Thanks for pointing this out - I had forgotten that this code was
> > pretty much copied fron usbhid-ups/newhidups, and thus needed to be
> > fixed as well.
> >
> > However, I'm not sure I caught the resolution of the problem. Should I
> > just take out the retry? The retry logic is a little simpler in
> > tripplite_usb in that reconnect_ups() only gets called in one place
> > (usb_comm_fail()).
> Well, basically you should never hang around in upsdrv_updateinfo(). So if
> something isn't working out as expected, instead of calling sleep and
> retrying, you should return back to main() and wait for the next time
> upsdrv_updateinfo() gets called again to try again. So any while loop with
> a sleep in it is out.

I think I got it now.

Tested with various amounts of time plugging and unplugging the UPS,
and it goes from "Data stale" to "Driver not connected" once the retry
count is exceeded. Let me know if it still looks wrong.


- Charles Lepple

More information about the Nut-upsdev mailing list