High hardware interrupts from timer and parport0 causing issues
 

I guess this is the right place to set this as it comes back to hardware, but alas I hope someone can help me.

I recently put a ClearOS proxy into our office and it seemed to operate ok at first, then the box stopped passing network traffic and once rebooted and that fixed it started to slow down the Internet connection. I thought maybe ntop was causing issues, I disabled that, and that didn't help, I did some investigation and found that the CPU (dual core) is servicing 45%-50% hardware interrupts according to top (when looking at individual core on get 88%-100% hardware interrupts the other sits almost completely idle) using procinfo I see that the timer and a device called parport0 are causing an insane number of interrupts. I don't know where to proceed form here, I have done some googling and nothing good has come up, mainly talks about high interrupts suggesting hardware issues and to replace hardware, but I can hardly replace the timer, and I don't even know what parport0 is (though I highly suspect parallel port). Any suggestions how to proceed? I am thinking of wiping the box and rolling my own based on Debian.

I take it you are not using the parallel port?

Parallel ports come with 2 modules, and two possibile configurations. As parport0, it's bidirectional. As lp0, it is unidirectional. It is usually possible to deny them an interrupt or disable the parallel port completely in the bios.

I would remove the parport.ko module. It's probably in the /lib/modules module tree, and may also be in the initrd if you have one. Rm it or move it out of sight. If you have the setting to trigger interrupts as edge or level, I would set edge.

Thanks business kid, I'll look into that the first chance I get.

Well just an update as part of troubleshooting I disabled the parallel port in the BIOS and the issue seems to have disappeared. As this is a production machine I am not going to dig any further, though I would like to know what caused it.

Spurious interrupts.

The only one of these I properly ran to ground was causing log spam on usb-2.0, and I had a box which displayed the fault. I made waves on the chipset manufacturer's(VIA) forums, and they evidently decided I was dangerous, and asked their linux guy (some programming hopeful)to put work into solving this.
He produced a kernel patch which read the state of salient registers into the log, as I threw in and removed usb things. Patch mark III worked.We could suddenly see that it wasn't paying a blind bit of notice to the state registers, and just spewing messages when nothing was connected.

ehci: overcurrent change on port 0.0
ehci: overcurrent change on port 0.1

To the software guys, this was perplexing. But fortunately there was a hardware guy on the job (ME), and I could pat them on the head and say yes, dud hardware getting out the door was a perfectly normal if not desirable thing, and not to be worrying themselves. A patch giving a kernel option followed, and wiped them.

I subsequently discovered this was on 2 of the 6 usb ports on that chip. Via's 'reaction' to it had been to quietly disable the 2 offending ports internally, and make MK II with 4 usb ports. They sold the stock off cheap, and I bought cheap, so what goes around comes around, etc.

Interesting story, but things happen I guess, as I don't need the parallel port it's all good. Thanks for helping out.