Most recent kernel where this bug did not occur: the last without pci=routeirq
Distribution: Gentoo Linux
Hardware Environment: Intel AC450NX 4xPIII 4Gb Ram
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
Created attachment 6150 [details]
output of dmesg just after boot
Created attachment 6151 [details]
dmesg output when using pci=routeirq
Created attachment 6152 [details]
Created attachment 6153 [details]
/proc/interrupts when using pci=routeirq
Created attachment 6154 [details]
Created attachment 6155 [details]
lspci output when using pci=routeirq
Created attachment 6156 [details]
/dev/vcs0 of top showing kacpid at 95% cpu
Created attachment 6157 [details]
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
0000:00:0c.0 VGA compatible controller: Cirrus Logic GD 5446
0000:02:08.0 PCI Hot-plug controller: Compaq Computer Corporation PCI
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
Created attachment 6164 [details]
add pci_enable_device() calls
it seems fixed.
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?
Yes, I confirm you that it works with just the cpqphp patch.
bjorn, looks like you nailed it.
how would you like to proceed?
> how would you like to proceed?
I posted the cpqphp patch yesterday:
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.
I'm running gentoo-sources 2.6.14-r2 that is vanilla 22.214.171.124 + other patches,
and I still need to apply your patch manually. It isn't included in the
official sources yet.
Bjorn's cpqphp patch from comment #10 shipped in linux-2.6.15