Interrupt storm on ehci USB controller (irq10 ) on HP DL165 64-bit (bug?)

dxangel

Hello,

N00b here, please be nice

Im currently trying to install Pfsense onto a HP DL165 G5.

I was able to install, however, throughout the boot process and upon reboot i have experiencved interrupt storms on irq10.

All unnecessary hardware was disabled in the bios - including USB.

dmesg | grep irq tells me that the below devices are using irq10:

ohci
ehci

vmstat -i confirms this

irq10: ohci0 ohci+ 6703418 1261

these are the usb drivers, even thought usb is disabled.

I cannot find a way to disable these usb drivers. The only fix i found was to recompile the kernel via the GENERIC file,
which i cannot achieve on the current system for various reasons. I am also on a timeframe as i need to get firewalls into production ASAP.

Has a patch or a fix for this been developed yet? If so, can someone please point me in the right direction, as i have been unable to locate it.

If someone could please shed some light, it would be much appreciated.

wallabybob

I don't know whats inside a HP DL165, so some of this comment may not be relevant. In a number of recent Intel chipsets there is a mechanism to hide various on-chip devices such as USB, LAN etc. I would expect that if a device is completely disabled in the BIOS it would be invisible to FreeBSD. (I have recently done some configuration of a motherboard based on the AMD 780G chipset and disabling USB in the on-chip devices section of the BIOS menus made all the USB devices invisible to FreeBSD. In that system I disabled USB to workaround a hang immediately after the startup reported the ehci device.)

So I suggest you take a further look in the BIOS menu, maybe there is another place to where you can make the USB devices invisible. Its worth looking in the HP support pages for the DL165 - there may be a newer BIOS than the one on your system. Have you tried a pfSense 1.2.3 snapshot? That fixed my "ehci" problem on the 780G based motherboard.

dxangel

yes i went through the bios with a fine-tooth comb.

In the end the problem still remains unresolved, due to time constraints and not wishing to recompile kernels, i just swapped out the hardware for some DL150's, which it loaded onto fine.