-   General (
-   -   Interrupts on a laptop (

andy713 04-02-2013 10:11 PM

Interrupts on a laptop
So, my wife's HP laptop has a problem that is causing it to generate >4000 interrupts per second and chew up the CPU. Problem is it is running Window 7. Now before you go off about this being a Slackware forum, let's be honest. Normally I would open a shell and cat /proc/interrupts, wait a few seconds, do it again, and I'd know what the problem was. Unfortunately, this doesn't appear to be something that Windoze knows how to do. Why do I ask this here? Because we all know that I'd spend all my waking hours trying to explain the problem on some MS forum to a legion of clueless "experts", when we all know that as much as we don't like it, we live in a Windoze world and we have probably forgotten more about Windoze than most of the so-called experts know. The saying goes that if you have a computer question ask a Slacker, and I'm hoping that someone here knows.

Please don't reply with disparaging comments about Windows; you're preaching to the choir. We're all thinking it. And you probably couldn't dislike it more than me without spontaneously bursting into flame anyway.


volkerdi 04-02-2013 11:53 PM

Can you test with -current to see if the problem still exists?

astrogeek 04-02-2013 11:57 PM


Originally Posted by volkerdi (Post 4923987)
Can you test with -current to see if the problem still exists?


H_TeXMeX_H 04-03-2013 03:43 AM

Post the output of '/proc/interrupts', and '/sbin/lspci -k'.

jamesf 04-03-2013 08:32 AM

Slacker by night, Windows programmer in ArcGIS environment by day.

Go to and download the "sysinternals suite". My first tool of choice is "procexp", the process explorer. Gives you a configurable htop-like display of what is going on, complete with sortable columns like %CPU, etc. By the way, the URL I have redirects to MSDN, the Microsoft Developer Network, and is Microsoft-hosted. Mark Russinovich was hired by MS on the strength of his Sysinternals stuff.

I also use "autoruns" quite a bit, it shows all of the eleventy-seven locations that Windows stuff can automatically run from as well as letting you toggle the running on and off. Be careful here, other utilities do the same thing but don't necessarily understand just where autoruns stuffs the items you've turned off.

After you've identified some process that is _responding_ to lots of interrupts you might want to trace exactly what the process is doing by using "procmon", the process monitor. You can build filters in procmon so that you can narrow down the monitoring from all windows events/registry writes/disk reads to just the few (or the many, or the specific process) that you want to monitor.

Procexp also has a "trace-the-boot" mode where it gets started really early and logs the boot process.

Hope this helps.

EDIT: Add some columns in Procexp, you'll probably be able to figure out what, but things like Disk I/O, swap space, memory used, etc. You might just be having a case of not quite enough RAM and thrashing the pagefile like crazy. If you do Disk I/O be sure to add all three (reads, writes, other, IIRC).

jamesf 04-03-2013 09:53 AM

Another thing - googling combinations of 'sysinternals interrupts' brings up some google search suggestions as well as some interesting ideas.

andy713 04-07-2013 07:47 PM

I tried procexp but it only tells me what I already know, that the CPU is churing at 10% servicing some interrupt. The closest thing I've found to help was on the MS site, which suggests I look at the times of the drivers and guess that the driver handling the interrupt will tell me what hardware is the problem. The other problem is that this of course goes away if I reboot, only to eventually come back. Is it any wonder Linus thought he could do better?


michaelk 04-07-2013 09:38 PM

Moved: This thread is more suitable in Non-*NIX>General and has been moved accordingly to help your thread/question get the exposure it deserves.

jamesf 04-08-2013 10:46 AM

This is in no way an endorsement of any of the suggestions of the linked thread:

There are some good ideas there, though.

Basically you're down to tracking it down via finding the process where all the time is going, determining what that process (or thread) does, and fixing it.

Yeah, I know...

All times are GMT -5. The time now is 01:10 AM.