[Nut-upsdev] Tripplite USB 3003 problems

[Wallis, Chase Civ USAF AFMC 519 SMXS/MXDEA]

> 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?