[SOLVED] High hardware interrupts from timer and parport0 causing issues
Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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.
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.
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.