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
Created attachment 6150 [details] output of dmesg just after boot
Created attachment 6151 [details] dmesg output when using pci=routeirq
Created attachment 6152 [details] /proc/interrupts
Created attachment 6153 [details] /proc/interrupts when using pci=routeirq
Created attachment 6154 [details] lspci output
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] acpidump output
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.
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: 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.
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.
Bjorn's cpqphp patch from comment #10 shipped in linux-2.6.15 closed.