[Nut-upsdev] Syslog flooding

[Charles Lepple]

On Mon, Apr 19, 2010 at 8:12 PM, Kelvin Ku
<kelvin at telemetry-investments.com> wrote:
> On Mon, Apr 19, 2010 at 07:08:37PM -0400, Charles Lepple wrote:
>> On Mon, Apr 19, 2010 at 4:22 PM, Kelvin Ku
>> <kelvin at telemetry-investments.com> wrote:
>> > Hello,
>> >
>> > I have a TrippLite SU2200XLA UPS with a possibly unreliable USB interface
>> > running on NUT 2.4.3. This flooded syslog last night, beginning with the USB
>> > connection spontaneously reconnecting:
>> >
>> > Apr 18 22:00:42 kernel: hiddev96: USB HID v1.11 Device [Tripp Lite       TRIPP LITE UPS  ] on usb-0000:00:0f.2-2
>> > Apr 18 22:00:44 usbhid-ups[486]: Got disconnected by another driver: Device or resource busy
>> > Apr 18 22:00:46 usbhid-ups[486]: Got disconnected by another driver: Device or resource busy
>> > Apr 18 22:00:48 usbhid-ups[486]: Got disconnected by another driver: Device or resource busy
[...]
> Sorry, I left this out of the paste:
>
> Apr 18 22:00:42 kernel: hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
> Apr 18 22:00:42 kernel: usb 1-2: USB disconnect, address 5
> Apr 18 22:00:42 kernel: usb 1-2: new low speed USB device using ohci_hcd and address 6
> Apr 18 22:00:42 kernel: usb 1-2: configuration #1 chosen from 1 choice
> Apr 18 22:00:42 kernel: hiddev96: USB HID v1.11 Device [Tripp Lite       TRIPP LITE UPS  ] on usb-0000:00:0f.2-2
>
> Does this indicate something is flaky with the USB connection? I don't think
> the device is actually being claimed by another driver:

Yes. Any time the kernel decides to disable a USB port, something is
flaky. This happens in a software layer well below NUT.

However, if those error messages you are getting (device busy) are a
direct result of the EMI issue, I don't know how we can tell the
difference between a transient error like that, versus a true device
contention situation (where one driver needs to back off, and exit).
The NUT USB drivers are designed to reconnect after a device has
disconnected, but that requires the old device to stop working in a
predictable manner.

What kernel (and distribution) are you using?

> $ ps -ef | egrep 'usb|hid'
> root       119     2  0 Mar13 ?        00:00:00 [ksuspend_usbd]
> hero     13364 13004  0 20:06 pts/0    00:00:00 egrep usb|hid
>
> There's nothing else in syslog around the time that the device was
> disconnected. Just to be clear, I didn't physically reconnect the device at
> 22:00:42; it was connected long before that.
>
> Also, this specific unit does this on every host I connect it to, so it could
> be a bad USB interface on the UPS (or maybe a bad cable?), in which case I hope
> I can configure the software to work around it.

USB cables are inexpensive - that would be the first thing I would
swap out. It could also be the interface on the UPS, in which case I
wouldn't want to trust a software workaround (since that would mask a
real problem down the road).

-- 
- Charles Lepple