[Nut-upsdev] Driver bestfcom - Timing problem with Fortress LI1420

[Arjen de Korte]

[...]

> Am I the only one facing this? Or is my UPS (manufactured 1998) the last
> of it's kind?

Looking at the sources, it looks this this problem was created with the
conversion to the new ser_* functions a couple of years ago. Given the age
of your UPS, chances are that this isn't a very popular one anymore, so
you may indeed be the first to notice that there is something wrong.

The problems are (as you empirically found out as well) in the timeouts
used in the driver:

173	ser_get_line(upsfd, buf, sizeof(buf), '\012', "", 0, 20);
189	ser_get_line_alert(upsfd, buf, sizeof(buf), '\012', "",
190		POLL_ALERT, alert_handler, 0, 20);
195	for (ch = '\0'; ch != '\012'; ser_get_char(upsfd, &ch, 0, 10));

The first problem is that the person that converted these functions from
an earlier version probably assumed that the timeout values here are
defined in seconds and milliseconds. The first is true, but the second
value reads in microseconds. In practice this will mean that these
functions will not wait at all and immediately timeout. This could have
been detected, but unfortunately in none of these cases is checked for the
return value (problem number two). Adding a lot of delay (like you did)
fixes this, by allowing the serial buffers in the kernel to receive all
the characters that the UPS sends, before doing the reads, so no
additional delays are needed and they will work as intended.

Could you try if fixing this (instead of adding these 1 second sleeps) by
changing the above calls in the driver to

173	ser_get_line(upsfd, buf, sizeof(buf), '\012', "", 0, 20000);
189	ser_get_line_alert(upsfd, buf, sizeof(buf), '\012', "",
190		POLL_ALERT, alert_handler, 0, 20000);
195	for (ch = '\0'; ch != '\012'; ser_get_char(upsfd, &ch, 0, 10000));

fixes this problem?

The reason why I don't want to use your patch ad verbatim, is that
unconditional 1 second sleeps makes the driver very sluggish, to the point
that we may get into trouble with the connection to the sever. It probably
isn't needed either.

Thanks for your efforts in diagnosing this problem, anyway.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57