If you see 16 entries, your machine is handling interrupts using PIC
(programmable interrupt controller). The other option, is APIC (which
may be a BIOS option). APIC has a couple features, such as being able
to forward interrupts to a particular processor on a multiprocessor
(or multicore) machine. APIC interrupt numbers also go a bit higher,
and the PCI bus INTA/B/C/D signals may be listed in 16..23 . APIC
can even be used on a single core computer, but in that case, there
is no need to steer the interrupts because they all go to the same
place.
http://en.wikipedia.org/wiki/Intel_APIC_Architecture
This is my Device Manager summary report in the interrupt section.
I'm running APIC. You can see there is still sharing going on.
On IRQ 18, my WinTV card (on PCI bus), the network interface (on PCI
Express
bus), and the chipset, are all sharing the same IRQ. Interrupt
handlers have to be able to deal with this sharing.
******************** IRQ SUMMARY ********************
IRQ Usage Summary:
(ISA) 0 System timer
(ISA) 1 Standard 101/102-Key or Microsoft Natural PS/2 Keyboard
(ISA) 6 Standard floppy disk controller
(ISA) 8 System CMOS/real time clock
(ISA) 9 Microsoft ACPI-Compliant System
(ISA) 13 Numeric data processor
(PCI) 15 Hauppauge WinTV 878/9 WDM Aux Driver
(PCI) 15 Intel(R) ICH9 Family SMBus Controller - 2930
(PCI) 16 Intel(R) X38/X48 Express Chipset PCI Express Root Port - 29E9
(PCI) 16 NVIDIA GeForce 7900 GT/GTO
(PCI) 16 Intel(R) ICH9 Family USB Universal Host Controller - 2937
(PCI) 16 Standard Dual Channel PCI IDE Controller
(PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 1 - 2940
(PCI) 17 Intel(R) ICH9 Family PCI Express Root Port 5 - 2948
(PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2939
(PCI) 18 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293C
(PCI) 18 Intel(R) ICH9 Family PCI Express Root Port 3 - 2944
<---
(PCI) 18 Marvell Yukon 88E8056 PCI-E Gigabit Ethernet Controller
<---
(PCI) 18 Intel(R) ICH9 Family USB Universal Host Controller - 2936
(PCI) 18 Hauppauge WinTV 878/9 WDM Video Driver
<---
(PCI) 19 Intel(R) ICH9 Family USB Universal Host Controller - 2935
(PCI) 19 VIA OHCI Compliant IEEE 1394 Host Controller
(PCI) 21 Intel(R) ICH9 Family USB Universal Host Controller - 2938
(PCI) 22 Microsoft UAA Bus Driver for High Definition Audio
(PCI) 22 Intel(R) ICH9R/DO/DH 4 port Serial ATA Storage Controller 1 -
29
(PCI) 22 Intel(R) ICH9 Family 2 port Serial ATA Storage Controller 2 -
29
(PCI) 23 Intel(R) ICH9 Family USB Universal Host Controller - 2934
(PCI) 23 Intel(R) ICH9 Family USB2 Enhanced Host Controller - 293A
I don't know of a tool for logging specific interrupt counts in Windows.
In Linux,
you can use /proc/interrupts to get the info. I still haven't figured
out how to do the equivalent of this in Windows.
http://www.linuxtopia.org/online_bo...istration_guide/centos5_s1-proc-topfiles.html
"3.2.11. /proc/interrupts
For a multi-processor machine, this file may look slightly different:
CPU0 CPU1
0: 1366814704 0 XT-PIC timer
1: 128 340 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
8: 0 1 IO-APIC-edge rtc
12: 5323 5793 IO-APIC-edge PS/2 Mouse
13: 1 0 XT-PIC fpu
16: 11184294 15940594 IO-APIC-level Intel EtherExpress Pro
10/100 Ethernet
20: 8450043 11120093 IO-APIC-level megaraid
30: 10432 10722 IO-APIC-level aic7xxx
31: 23 22 IO-APIC-level aic7xxx
NMI: 0
ERR: 0 "
In that example, APIC is able to steer interrupts to a particular CPU.
CPU0 is getting all the timer interrupts. A high count there would
not be a cause for concern, because the timer is being used by
the OS a lot.
I had great hopes for an article with this title, but in fact
the facilities available look pretty poor. "Disabling hardware"
is a pathetic way to debug things, especially in a case where
the hardware cannot be physically removed, to be sure it is
not affecting system state.
"Debugging an Interrupt Storm"
http://msdn.microsoft.com/en-us/library/ff540586(VS.85).aspx
According to this, when things share an IRQ, an ISR (interrupt
service routine) chain is used to sequentially attempt to service
the interrupt. Different ISRs are tried until the interrupt is cleared.
To get some idea what hardware is interrupting, you'd need
the ISR routine to count how many times it successfully
handled an interrupt. An ISR may queue up a DPC, to finish
handling the interrupt - a DPC runs at user level, rather
than interrupt level, and that allows the ISR to be fast
and lightweight. Process Explorer can show you the level of
DPC activity, which might be proof that real interrupt
events are happening (since they finish the servicing
needed by the hardware). If there was something wrong
with interrupts, perhaps you'd see a mismatch between
the time spent handling interrupts, and the amount of
DPC activity.
http://www.microsoft.com/whdc/archive/apic.mspx
"4. The operating system calls the first ISR in the chain.
5. The ISR probes the hardware and attempts to handle the interrupt.
6. If there are additional ISRs, the operating system goes on to
the next one and returns to step 5."
HTH,
Paul