On Mon, Apr 19, 2010 at 8:12 PM, Kelvin Ku <[email protected]> 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 >> <[email protected]> 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 _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
