Hey 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150409/e92a15c3/attachment.html>
Hello everyone,
Here are the output log files as requested.
Eric Cobb
ekcobb at tripplite.com
From: aquette.dev at gmail.com [mailto:aquette.dev at gmail.com] On Behalf Of
Arnaud Quette
Sent: Thursday, April 09, 2015 5:03 AM
To: Charles Lepple
Cc: Eric Cobb; nut-upsdev at lists.alioth.debian.org
Subject: Re: [Nut-upsdev] CENTOS 6.6 NUT RPM BUILD ISSUES
Hey
2015-04-09 1:46 GMT+02:00 Charles Lepple <clepple at
gmail.com<mailto:clepple at gmail.com>>:
On Apr 8, 2015, at 2:04 PM, Eric Cobb <Eric_Cobb at
tripplite.com<mailto: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<mailto: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 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
________________________________
This message is for the addressee's use only. It may contain confidential
information. If you receive this message in error, please delete it and notify
the sender. Tripp Lite disclaims all warranties and liabilities, and assumes no
responsibility for viruses which may infect an email sent to you from Tripp Lite
and which damage your electronic systems or information. It is your
responsibility to maintain virus detection systems to prevent damage to your
electronic systems and information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150413/b7efccf3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.rar
Type: application/octet-stream
Size: 12240 bytes
Desc: dmesg.rar
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150413/b7efccf3/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tripplite.rar
Type: application/octet-stream
Size: 44789 bytes
Desc: tripplite.rar
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150413/b7efccf3/attachment-0003.obj>
On Apr 13, 2015, at 11:51 AM, Eric Cobb <Eric_Cobb at tripplite.com> wrote:> Here are the output log files as requested.[...]> 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. >Hmm, the two logs you attached don't seem to contain the error you mentioned. Was the debug output from boot time? This part of dmesg looks normal: usb 1-1.1: new low speed USB device number 3 using ehci_hcd usb 1-1.1: New USB device found, idVendor=09ae, idProduct=0001 usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1.1: Product: TRIPP LITE SMART500RT1U usb 1-1.1: Manufacturer: Tripp Lite usb 1-1.1: configuration #1 chosen from 1 choice generic-usb 0003:09AE:0001.0001: hiddev96,hidraw0: USB HID v1.10 Device [Tripp Lite TRIPP LITE SMART500RT1U ] on usb-0000:00:16.0-1.1/input0 -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20150413/8ec75ea1/attachment.html>