My guess would be that there is some miscommunication between driver levels, perhaps a result of running a new nut with an old kernel (latest is 2.6-37)?<br><br>That the presence of the "-D" flag appears to suppress the error:<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote"> * I have hacked the startup script to invoke usbhid-ups directly with<br>
the proper device parameter and -D, and the problem goes away<br>
* I have used the hacked startup script to invoke usbhid-ups directly<br>
with the proper device parameter but *no* -D, and we have a crash!<br></blockquote><div><br>suggests a place to start, possibly looking for a device/interface timing issue.<br><br>Dave<br></div><br><div class="gmail_quote">
On Wed, Jan 12, 2011 at 10:08 AM, Alfred Ganz <span dir="ltr"><<a href="mailto:alfred-ganz%2Bnut@agci.com">alfred-ganz+nut@agci.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Ladies and Gentlemen,<br>
<br>
I have been trying to sort out a nasty kernel oops for which I would<br>
like to ask for some advice. I don't actually think that this is a nut<br>
problem, although it is triggered by upsdrvctl or usbhid-ups. I rather<br>
suspect the USB library or the associated kernel code.<br>
Here is the configuration information:<br>
* system: Centos-5.5<br>
* kernel: 2.6.18-194.32.1.el5, latest vanilla for Centos-5.5<br>
* nut: nut-2.4.3-1, a build provided by Arnaud last fall<br>
* libusb: libusb-0.1.12-5.1, the latest for this system<br>
* the UPS:<br>
device.mfr: APC<br>
device.model: Back-UPS ES 650<br>
device.serial: QB0514232934<br>
device.type: ups<br>
ups.firmware: 818.w1.D<br>
ups.mfr.date: 2005/08/10<br>
ups.productid: 0002<br>
Sorry Arnaud!<br>
* the driver:<br>
<a href="http://driver.name" target="_blank">driver.name</a>: usbhid-ups<br>
driver.parameter.pollfreq: 30<br>
driver.parameter.pollinterval: 1<br>
driver.parameter.port: auto<br>
driver.version: 2.4.3<br>
driver.version.data: APC HID 0.95<br>
driver.version.internal: 0.34<br>
The problem:<br>
* under certain circumstances system boot fails with a kernel oops<br>
during the upsdrvctl/usbhid-ups phase of the startup script.<br>
Note that we have *not* reached the upsd part of the startup script,<br>
and the startup script of the printer package (cups) would be<br>
reached much later.<br>
* the boot process works fine if another USB device, the USB printer,<br>
is powered up. Unfortunately, I would like to keep it powered off<br>
most of the time if I could do so.<br>
Note, the printer is not the only other USB device on the system,<br>
but the number of active USB devices is being changed.<br>
* Once the system is completely booted, there is no problem starting<br>
and stopping the ups using the startup script.<br>
* the problem appeared late in the lifetime of Centos-5, the system<br>
has shut down due to power loss and restarted with the printer off<br>
before the arrival of the problem.<br>
* the problem has probably appeared with the transition from Centos-5.4<br>
(kernel-2.6.18-164.15.1.el5) to Centos-5.5 (kernel-2.6.18-194.3.1.el5),<br>
although I noticed it much later<br>
* libusb has been the same since 2008/04/22, I don't believe the problem<br>
appeared that long ago.<br>
* the problem happens with the locally rebuilt (with no changes)<br>
nut-2.2.0-6.1 from Fedora 8, with the nut-2.4.3-1 provided by<br>
Arnaud, and with a locally rebuilt version of nut-2.4.3-1 using<br>
a spec file provided by Arnaud.<br>
Here is what I have tried:<br>
* I have started the system for a crash dump, and below is an extract<br>
from the crash log.<br>
* I have tried to recreate the problem on a virtual machine, but it<br>
doesn't happen there<br>
* I have introduced a delay before the start of the ups startup script<br>
to make sure that the suspected timing problem doesn't happen earlier.<br>
* I have hacked the startup script to invoke usbhid-ups directly with<br>
the proper device parameter and -D, and the problem goes away<br>
* I have used the hacked startup script to invoke usbhid-ups directly<br>
with the proper device parameter but *no* -D, and we have a crash!<br>
So I am now left with the observation that we have a timing problem<br>
somewhere among usbhid-ups, libusb, and the kernel, and I have no<br>
idea how to further narrow things down.<br>
<br>
I would be glad to do some more tests, but I would need your help with<br>
this.<br>
<br>
Thanks for any advice, AG<br>
<br>
----------------------------------------------------------------------------<br>
BUG: unable to handle kernel paging request at virtual address 0000190c<br>
printing eip:<br>
c05954c6<br>
*pde = 74ecb067<br>
Oops: 0000 [#1]<br>
SMP<br>
....<br>
CPU: 0<br>
EIP: 0060:[<c05954c6>] Not tainted VLI<br>
EFLAGS: 00010206 (2.6.18-194.26.1.el5 #1)<br>
EIP is at hid_close+0x2/0x1f<br>
eax: 00000000 ebx: d216bd20 ecx: f7fff080 edx: 00000000<br>
esi: d21ebc00 edi: c06b3470 ebp: 00000000 esp: f768ad34<br>
ds: 007b es: 007b ss: 0068<br>
Process usbhid-ups (pid: 2437, ti=f768a000 task=f7682000 task.ti=f768a000)<br>
Stack: c05976fd d20fe000 c0595668 d21ebc00 c06b3440 c058e1c5 d21ebc8c d21ebc14<br>
c055e859 d21ebc14 d21ebc14 d21ebc00 c055ea91 d21ebc00 c0588351 ffffffc3<br>
00000000 c0590cc0 f75ee340 00000000 00005516 00000000 c00c5512 d2173400<br>
Call Trace:<br>
[<c05976fd>] hiddev_disconnect+0x3f/0x5e<br>
[<c0595668>] hid_disconnect+0x81/0xbf<br>
[<c058e1c5>] usb_unbind_interface+0x34/0x6a<br>
[<c055e859>] __device_release_driver+0x7d/0xbb<br>
[<c055ea91>] device_release_driver+0x1c/0x2b<br>
[<c0588351>] usb_driver_release_interface+0x38/0x60<br>
[<c0590cc0>] proc_ioctl_default+0x10d/0x1d0<br>
[<c0591ffd>] usbdev_ioctl+0x1027/0x10de<br>
[<c048b06b>] __d_lookup+0x98/0xdb<br>
[<c04c7eff>] inode_has_perm+0x54/0x5c<br>
[<c04c78ab>] avc_has_perm+0x3c/0x46<br>
[<c04c7eff>] inode_has_perm+0x54/0x5c<br>
[<c0464c32>] __handle_mm_fault+0x463/0xaac<br>
[<c0486290>] do_ioctl+0x47/0x5d<br>
[<c04867f9>] vfs_ioctl+0x47b/0x4d3<br>
[<c0486899>] sys_ioctl+0x48/0x5f<br>
[<c0404f17>] syscall_call+0x7/0xb<br>
=======================<br>
Code: 00 05 b0 01 86 83 b4 0c 00 00 fb 8d 83 54 0c 00 00 e8 4c 87 e9 ff 8b 83 a8 0c 00 00 e8 7d 74 ff ff 31 c0 5b c3 31 d2 eb be 89 c2 <8b> 80 0c 19 00 00 48 85 c0 89 82 0c 19 00 00 75 0b 8b 82 a8 0c<br>
EIP: [<c05954c6>] hid_close+0x2/0x1f SS:ESP 0068:f768ad34<br>
----------------------------------------------------------------------------<br>
<font color="#888888"><br>
--<br>
----------------------------------------------------------------------<br>
Alfred Ganz alfred-ganz:at:<a href="http://agci.com" target="_blank">agci.com</a><br>
AG Consulting, Inc. (203) 624-9667<br>
440 Prospect Street # 11<br>
New Haven, CT 06511<br>
----------------------------------------------------------------------<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>"Ridicule is man's most potent weapon. <span> It’s hard to counterattack ridicule, and it infuriates<br> the opposition, which then reacts to your advantage.</span>"<br>
<br> Saul Alinsky, Marxist, Obama mentor<br><br>