LinuxQuestions.org - PCI board preventing USB host controller from getting hardware interrupts??

So, this isn't the annoying DEVPATH problem with the kernel layer not setting the variable so HAL complains ... this is a little more weird for me, on dell poweredge servers 2850 we get thousands of:

Code:

                                          drivers/usb/input/hid-core.c: not resubmitting, input1

 usb 2-1: USB disconnect, address 52

 usb 2-1: new full speed USB device using address 53

 usb 2-1: device not accepting address 53, error -71

 usb 2-1: new full speed USB device using address 54

 input: USB HID v1.10 Keyboard [Dell DRAC4] on usb-0000:00:1d.0-1

 input: USB HID v1.10 Mouse [Dell DRAC4] on usb-0000:00:1d.0-1

 



 



 Jun 13 10:43:14 dx1-ptr kernel: usb 2-1: device not accepting address 51, error -71

 Jun 13 10:43:15 dx1-ptr hal.hotplug[26983]: DEVPATH is not set

 Jun 13 10:43:15 dx1-ptr hal.hotplug[27053]: DEVPATH is not set

 Jun 13 10:57:33 dx1-ptr hal.hotplug[7209]: DEVPATH is not set

 Jun 13 10:57:33 dx1-ptr hal.hotplug[7234]: DEVPATH is not set

 Jun 13 10:58:06 dx1-ptr kernel: usb 2-1: device not accepting address 53, error -71

 Jun 13 10:58:06 dx1-ptr hal.hotplug[7593]: DEVPATH is not set

 Jun 13 10:58:07 dx1-ptr hal.hotplug[7675]: DEVPATH is not set

Now, like I said, the DEVPATH is okay, RHEL4u5 I think has an errata which will fix that annoying error, but the other errors are what is concerning because I was able to replicate the problem/errors by intercepting the interrupt requests from the USB host controller...

could the PCI be preventing the controller from getting the hardware interrupts?

on my 2.6.19-1.2911.fc6 box /proc/interrupts would consistently increment when requests were made by the kernel, i.e. the controller replied to the request...

however on the dell poweredge I wasn't able to see /proc/interrupts increment at all, even when sending hardware requests. I also noticed that the BIOS interacts with this, among other things....perhaps moving the USB adapter to another PCI slot
might mitigate the errors? or is this a problem with /proc/sys/kernel/hotplug, which is normally /sbin/hotplug. A hotplug event is initiated and hal_hotplug is called via /sbin/hotplug so is there something in there that needs tweaking?

Also, I guess I can blacklist the usb controller to get rid of the errors, but I didn't want to disable usb support -- DRAC4 errors in there too...so not sure with those being a red herring, or a firmware update needed, as per some other posts on google, however I wasn't able to find a definitive answer concerning the usb errors -- we have literally a thousand of these identical servers, yet only one demonstrating the problem, so of course, I thought hardware too, but they just didn't look like hardware errors to me originally...

thanks, sorry for the long post (again)