[Nut-upsdev] a nasty kernel oops

[Alfred Ganz]

Charles,

Here is some more insight into my problem.
 * I am now able to get a crash on a virtual machine, so life has
   become a bit easier
 * disabling the UPS, then immediately after re-enabling it, the first 
   libhid-detach-device fails after about 10 sec, with:
	hid_force_open failed with return code 7.
   i.e. no device has been found.
   Following the first libhid-detach-device immediately by several more,
   they all fail the same way, but without another 10 sec delay.
   Finally, adding a sleep 1 followed by another libhid-detach-device
   will succeed.
 * disabling the UPS, then waiting 20 sec after re-enabling it, the 
   first libhid-detach-device will succeed.
   Note, I wasn't able to reduce this delay significantly, so it seems
	that the total delay can be smaller when doing the above
	failing operations.
 * The same behavior occurs when using lsusb -d instead of the above
   libhid-detach-device.
 * usbhid-ups crashes if the last preceeding libhid-detach-device fails,
   but it will not fail if there is a successful libhid-detach-device
   preceeding it, or if there is a longer inactive delay.
Unfortunately, the timing is for the virtual machine, and I don't expect
things to be similar on the real machine, not to speak of the boot
context with other devices present.

As you suspected, it looks like usbhid-ups crashes if things have not 
reached quiescence or some other kind of availability. However, I have 
no idea how at boot time adding an active USB device can achieve this 
(or maybe achieve it much more quickly).

It would of course be nice to make usbhid-ups have a builtin method for
detecting such a state and at the same time be able to detect the 
absence of the device in question. However, I think the appropriate
thing is to determine such a method outside of usbhid-ups first. If at
all possible, I would prefer to do this with some shell script, but if
push comes to shuff, I might have to resort to some C code as well.

Any advice on what might work would of course be much appreciated. 

Thanks, AG

P.S. What happened to the mail server at lists.alioth.debian.org

-- 
 ----------------------------------------------------------------------
   Alfred Ganz					alfred-ganz:at:agci.com
   AG Consulting, Inc.				(203) 624-9667
   440 Prospect Street # 11
   New Haven, CT 06511
 ----------------------------------------------------------------------