Hello everyone,

Here are the output log files as requested.

Eric Cobb
[email protected]

From: [email protected] [mailto:[email protected]] On Behalf Of Arnaud 
Quette
Sent: Thursday, April 09, 2015 5:03 AM
To: Charles Lepple
Cc: Eric Cobb; [email protected]
Subject: Re: [Nut-upsdev] CENTOS 6.6 NUT RPM BUILD ISSUES

Hey

2015-04-09 1:46 GMT+02:00 Charles Lepple 
<[email protected]<mailto:[email protected]>>:
On Apr 8, 2015, at 2:04 PM, Eric Cobb 
<[email protected]<mailto:[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]<mailto:[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
________________________________
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.

Attachment: dmesg.rar
Description: dmesg.rar

Attachment: tripplite.rar
Description: tripplite.rar

_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Reply via email to