Arnaud Quette arnaud.quette at gmail.com
Thu Apr 9 10:02:52 UTC 2015


2015-04-09 1:46 GMT+02:00 Charles Lepple <clepple at gmail.com>:

> On Apr 8, 2015, at 2:04 PM, Eric Cobb <Eric_Cobb at tripplite.com> wrote:
> Charles and list,
> If I leave the driver alone it does not eventually start.  It continues to
> report that it is unable to connect.  I have to perform a upsdrvctl stop ;
> upsdrvctl start (I actually just perform a init stop and start so that upsd
> and upsmon both restart) for the driver to actually connect to the ups.
> I have attached an strace of the upsdrvctl start command when it is ran at
> boot time via the init script. I'll let the experts make their assessment
> of what is going wrong.
> Here is the exact line out of the /etc/init.d/ups that i ran (I added -D
> and -u nut on the latest runs, I get the same issue with or without it) Let
> me know if you would like any further symptoms or output.
> start() {
>         echo -n $"Starting UPS Driver:"
>         echo "UPS DRIVER START" > /var/log/upslog
>         strace -f -o /var/log/nut/strace.log /usr/sbin/upsdrvctl -D -u nut
> start >> /var/log/upslog 2>&1 && success || failure
>         RETVAL=$?
>         Echo
> Eric Cobb
> ekcobb at tripplite.com
> The mailing list doesn't accept large attachments, so I attached a gzip'd
> copy of the log in case anyone else wants to take a look.
> It doesn't show timing information, or the content of the URBs, so it is
> hard to tell what the driver is trying to do at any given point.
> I recognize that it is a slight change of the experiment to remove
> upsdrvctl, but could you please start the driver directly in the init
> script with -DDD (path should be in the output of '/usr/sbin/upsdrvctl
> -D'), and redirect that output to a log file? (We had a reason for why
> upsdrvctl does not pass '-D' flags through to the driver, but the reason
> escapes me at the moment.)

simply debugging the driver controller in itself, more than passing the
debug flags to the driver(s)
that said, this point keeps on getting back, on and on.
RFC: we should probably consider for upsdrvctl that -D... is passed to the
driver(s) and -d... for upsdrvctl specifics.
there is no big issue with breaking backward compat here, so if that suits
you all, we can go on implementing that...

> It would also be useful to have the output of dmesg (or at least the
> USB-related subset), in case it has additional information on why
> libusb_get_interrupt() is failing.

2nded, along with your comment that I don't see any difference between
drivers startup process at boot time or later on, WRT to the mentioned
the only point I also see would be some noise (interferences) tied to other
processes looking at USB devices.

Beside from Charles requested test, I would advise you to try increasing
the USB_TIMEOUT value (in usb-common.h) to see if it's just an transient
lack of responsiveness due to some kind of race to access USB devices...

Eaton Data Center Automation - Opensource Leader
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150409/e92a15c3/attachment.html>

More information about the Nut-upsdev mailing list