On Wed, 14 Oct 2009, Justin Piszcz wrote:
>
>
> On Wed, 14 Oct 2009, Justin Piszcz wrote:
>
>> Hi,
>>
>> I have included debugging logs-- see below, is this a nut or kernel/USB
>> subsystem issue?
>>
>> Robert/Nut User List--
>>
>> Looks like the data goes stale, please let me know if any more
>> logs/debugging is required, is this a kernel/usb problem or a nut issue? I
>> recall a change in the USB subsystem a few kernel versions back caused a
>> different issue (on a different UPS, but nevertheless it was kernel
>> related).
>
The details+logs are here (previous e-mail did not go through, too large for
the list):
wget http://home.comcast.net/~jpiszcz/20091014/nut-problem.txt
For now I have disabled nut-- is there any more debugging that I can do to
help find/solve the problem? Also cc'ing linux-usb & linux-kernel on this
one.
Highlights from the above txt file:
Pinging UPS [apc]
mainloop: polling 3 filedescriptors
Got PONG from UPS [apc]
mainloop: polling 3 filedescriptors
mainloop: no data available
mainloop: polling 3 filedescriptors
sstate_dead: driver for UPS [apc] says data is stale
Data for UPS [apc] is stale - check driver
mainloop: polling 3 filedescriptors
mainloop: no data available
sstate_dead: driver for UPS [apc] says data is stale
mainloop: polling 3 filedescriptors
Sending error [DATA-STALE] to client 127.0.0.1
write: [destfd=6] [len=15] [ERR DATA-STALE]
sstate_dead: driver for UPS [apc] says data is stale
mainloop: polling 3 filedescriptors
mainloop: no data available
sstate_dead: driver for UPS [apc] says data is stale
mainloop: polling 3 filedescriptors
Entering libusb_get_report
Report[get]: (2 bytes) => 50 16
PhyMax = 0, PhyMin = 0, LogMax = 100, LogMin = 0
get_unit_expo: 00000000 found 0
Path: UPS.PowerConverter.PercentLoad, Type: Feature, ReportID: 0x50, Offset: 0, Size: 8, Value: 22.000000
Entering libusb_get_report
Can't retrieve Report 21: Broken pipe
send_to_one: PONG
upsdrv_updateinfo...
Got to reconnect!
The same cable, UPS etc was used on another motherboard for 1-2+ years without
any issue, after moving it to a DP55KG, this problem began.
Justin.
On Sun, 18 Oct 2009, Justin Piszcz wrote:
> >> I have included debugging logs-- see below, is this a nut or kernel/USB
> >> subsystem issue?
> >>
> >> Robert/Nut User List--
> >>
> >> Looks like the data goes stale, please let me know if any more
> >> logs/debugging is required, is this a kernel/usb problem or a nut issue? I
> >> recall a change in the USB subsystem a few kernel versions back caused a
> >> different issue (on a different UPS, but nevertheless it was kernel
> >> related).
> >
>
> The details+logs are here (previous e-mail did not go through, too large for
> the list):
> wget http://home.comcast.net/~jpiszcz/20091014/nut-problem.txt
>
> For now I have disabled nut-- is there any more debugging that I can do to
> help find/solve the problem? Also cc'ing linux-usb & linux-kernel on this
> one.
You could collect a usbmon trace showing the problem. For
instructions, see the kernel source file Documentation/usb/usbmon.txt.
It might also help to provide the dmesg log from a kernel built with
CONFIG_USB_DEBUG enabled.
Alan Stern
On Sun, 18 Oct 2009, Alan Stern wrote:
> On Sun, 18 Oct 2009, Justin Piszcz wrote:
>
>>>> I have included debugging logs-- see below, is this a nut or kernel/USB
>>>> subsystem issue?
>>>>
>>>> Robert/Nut User List--
>>>>
>>>> Looks like the data goes stale, please let me know if any more
>>>> logs/debugging is required, is this a kernel/usb problem or a nut issue? I
>>>> recall a change in the USB subsystem a few kernel versions back caused a
>>>> different issue (on a different UPS, but nevertheless it was kernel
>>>> related).
>>>
>>
>> The details+logs are here (previous e-mail did not go through, too large for
>> the list):
>> wget http://home.comcast.net/~jpiszcz/20091014/nut-problem.txt
>>
>> For now I have disabled nut-- is there any more debugging that I can do to
>> help find/solve the problem? Also cc'ing linux-usb & linux-kernel on this
>> one.
>
> You could collect a usbmon trace showing the problem. For
> instructions, see the kernel source file Documentation/usb/usbmon.txt.
>
> It might also help to provide the dmesg log from a kernel built with
> CONFIG_USB_DEBUG enabled.
>
> Alan Stern
>
Thanks Alan,
I have performed all of the steps you recommended, there is also a bug in
the docs, the directory seems to be different, or at least if you have
everything compiled into the kernel and not using modules.
wget http://home.comcast.net/~jpiszcz/20091018/1.mon.out
wget http://home.comcast.net/~jpiszcz/20091018/2.6.31.4-dmesg-after.txt
wget http://home.comcast.net/~jpiszcz/20091018/2.6.31.4-dmesg-usb-debug2.txt
wget http://home.comcast.net/~jpiszcz/20091018/2.6.31.4-dmesg-usb-debug.txt
Steps from the USB documentation:
# mount -t debugfs none_debugs /sys/kernel/debug
#
The kernel documentation is outdated:
# ls /sys/kernel/debug/usbmon
0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
#
The directory is:
# ls /sys/kernel/debug/usb/usbmon
0s 0u 1s 1t 1u 2s 2t 2u
Capture all output:
cat /sys/kernel/debug/usb/usbmon/0u > /tmp/1.mon.out
Start nut:
# /etc/init.d/nut start
Starting Network UPS Tools: upsdrvctl upsd upsmon.
Within ~20-30 seconds it already broke:
============================================================================
Broadcast Message from [email protected]
(somewhere) at 17:22 ...
Communications with UPS apc@localhost lost
============================================================================
I waited another 20-30 seconds:
============================================================================
Broadcast Message from [email protected]
(somewhere) at 17:23 ...
Communications with UPS apc@localhost established
============================================================================
Then a few seconds later:
============================================================================
Broadcast Message from [email protected]
(somewhere) at 17:23 ...
Communications with UPS apc@localhost lost
============================================================================
# /etc/init.d/nut stop
Stopping Network UPS Tools: upsdrvctl upsd upsmon.
# control-c
# cat /sys/kernel/debug/usb/usbmon/0u > /tmp/1.mon.out
# ls -l /tmp/1.mon.out
-rw-r--r-- 1 root root 88354 2009-10-18 17:24 /tmp/1.mon.out
# dmesg > /tmp/2.6.31.4-dmesg-after.txt
Text from dmesg-after.txt of interest:
[ 9.245770] 0000:04:00.0: eth2: 10/100 speed: disabling TSO
[ 35.448243] usb usb1: uevent
[ 35.448271] usb 1-0:1.0: uevent
[ 35.448303] usb 1-1: uevent
[ 35.448333] usb 1-1.1: uevent
[ 35.448361] usb 1-1.1.1: uevent
[ 35.448388] usb 1-1.1.1:1.0: uevent
[ 35.448543] usb 1-1.1.1:1.1: uevent
[ 35.448698] usb 1-1.1.2: uevent
[ 35.448727] usb 1-1.1.2:1.0: uevent
[ 35.448915] usb 1-1.1:1.0: uevent
[ 35.448939] usb 1-1:1.0: uevent
[ 35.449737] usb usb2: uevent
[ 35.449764] usb 2-0:1.0: uevent
[ 35.449788] usb 2-1: uevent
[ 35.449816] usb 2-1.6: uevent
[ 35.449843] usb 2-1.6:1.0: uevent
[ 35.449866] usb 2-1.6:1.1: uevent
[ 35.449890] usb 2-1.7: uevent
[ 35.449917] usb 2-1.7:1.0: uevent
[ 35.450018] usb 2-1:1.0: uevent
[ 35.631602] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 2 [1/2 us]
[ 35.661556] usb 2-1: clear tt buffer port 7, a4 ep0 t00080e42
[ 38.095486] usb 1-1.1.2: link qh8-0601/ffff8800cf0086c0 start 5 [1/2 us]
[ 203.323838] usb 2-1: clear tt buffer port 7, a4 ep0 t00080e42
[ 203.344727] usbhid 2-1.7:1.0: disconnect by usbfs
[ 203.344744] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 2 [1/2 us]
[ 203.344754] ehci_hcd 0000:00:1d.0: shutdown urb ffff88022d921540 ep1in-intr
[ 203.344772] drivers/usb/core/file.c: removing 96 minor
[ 204.144370] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 204.395021] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 204.395386] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 204.395389] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 204.487841] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 206.396322] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 206.396328] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 206.407416] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 208.397531] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 208.397537] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 208.454951] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 210.397943] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 210.397950] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 210.438499] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 212.398246] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 212.398252] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 212.422050] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 214.398555] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 214.398560] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 214.405607] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 216.398863] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 216.398869] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 216.453142] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 218.399177] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 218.399183] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 218.436710] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 220.399484] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 220.399489] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 220.420256] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 222.399787] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 222.399793] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 222.403809] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 224.400095] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 224.400101] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 224.451340] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 226.400405] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 226.400410] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 226.434901] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 228.400717] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 228.400723] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 228.418457] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 230.401025] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 230.401031] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 230.402020] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 232.401339] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 232.401341] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 232.449547] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 3 [1/2 us]
[ 232.490278] usb 2-1: clear tt buffer port 7, a4 ep0 t00080e42
[ 290.428240] usb 2-1: clear tt buffer port 7, a4 ep0 t00080e42
[ 290.454378] usbfs 2-1.7:1.0: disconnect by usbfs
[ 290.671011] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 4 [1/2 us]
[ 290.677315] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 4 [1/2 us]
[ 292.410579] ehci_hcd 0000:00:1d.0: reused qh ffff8800cf00c3c0 schedule
[ 292.410585] usb 2-1.7: link qh64-0601/ffff8800cf00c3c0 start 4 [1/2 us]
[ 292.469048] usb 2-1.7: unlink qh64-0601/ffff8800cf00c3c0 start 4 [1/2 us]
[ 292.473781] usb 2-1: clear tt buffer port 7, a4 ep0 t00080e42
A snippet from 1.mon.out:
ffff88022bee2380 341311138 S Ci:2:004:0 s 80 06 0300 0000 00ff 255 <
ffff88022bee2380 341312510 C Ci:2:004:0 0 4 = 04030904
ffff88022bee2380 341312515 S Ci:2:004:0 s 80 06 0302 0409 00ff 255 <
ffff88022bee2380 341331883 C Ci:2:004:0 0 30 = 1e033800 42003000 38003200 32005200 33003400 34003700 35002000 2000
ffff88022bee2380 343276840 S Ci:2:004:0 s 80 06 0300 0000 00ff 255 <
ffff88022bee2380 343282777 C Ci:2:004:0 0 4 = 04030904
ffff88022bee2380 343282783 S Ci:2:004:0 s 80 06 0303 0409 00ff 255 <
ffff88022bee2380 343293150 C Ci:2:004:0 0 52 = 34034100 6d006500 72006900 63006100 6e002000 50006f00 77006500 72002000
ffff88022bee2380 343293157 S Ci:2:004:0 s 80 06 0300 0000 00ff 255 <
ffff88022bee2380 343295400 C Ci:2:004:0 0 4 = 04030904
ffff88022bee2380 343295406 S Ci:2:004:0 s 80 06 0301 0409 00ff 255 <
ffff88022bee2380 343312151 C Ci:2:004:0 0 90 = 5a034200 61006300 6b002d00 55005000 53002000 52005300 20003100 35003000
ffff88022bee2380 343312157 S Ci:2:004:0 s 80 06 0300 0000 00ff 255 <
ffff88022bee2380 343316151 C Ci:2:004:0 0 4 = 04030904
ffff88022bee2380 343316155 S Ci:2:004:0 s 80 06 0302 0409 00ff 255 <
ffff88022bee2380 343335654 C Ci:2:004:0 0 30 = 1e033800 42003000 38003200 32005200 33003400 34003700 35002000 2000
ffff88022bee2380 345277876 S Ci:2:004:0 s 80 06 0300 0000 00ff 255 <
ffff88022bee2380 345283673 C Ci:2:004:0 0 4 = 04030904
ffff88022bee2380 345283681 S Ci:2:004:0 s 80 06 0303 0409 00ff 255 <
ffff88022bee2380 345294172 C Ci:2:004:0 0 52 = 34034100 6d006500 72006900 63006100 6e002000 50006f00 77006500 72002000
Please let me know if this helps.
Justin.
On Sun, 18 Oct 2009, Justin Piszcz wrote:
> I have performed all of the steps you recommended, there is also a bug in
> the docs, the directory seems to be different, or at least if you have
> everything compiled into the kernel and not using modules.
> Steps from the USB documentation:
>
> # mount -t debugfs none_debugs /sys/kernel/debug
> #
>
> The kernel documentation is outdated:
>
> # ls /sys/kernel/debug/usbmon
> 0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
> #
>
> The directory is:
> # ls /sys/kernel/debug/usb/usbmon
> 0s 0u 1s 1t 1u 2s 2t 2u
This has already been corrected in the 2.6.32-rc kernels.
However there is another respect in which the documentation is
outdated: It mentions /proc/bus/usb/devices. That file has moved; it
is now named /sys/kernel/debug/usb/devices. Would you like to submit a
patch fixing this?
Alan Stern
On Mon, 19 Oct 2009, Alan Stern wrote:
> On Sun, 18 Oct 2009, Justin Piszcz wrote:
>
>> I have performed all of the steps you recommended, there is also a bug in
>> the docs, the directory seems to be different, or at least if you have
>> everything compiled into the kernel and not using modules.
>
>> Steps from the USB documentation:
>>
>> # mount -t debugfs none_debugs /sys/kernel/debug
>> #
>>
>> The kernel documentation is outdated:
>>
>> # ls /sys/kernel/debug/usbmon
>> 0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
>> #
>>
>> The directory is:
>> # ls /sys/kernel/debug/usb/usbmon
>> 0s 0u 1s 1t 1u 2s 2t 2u
>
> This has already been corrected in the 2.6.32-rc kernels.
Great to hear, I will try the latest 2.6.31-rcX kernel!
>
> However there is another respect in which the documentation is
> outdated: It mentions /proc/bus/usb/devices. That file has moved; it
> is now named /sys/kernel/debug/usb/devices. Would you like to submit a
> patch fixing this?
>
> Alan Stern
>
Hi,
Sure, what I meant is:
usbmon.txt states:
/sys/kernel/debug/usbmon/3u
^^^^^
Actual location:
/sys/kernel/debug/usb/usbmon/3u
^^^^^^^^^
Patch below (and attached):
diff -uprN linux-2.6.31.1/Documentation/usb/usbmon.txt linux-2.6.31.1.patch/Documentation/usb/usbmon.txt
--- linux-2.6.31.1/Documentation/usb/usbmon.txt 2009-09-24 11:45:25.000000000 -0400
+++ linux-2.6.31.1.patch/Documentation/usb/usbmon.txt 2009-10-19 10:51:06.725516874 -0400
@@ -33,7 +33,7 @@ if usbmon is built into the kernel.
Verify that bus sockets are present.
-# ls /sys/kernel/debug/usbmon
+# ls /sys/kernel/debug/usb/usbmon
0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
#
@@ -58,11 +58,11 @@ Bus=03 means it's bus 3.
3. Start 'cat'
-# cat /sys/kernel/debug/usbmon/3u > /tmp/1.mon.out
+# cat /sys/kernel/debug/usb/usbmon/3u > /tmp/1.mon.out
to listen on a single bus, otherwise, to listen on all buses, type:
-# cat /sys/kernel/debug/usbmon/0u > /tmp/1.mon.out
+# cat /sys/kernel/debug/usb/usbmon/0u > /tmp/1.mon.out
This process will be reading until killed. Naturally, the output can be
redirected to a desirable location. This is preferred, because it is going
On Sun, 18 Oct 2009, Justin Piszcz wrote:
> Thanks Alan,
>
> I have performed all of the steps you recommended, there is also a bug in
> the docs, the directory seems to be different, or at least if you have
> everything compiled into the kernel and not using modules.
> Start nut:
> # /etc/init.d/nut start
> Starting Network UPS Tools: upsdrvctl upsd upsmon.
>
> Within ~20-30 seconds it already broke:
> ============================================================================
> Broadcast Message from [email protected]
> (somewhere) at 17:22 ...
Well, the usbmon trace shows that wherever the problem lies, it isn't
in the kernel. There were a few problems in the device itself -- it
was queried for a report and did not provide any data. The nut program
should be smart enough to retry when this happens, but it didn't.
It did try to re-establish communcation with the device, but it appears
that nut got caught in a loop during this attempt. During this loop
nut did nothing but transfer a bunch of string descriptors from the
device, over and over again at 2-second intervals. The loop lasted for
almost a minute, until another device error occurred. Then nut
recovered properly -- until a third error happened and nut got stuck in
its loop again.
Alan Stern
On Mon, 19 Oct 2009, Justin Piszcz wrote:
>
>
> On Mon, 19 Oct 2009, Alan Stern wrote:
>
>> On Sun, 18 Oct 2009, Justin Piszcz wrote:
>>
>>> I have performed all of the steps you recommended, there is also a bug in
>>> the docs, the directory seems to be different, or at least if you have
>>> everything compiled into the kernel and not using modules.
>>
>>> Steps from the USB documentation:
>>>
>>> # mount -t debugfs none_debugs /sys/kernel/debug
>>> #
>>>
>>> The kernel documentation is outdated:
>>>
>>> # ls /sys/kernel/debug/usbmon
>>> 0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
>>> #
>>>
>>> The directory is:
>>> # ls /sys/kernel/debug/usb/usbmon
>>> 0s 0u 1s 1t 1u 2s 2t 2u
>>
>> This has already been corrected in the 2.6.32-rc kernels.
> Great to hear, I will try the latest 2.6.31-rcX kernel!
Disregard this ^
Misread, thought you meant the bug was fixed in the latest kernel but saw
your follow-up that this appears to be nut-related.
Justin.
On Mon, 19 Oct 2009, Justin Piszcz wrote:
> >> The kernel documentation is outdated:
> >>
> >> # ls /sys/kernel/debug/usbmon
> >> 0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
> >> #
> >>
> >> The directory is:
> >> # ls /sys/kernel/debug/usb/usbmon
> >> 0s 0u 1s 1t 1u 2s 2t 2u
> >
> > This has already been corrected in the 2.6.32-rc kernels.
> Great to hear, I will try the latest 2.6.31-rcX kernel!
It looks like you misunderstood. I was referring to the 2.6.32-rc
kernels, not 2.6.31-rc. In particular, check out this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f0cc82a831d4d839eb6b67c7c046ebd2d1d7c4c2
> Hi,
>
> Sure, what I meant is:
>
> usbmon.txt states:
> /sys/kernel/debug/usbmon/3u
> ^^^^^
>
> Actual location:
> /sys/kernel/debug/usb/usbmon/3u
> ^^^^^^^^^
Yes, I know.
> Patch below (and attached):
As I said, this correction has already been made.
Alan Stern
On Mon, 19 Oct 2009, Alan Stern wrote:
> On Sun, 18 Oct 2009, Justin Piszcz wrote:
>
>> Thanks Alan,
>>
>> I have performed all of the steps you recommended, there is also a bug in
>> the docs, the directory seems to be different, or at least if you have
>> everything compiled into the kernel and not using modules.
>
>> Start nut:
>> # /etc/init.d/nut start
>> Starting Network UPS Tools: upsdrvctl upsd upsmon.
>>
>> Within ~20-30 seconds it already broke:
>> ============================================================================
>> Broadcast Message from [email protected]
>> (somewhere) at 17:22 ...
>
> Well, the usbmon trace shows that wherever the problem lies, it isn't
> in the kernel. There were a few problems in the device itself -- it
> was queried for a report and did not provide any data. The nut program
> should be smart enough to retry when this happens, but it didn't.
>
> It did try to re-establish communcation with the device, but it appears
> that nut got caught in a loop during this attempt. During this loop
> nut did nothing but transfer a bunch of string descriptors from the
> device, over and over again at 2-second intervals. The loop lasted for
> almost a minute, until another device error occurred. Then nut
> recovered properly -- until a third error happened and nut got stuck in
> its loop again.
>
> Alan Stern
>
Hi,
To the nut list, the last time nut changed was 2009-06-13:
2009-06-13 04:29:25 configure nut-cgi 2.4.1-3 2.4.1-3
2009-06-13 04:29:25 status unpacked nut-cgi 2.4.1-3
2009-06-13 04:29:25 status unpacked nut-cgi 2.4.1-3
2009-06-13 04:29:25 status unpacked nut-cgi 2.4.1-3
2009-06-13 04:29:25 status unpacked nut-cgi 2.4.1-3
2009-06-13 04:29:25 status unpacked nut-cgi 2.4.1-3
2009-06-13 04:29:25 status half-configured nut-cgi 2.4.1-3
2009-06-13 04:29:26 status installed nut-cgi 2.4.1-3
I made no changes to the nut configuration or install.
What did change was the motherboard.
From: Intel DG965WH -> Intel DP55KG
Then this problem began.
Justin.