Arnaud Quette wrote: > reported through launchpad: https://bugs.launchpad.net/bugs/253999 > the possible regression is between nut 2.0.1 (sarge) and 2.2.1 > (confirmed Jamie?) > > @Arjen: it may be related to some of your changes there... > No way. If you don't override in- or output signals, the only relevant changes between 2.0.1 and 2.2.1 are the following: > @@ -116,7 +143,8 @@ > ret = ioctl(upsfd, TIOCMGET, &flags); > > if (ret != 0) { > - upslog(LOG_INFO, "ioctl failed"); > + upslog_with_errno(LOG_INFO, "ioctl failed"); > + ser_comm_fail("Status read failed"); > dstate_datastale(); > return; > } > @@ -135,6 +163,10 @@ > status_set("OB"); /* on battery */ > > status_commit(); > + > + upsdebugx(5, "ups.status: %s %s\n", ol ? "OL" : "OB", bl ? "BL" : > ""); > + > + ser_comm_good(); > dstate_dataok(); > } Neither has any impact on the monitoring of the UPS, the only change you might see is that we now use the ser_comm_fail() and ser_comm_good() functions, so on the server you might see some activity if the ioctl() call is failing (and will be more verbose then). > @Jamie: we'll need some debug output from the drivers (-DDD) > What would be more interesting here, are the logs from the server. If you run the driver at debug level 5 (-DDDDD), you will see what it is reporting to the server.
Since 'upsmon' is reporting OL/OB status changes, the ioctl() calls must be succesful (it would be complaining about stale data otherwise). Which means that the problem is either in the kernel driver for the RS-232 port, the serial port itself, the cable or the UPS. A serial breakout box with colored LEDs indicating the status of the lines would be very helpful here to diagnose where things go wrong. Best regards, Arjen _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
