> I don't know the default syslog configuration on Solaris anymore, but
> is there a more detailed system log than what "dmesg" prints?
It turns out that the dmesg log information I posted earlier was not
actually part of the problem. It was just old logged information.
Nothing to do with the my current problem. Nor is there any information
in any of the logs.
> One possibility is to run the driver
> with some "-D" flags to generate debug output.
> After this, is the tripplite_usb process still running?
I ran it as you suggested with 4 D flags (-DDDD).
Output:
12.008281 send_cmd(msg_len=2, type='S')
12.136276 send_cmd(msg_len=2, type='D')
12.264275 send_cmd(msg_len=2, type='M')
12.392281 send_cmd(msg_len=2, type='T')
13.768512 send_cmd(msg_len=2, type='L')
13.896289 send_cmd(msg_len=2, type='D')
.
.
.
##.###### send_cmd(msg_len=2, type='T')
At this point tripplite_usb freezes. No more debugging information is
output. It doesn't always hang on the 'T' command, it appears to be
random. I was able to look at the stack to see where it was hanging.
Stack:
Read
Usb_do_io
Usb_interrupt_read
Usb_interrupt_read
Libusb_get_interrupt
Send_cmd
Upsdrv_updateinfo
Main
_start
It appears NUT is waiting for the UPS to respond. I am currently
attempting to duplicate this crash with more -D flags, but because of
the rarity of the issue it may take some time.
> one Fedora user has seen the same (or similar) problem with
triplite_usb.
> After several power cycles ups driver goes crazy, probably hangs.
>
> More info and log messages can be found here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=575875
>
> if you are interested in any info, let me know and I'll ask the
reporter.
It may be similar/same. I think it may be too early to tell. Thoughts?
Suggestions?
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
