Hey 2015-04-09 1:46 GMT+02:00 Charles Lepple <[email protected]>:
> On Apr 8, 2015, at 2:04 PM, Eric Cobb <[email protected]> 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 > [email protected] > > > 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 context. 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... cheers Arno -- 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
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
