Bug 5312

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.