https://bugzilla.kernel.org/show_bug.cgi?id=15924
Len Brown <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Component|Config-Interrupts |Other AssignedTo|[email protected] |[email protected] | |.org --- Comment #7 from Len Brown <[email protected]> 2010-05-10 06:59:39 --- > /sys/firmware/acpi/interrupts/gpe01: 246416 enabled GPE01 appears to be the problem Does the kacpid thrashing stop after this? # echo disable > /sys/firmware/acpi/interrupts/gpe01 # cat /sys/firmware/acpi/interrupts/gpe01 > Device S-state Status Sysfs node > LANC S0 *disabled pci:0000:00:19.0 > HDEF S3 *disabled pci:0000:00:1b.0 > EHC1 S0 *disabled pci:0000:00:1d.0 > EHC2 S0 *disabled pci:0000:00:1a.0 > ... All of the devices in /proc/acpi/wakeup have the run_wake flag set in 2.6.34, while none had this set in 2.6.33 It should be possible to bisect which commit caused this regression, particularly if the bisect is limited to the PCI and ACPI code. GPE01's handler seems to be involved in PCI hotplug notifies: Method (_L01, 0, NotSerialized) { Add (L01C, 0x01, L01C) \_SB.PCI0.RP01.HPLG () \_SB.PCI0.RP02.HPLG () \_SB.PCI0.RP03.HPLG () \_SB.PCI0.RP04.HPLG () \_SB.PCI0.RP05.HPLG () \_SB.PCI0.RP06.HPLG () } It isn't immediately clear from the AML how the handler clears the event that caused the interrupt. BTW. there seem to be checksum errors in the acpi tables, please attach the full output from acpidump -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are watching the assignee of the bug. ------------------------------------------------------------------------------ _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
