On Jan 12, 2011, at 10:08 AM, Alfred Ganz wrote:
EIP is at hid_close+0x2/0x1f
eax: 00000000 ebx: d216bd20 ecx: f7fff080 edx: 00000000
esi: d21ebc00 edi: c06b3470 ebp: 00000000 esp: f768ad34
ds: 007b es: 007b ss: 0068
Process usbhid-ups (pid: 2437, ti=f768a000 task=f7682000
task.ti=f768a000)
Stack: c05976fd d20fe000 c0595668 d21ebc00 c06b3440 c058e1c5
d21ebc8c d21ebc14
c055e859 d21ebc14 d21ebc14 d21ebc00 c055ea91 d21ebc00 c0588351
ffffffc3
00000000 c0590cc0 f75ee340 00000000 00005516 00000000 c00c5512
d2173400
Call Trace:
[<c05976fd>] hiddev_disconnect+0x3f/0x5e
[<c0595668>] hid_disconnect+0x81/0xbf
[<c058e1c5>] usb_unbind_interface+0x34/0x6a
[<c055e859>] __device_release_driver+0x7d/0xbb
[<c055ea91>] device_release_driver+0x1c/0x2b
[<c0588351>] usb_driver_release_interface+0x38/0x60
...
I suspect that the problem goes away once you have booted because the
kernel HID driver has been detached from the UPS once already.
Perhaps I am misreading your description, but have you tried booting
without any USB devices, plugging the UPS in later (maybe once the
system has quiesced), then restarting the NUT init scripts?
It also might work better to disconnect the kernel HID driver before
starting usbhid-ups. If you have libhid, it comes with an example
program (libhid-detach-device) that detaches the kernel driver from
the first interface of a USB device. If not, it's just a handful of
libusb calls, and we can put together a test program to do that before
usbhid-ups gets to it.
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
