Bug 5312 - when booting without pci=routeirq, kacpid eats 100% cpu time - AC450NX
Summary: when booting without pci=routeirq, kacpid eats 100% cpu time - AC450NX
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Bjorn Helgaas
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-26 00:40 UTC by Bruno Redondi
Modified: 2007-03-07 23:18 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.12.5
Tree: Mainline
Regression: ---


Attachments
output of dmesg just after boot (25.25 KB, text/plain)
2005-09-26 00:42 UTC, Bruno Redondi
Details
dmesg output when using pci=routeirq (26.26 KB, text/plain)
2005-09-26 00:42 UTC, Bruno Redondi
Details
/proc/interrupts (1.51 KB, text/plain)
2005-09-26 00:43 UTC, Bruno Redondi
Details
/proc/interrupts when using pci=routeirq (1.51 KB, text/plain)
2005-09-26 00:44 UTC, Bruno Redondi
Details
lspci output (5.59 KB, text/plain)
2005-09-26 00:44 UTC, Bruno Redondi
Details
lspci output when using pci=routeirq (5.59 KB, text/plain)
2005-09-26 00:45 UTC, Bruno Redondi
Details
/dev/vcs0 of top showing kacpid at 95% cpu (1.95 KB, text/plain)
2005-09-26 00:47 UTC, Bruno Redondi
Details
acpidump output (125.53 KB, text/plain)
2005-09-26 00:47 UTC, Bruno Redondi
Details
add pci_enable_device() calls (1.31 KB, patch)
2005-09-26 14:27 UTC, Bjorn Helgaas
Details | Diff

Description Bruno Redondi 2005-09-26 00:40:46 UTC
Most recent kernel where this bug did not occur: the last without pci=routeirq 
parameter 
Distribution: Gentoo Linux 
Hardware Environment: Intel AC450NX 4xPIII 4Gb Ram 
Software Environment:  
Problem Description: When I boot without the "pci=routeirq" parameter the 
kacpid process eats completly one cpu; when i pass "pci=routeirq" parameter the 
system runs fine. 
Steps to reproduce: boot without the parameter
Comment 1 Bruno Redondi 2005-09-26 00:42:01 UTC
Created attachment 6150 [details]
output of dmesg just after boot
Comment 2 Bruno Redondi 2005-09-26 00:42:51 UTC
Created attachment 6151 [details]
dmesg output when using pci=routeirq
Comment 3 Bruno Redondi 2005-09-26 00:43:33 UTC
Created attachment 6152 [details]
/proc/interrupts
Comment 4 Bruno Redondi 2005-09-26 00:44:13 UTC
Created attachment 6153 [details]
/proc/interrupts when using pci=routeirq
Comment 5 Bruno Redondi 2005-09-26 00:44:48 UTC
Created attachment 6154 [details]
lspci output
Comment 6 Bruno Redondi 2005-09-26 00:45:27 UTC
Created attachment 6155 [details]
lspci output when using pci=routeirq
Comment 7 Bruno Redondi 2005-09-26 00:47:02 UTC
Created attachment 6156 [details]
/dev/vcs0 of top showing kacpid at 95% cpu
Comment 8 Bruno Redondi 2005-09-26 00:47:39 UTC
Created attachment 6157 [details]
acpidump output
Comment 9 Bjorn Helgaas 2005-09-26 14:25:12 UTC
Here are the interesting things I noticed.  Maybe there's a clue somewhere. 
/proc/interrupts shows a ton of acpi interrupts, which is probably why 
you're seeing kacpid running all the time: 
 
  -  9:     181084     431598     169541          0   IO-APIC-level  acpi 
  +  9:          0          0          0          0   IO-APIC-level  acpi 
 
Without "pci=routeirq", there are two interrupts we don't enable: 
  ACPI: PCI Interrupt 0000:00:0c.0[A] -> GSI 48 (level, low) -> IRQ 48 
  ACPI: PCI Interrupt 0000:02:08.0[A] -> GSI 19 (level, low) -> IRQ 19 
which are: 
  0000:00:0c.0 VGA compatible controller: Cirrus Logic GD 5446 
  0000:02:08.0 PCI Hot-plug controller: Compaq Computer Corporation PCI 
Hotplug Controller 
 
The cpqphp driver looks like it's missing a pci_enable_device() call. 
I'll attach a patch to add it.  I don't know whether it will make a 
difference, but worth trying. 
 
Another interesting thing is that although the i2c_piix4 driver bails 
out and doesn't do anything with the SMBus controller, lspci shows 
that the device is assigned to IRQ 9: 
 
  0000:00:0f.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02) 
	Flags: medium devsel, IRQ 9 
 
i2c_piix4 is also missing a pci_enable_device() (as are all the 
other i2c drivers). 
 
And there's this: 
  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) 
which looks like the opposite of PCI interrupts (which are level, 
low).  But I don't see what difference "pci=routeirq" would make 
here. 
Comment 10 Bjorn Helgaas 2005-09-26 14:27:06 UTC
Created attachment 6164 [details]
add pci_enable_device() calls
Comment 11 Bruno Redondi 2005-09-27 12:07:19 UTC
it seems fixed. 
Comment 12 Bjorn Helgaas 2005-09-27 15:13:00 UTC
Thanks very much for testing this.  I'd like to narrow this down  
and determine which patch actually fixed the problem.  I suspect  
it was the cpqphp fix; can you back out the i2c_piix4 change and 
try with just the cpqphp patch? 
Comment 13 Bruno Redondi 2005-09-27 19:51:40 UTC
Yes, I confirm you that it works with just the cpqphp patch. 
Comment 14 Len Brown 2005-09-28 18:15:30 UTC
bjorn, looks like you nailed it.
how would you like to proceed?
Comment 15 Bjorn Helgaas 2005-09-29 08:16:56 UTC
> how would you like to proceed? 
 
I posted the cpqphp patch yesterday: 
  http://sourceforge.net/mailarchive/forum.php?thread_id=8335665&forum_id=765 
 
Do you see anything else that needs to be done? 
 
I am still worried about the INT_SRC_OVR that makes GSI 9 
(high,level), and the PIIX4 SMbus controller that says it's 
on IRQ 9 (device 0f.3).  Since it's a PCI device, that would 
be (low,level).  But as far as I can tell, the i2c drivers 
don't use interrupts anyway.  I just don't understand this 
very well, so maybe it's a baseless worry. 
Comment 16 Bruno Redondi 2005-11-14 00:00:24 UTC
I'm running gentoo-sources 2.6.14-r2 that is vanilla 2.6.14.2 + other patches,  
and I still need to apply your patch manually. It isn't included in the  
official sources yet. 
Comment 17 Len Brown 2007-03-07 23:18:16 UTC
Bjorn's cpqphp patch from comment #10 shipped in linux-2.6.15
closed.

Note You need to log in before you can comment on or make changes to this bug.