[Nut-upsdev] tripplite_usb.c reconnection

Charles Lepple clepple at gmail.com
Thu Jun 21 16:21:26 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.

OK, hopefully I will have some time to look at that tonight.

> Problem is that I can't seem to manage SVN properly from
> my end, it refuses to accept any changes to the ServerConf branch I
> created for this purpose, so I guess I'll remove that and commit it again.

If you want, you can send me the error messages you're getting, and
I'll see if it's something that the Alioth admins can fix.

Often, though, it's something that 'svn update' and 'svn cleanup'
should be able to fix.

-- 
- Charles Lepple



More information about the Nut-upsdev mailing list