[2.6.7] Ehci controller interrupts like crazy on nforce2
Here it is: another nforce2 hardware bug. The ehci controller seems to send a massive number of interrupts to the kernel (264379 per second). This uses about 5 to 10% of the cpu. This shows up in top in the "hi"(hard interrupts) indicator. Nothing unusual shows up in the kernel log. My system has an Asus A7N8X Nforce2 Board with an Athlon XP 2800+ mounted on it.
[joe@omega3:~]$ cat /proc/interrupts ; sleep 1; cat /proc/interrupts
CPU0
0: 583513 XT-PIC timer
1: 1279 IO-APIC-edge i8042
7: 137293 IO-APIC-edge parport0
8: 0 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
14: 41463 IO-APIC-edge ide0
15: 23 IO-APIC-edge ide1
17: 9 IO-APIC-level EMU10K1
18: 18584 IO-APIC-level eth0
20: 121541873 IO-APIC-level ehci_hcd
21: 0 IO-APIC-level ohci_hcd
22: 0 IO-APIC-level ohci_hcd
NMI: 0
LOC: 583348
ERR: 0
MIS: 0
CPU0
0: 584760 XT-PIC timer
1: 1280 IO-APIC-edge i8042
7: 137578 IO-APIC-edge parport0
8: 0 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
14: 41505 IO-APIC-edge ide0
15: 23 IO-APIC-edge ide1
17: 9 IO-APIC-level EMU10K1
18: 18641 IO-APIC-level eth0
20: 121806252 IO-APIC-level ehci_hcd
21: 0 IO-APIC-level ohci_hcd
22: 0 IO-APIC-level ohci_hcd
NMI: 0
LOC: 584595
ERR: 0
MIS: 0
[joe@omega3:~]$Any help or random thougths are welcome.
Happy Hacking,
Joe
Quoted 6 lines · Jonathan Filiatrault
Here it is: another nforce2 hardware bug. The ehci controller seems to send a massive number of interrupts to the kernel (264379 per second). This uses about 5 to 10% of the cpu. This shows up in top in the "hi"(hard interrupts) indicator. Nothing unusual shows up in the kernel log. My system has an Asus A7N8X Nforce2 Board with an Athlon XP 2800+ mounted on it.
Well, I have the same system (board is Deluxe version) and no such situation.
Quoted 3 lines
[joe@omega3:~]$ cat /proc/interrupts ; sleep 1; cat /proc/interrupts
CPU0
0: 583513 XT-PIC timerHmm, I don't have this though. "IO-APIC-edge timer" is the closest in my box.
Quoted 15 lines
1: 1279 IO-APIC-edge i8042 7: 137293 IO-APIC-edge parport0 8: 0 IO-APIC-edge rtc 9: 0 IO-APIC-level acpi 14: 41463 IO-APIC-edge ide0 15: 23 IO-APIC-edge ide1 17: 9 IO-APIC-level EMU10K1 18: 18584 IO-APIC-level eth0 20: 121541873 IO-APIC-level ehci_hcd 21: 0 IO-APIC-level ohci_hcd 22: 0 IO-APIC-level ohci_hcd NMI: 0 LOC: 583348 ERR: 0 MIS: 0
[snip]
Quoted 1 line
20: 121806252 IO-APIC-level
ehci_hcd
[snip]
Quoted 1 line
Any help or random thougths are welcome.
Well, the "usual answer" is try enable/disable PREEMPT, upgrade BIOS. Also IO-APIC and APIC as a whole.
Here is my board:
$ cat /proc/interrupts
CPU0
0: 415667195 IO-APIC-edge timer
1: 184380 IO-APIC-edge i8042
8: 2 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
14: 865112 IO-APIC-edge ide0
15: 9195 IO-APIC-edge ide1
19: 31371344 IO-APIC-level nvidia
20: 8356973 IO-APIC-level ehci_hcd, NVidia nForce2, eth0
21: 0 IO-APIC-level ohci_hcd
22: 798076 IO-APIC-level ohci_hcd
NMI: 0 LOC: 415691931 ERR: 0
MIS: 0
$ bash -c 'cat /proc/interrupts ; sleep 1; cat /proc/interrupts'| grep ehci
20: 8357517 IO-APIC-level ehci_hcd, NVidia nForce2, eth0
20: 8357530 IO-APIC-level ehci_hcd, NVidia nForce2, eth0Signature · 3 lines
|| ~~~~~~~~~~~~~~~~~~~~~~ || ( ) http://ThinRope.net/ ( ) || ______________________ ||
Quoted 6 lines · Jonathan Filiatrault
Here it is: another nforce2 hardware bug. The ehci controller seems to send a massive number of interrupts to the kernel (264379 per second). This uses about 5 to 10% of the cpu. This shows up in top in the "hi"(hard interrupts) indicator. Nothing unusual shows up in the kernel log. My system has an Asus A7N8X Nforce2 Board with an Athlon XP 2800+ mounted on it.
I've seen this problem on my board (Epox 8RDA3+) as well. The root cause seems to be interrupt link devices enabled without regard for the actual device status. A recent patch that delayed IRQ assignment to device activiation time fixed this for me; you might want to try a fresh -mm or -bk kernel.
Hope that helps,
Daniel.
Quoted 5 lines
I've seen this problem on my board (Epox 8RDA3+) as well. The root cause seems
to be interrupt link devices enabled without regard for the actual device status. A recent patch that delayed IRQ assignment to device activiation time fixed this for me; you might want to try a fresh -mm or -bk kernel.
2.6.7-bk21 fixed this problem for me, thanks
Quoted 3 lines
Hope that helps,
it sure did.
Happy Hacking,
Joe