thr3ads.net - Nut upsuser - [Nut-upsuser] Data Stale at random intervals [Oct 2016]

If this information is useful, please help other people find it:
Share via:

Daniel Shields

2016-Oct-15 03:41 UTC

[Nut-upsuser] Data Stale at random intervals

Hi Charles,


     Thanks for the tip.  I reran the debug again until communication stopped. 
Backtrace is below.  Thanks!



 441.204990     upsdrv_updateinfo...     (Driver stopped communicating)

Broadcast message from nut at golgotha.tklapp.com (somewhere) (Sat Oct 15
03:36:57

UPS nailbunny at localhost is unavailable

^C
Program received signal SIGINT, Interrupt.
0x00007ffff76ec1c7 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff76ec1c7 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff7bd69e5 in ?? () from /lib/x86_64-linux-gnu/libusb-0.1.so.4
#2  0x000000000040659b in ?? ()
#3  0x0000000000405b32 in ?? ()
#4  0x0000000000404340 in ?? ()
#5  0x0000000000402c39 in ?? ()
#6  0x00007ffff762cb45 in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#7  0x0000000000402e4d in ?? ()
(gdb)


________________________________
From: Charles Lepple <clepple at gmail.com>
Sent: Friday, October 14, 2016 10:41 PM
To: Daniel Shields
Cc: nut-upsuser at lists. alioth. debian. org
Subject: Re: [Nut-upsuser] Data Stale at random intervals

On Oct 14, 2016, at 8:53 PM, Daniel Shields <grungelizard9 at
hotmail.com<mailto:grungelizard9 at hotmail.com>> wrote:

Ran with gdb:


gdb /lib/nut/usbhid-ups

run -u nut -a nailbunny -x bus=010 -x vendorid=0764 -x productid=0501 -DDDDD


Same result as when I ran normally.  Driver just stops communicating with no
errors or messages in the logs.  Not sure where to go from here as I'm not
seeing anything to follow up on.

I still haven't had a chance to look at all of the logs, but if you press
Ctrl-C while running in gdb, and get a backtrace with "bt", where is
it stopped?

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161015/63123d77/attachment.html>

Daniel Shields

2016-Oct-16 07:34 UTC

head link

[Nut-upsuser] Data Stale at random intervals

I've been testing with debug further and there's a few extra lines when
the nut-server stops communicating as opposed to when it's running.


Backtrace after stale data, UPS nailbunny at localhost is unavailable:


^C
Program received signal SIGINT, Interrupt.
0x00007ffff76ec1c7 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff76ec1c7 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff7bd69e5 in ?? () from /lib/x86_64-linux-gnu/libusb-0.1.so.4
#2  0x000000000040659b in ?? ()
#3  0x0000000000405b32 in ?? ()
#4  0x0000000000404340 in ?? ()
#5  0x0000000000402c39 in ?? ()
#6  0x00007ffff762cb45 in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#7  0x0000000000402e4d in ?? ()
(gdb)



Backtrace after stopping while UPS is communicating:

^C
Program received signal SIGINT, Interrupt.
0x00007ffff76ec873 in select () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff76ec873 in select () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000000000040a88e in ?? ()
#2  0x0000000000402c4d in ?? ()
#3  0x00007ffff762cb45 in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#4  0x0000000000402e4d in ?? ()
(gdb)



________________________________
From: Daniel Shields <grungelizard9 at hotmail.com>
Sent: Friday, October 14, 2016 11:41 PM
To: Charles Lepple
Cc: nut-upsuser at lists. alioth. debian. org
Subject: Re: [Nut-upsuser] Data Stale at random intervals


Hi Charles,


     Thanks for the tip.  I reran the debug again until communication stopped. 
Backtrace is below.  Thanks!



 441.204990     upsdrv_updateinfo...     (Driver stopped communicating)

Broadcast message from nut at golgotha.tklapp.com (somewhere) (Sat Oct 15
03:36:57

UPS nailbunny at localhost is unavailable

^C
Program received signal SIGINT, Interrupt.
0x00007ffff76ec1c7 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff76ec1c7 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff7bd69e5 in ?? () from /lib/x86_64-linux-gnu/libusb-0.1.so.4
#2  0x000000000040659b in ?? ()
#3  0x0000000000405b32 in ?? ()
#4  0x0000000000404340 in ?? ()
#5  0x0000000000402c39 in ?? ()
#6  0x00007ffff762cb45 in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#7  0x0000000000402e4d in ?? ()
(gdb)


________________________________
From: Charles Lepple <clepple at gmail.com>
Sent: Friday, October 14, 2016 10:41 PM
To: Daniel Shields
Cc: nut-upsuser at lists. alioth. debian. org
Subject: Re: [Nut-upsuser] Data Stale at random intervals

On Oct 14, 2016, at 8:53 PM, Daniel Shields <grungelizard9 at
hotmail.com<mailto:grungelizard9 at hotmail.com>> wrote:

Ran with gdb:


gdb /lib/nut/usbhid-ups

run -u nut -a nailbunny -x bus=010 -x vendorid=0764 -x productid=0501 -DDDDD


Same result as when I ran normally.  Driver just stops communicating with no
errors or messages in the logs.  Not sure where to go from here as I'm not
seeing anything to follow up on.

I still haven't had a chance to look at all of the logs, but if you press
Ctrl-C while running in gdb, and get a backtrace with "bt", where is
it stopped?

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161016/471510e7/attachment.html>

Charles Lepple

2016-Oct-22 18:11 UTC

head link

[Nut-upsuser] Data Stale at random intervals

- Charles> On Oct 16, 2016, at 3:34 AM, Daniel Shields <grungelizard9 at
hotmail.com> wrote:
> 
> I've been testing with debug further and there's a few extra lines
when the nut-server stops communicating as opposed to when it's running.
> 
> 
> Backtrace after stale data, UPS nailbunny at localhost is unavailable:
> Sorry to take a while to get back to you on this.

I wonder if it is getting stuck once at that point, or if it is repeatedly
calling the same libusb function.

If it is the former, then I suspect we are not going to get much help from
Debian on this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810449

Using "strace -p" with some extra options to see the time spent on
each syscall might work. (There might be some sysctl magic necessary to attach
to a running driver.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161022/d30256e1/attachment.html>

Possibly Parallel Threads

Search for more seemingly similar threads

Nut upsuser - Oct 2016 - Data Stale at random intervals

[Nut-upsuser] Data Stale at random intervals

[Nut-upsuser] Data Stale at random intervals

[Nut-upsuser] Data Stale at random intervals

Possibly Parallel Threads