Windows 7 - Hardware interrupts and High CPU time

Asked By Mycroft Holmes on 05-Apr-07 05:13 AM
Hi,

I've got a new pc (Athlon64 x2 5200, Mainboard ASUS Crosshair nforce 590
SLI, 4x1GB ram, pcie GeForce 7900, and a pcie Promise 8350 raid controller).
I realized using Process Explorer that IRQs consume constantly 40% of the
CPU time.

What is the standard procedure to track the problem?
1) I disabled all devices non-vital devices from bios (except video card and
raid controller -- windows is installed on a raid partition and there's no
other hard drive connected) and the problem still persists.
2) there's a mysterious error in event log, which occurs once per boot,
saying more or less "IRQARB: ACPI BIOS says there's a device named
_SB_.PCI0.APC0 on IRQ18 but the device cannot be found)
3) I formatted and reinstalled a fresh copy of windows 2003 x64 SP2
(streamlined), the problem persists, even before installing drivers.

Is there a utility to see at least WHICH irq is being raised?

TIA,
MH




KarlPielor replied on 11-Apr-07 04:36 AM
Hi,

I have exactly the same problem on a dual Opteron 285 system here, running
XP Pro x64. Four CPU 'cores' show in Task Manager, one is pegged at 100% load
constantly, all 'Kernel Time'.

ProcessExplorer shows it's busy running Interrupt handling code - which
interrupt? Who knows?! :(

I've not found any way yet of getting windows to tell me which handler is
pegging the CPU.

I don't have an error like yours in the Event Log though. This system used
to work fine - and has just been re-installed.

I've tried with, and without all the AMD chipset drivers - they don't appear
to make any difference.

There must be some way of finding out which handler is spinning around in
circles?

Hoping someone will know :)

-Karl
Mycroft Holmes replied on 13-Apr-07 05:14 AM
After a looong and painful search, I collected the following information:
1) this IRQ level is usually a symptom of some hardware fault OR a bad
driver (which I exclude, since I observed the pc to run fine)
2) there's NO (free/shareware) utility that monitors IRQ in real time
3) try to boot in safe mode and see if the problem disappears (mine does
not)
4) if it does, boot nomally and try disabling devices one by one until you
find it
5) if it does not, it's one of the vital devices (ram/drive
controller/mainboard)
5A) try swapping/reducing ram banks
5B) try to attach your hard drive to a different controller (I cannot do
this...)
5C) try booting from a livecd and see if the problem persists

Hope this helps...
KarlPielor replied on 13-Apr-07 05:32 AM
I'd come to pretty much the same conclusion - it's annoying there's just no
way of finding out *what* interrupt is running so often :(

I've also tried Vista x64 on the same system - and it *doesn't* have the
same problem - but, there's just not enough driver support for me to leave
that on there [even installing stuff like VS2005 under Vista was scary enough
to put me off].

So - I'm kind of resigned to leaving it 'as is' at the moment. I can't not
afford to have the machine working. I may try the motherboard manufacturer -
Tyan, to see if they have any suggestions...

Thanks for your reply anyway,

-Karl
Mycroft Holmes replied on 17-Apr-07 10:15 AM
I think - but it's not exactly my research field, so I could be totally or
partially wrong - that you could write a driver (with windows ddk), and
declare that you want to be signaled when an interrupt fires, and somehow
the OS will pass you an integer, representing a mask with the interrupts
that fired (they you can do whatever, without user interaction, say, you can
log it to a file)

If you say that Vista does not have the same problem, it sounds like a
driver problem.
For example, I had windows 2003 x64/x86 in dual boot, and the problem
occurred in BOTH, so it's likely a true hardware failure...