Displaying 4 results from an estimated 4 matches for "reconnect_up".
Did you mean:
reconnect_ups
2007 Jun 21
2
[nut-commits] svn commit r971 - in trunk: . drivers
...d changes to
>
> Modified: trunk/drivers/usbhid-ups.c
> ==============================================================================
> --- trunk/drivers/usbhid-ups.c (original)
> +++ trunk/drivers/usbhid-ups.c Thu Jun 21 07:43:46 2007
> @@ -987,7 +987,7 @@
>
> static void reconnect_ups(void)
> {
> - if (hd == NULL)
> + while (hd == NULL)
^^^^^^^^^^^^^^^^^^
If the communication to the UPS is lost (and can't be established again),
it will stay in this loop forever and therefor never leave the
upsdrv_updateinfo() function. This is bad for two reasons:
#1 The...
2007 Jun 21
1
tripplite_usb.c reconnection
On 6/21/07, Arjen de Korte <nut+devel at de-korte.org> wrote:
> Charles,
>
> 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...
2007 Aug 23
1
[nut-commits] svn commit r1073 - in trunk: . drivers
...to 206) is ultimately a mistake,
albeit one that I am probably responsible for. Would it make sense to
confine libhid to low-level operations, and leave the decision of
trying to reopen vs. retrying to open to the high-level driver, in
this case usbhid-ups?
I envision that the code in usbhid-ups:reconnect_ups() could be
changed to something like:
hd = HIDOpenDevice(&udev, &curDevice, reopen_matcher, MODE_REOPEN);
if (hd == NULL) {
/* reopening failed, try opening new device */
hd = HIDOpenDevice(&udev, &curDevice, regex_matcher, MODE_OPEN);
}
if (hd == NULL) {
return 0;
}
Not...
2007 Jun 21
0
tripplite_usb.c
Charles,
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...