Distribution: ARCH Hardware Environment: Sony Vaio VGN-TT11/LN Problem Description: kacpid(_notify) constantly use 60-70% of CPU time [mike@pygmytarsier ~]$ ps aux | grep acpi root 16 60.7 0.0 0 0 ? R< 15:35 108:15 [kacpid] root 17 7.3 0.0 0 0 ? S< 15:35 13:06 [kacpi_notify] hal 4758 0.0 0.0 2008 856 ? S 15:35 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket root 5121 0.0 0.0 1680 580 ? Ss 15:39 0:00 /usr/sbin/acpid Looks like I have a lot of interrupts: [mike@pygmytarsier ~]$ vmstat 1 10 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 1038288 70120 468648 0 0 13 19 650 1605 6 37 56 1 1 0 0 1037648 70120 468648 0 0 0 0 9276 15695 12 38 50 0 1 0 0 1038268 70120 468648 0 0 0 0 9759 16271 10 38 52 0 2 0 0 1037804 70120 468648 0 0 0 0 9528 16428 11 40 49 0 3 0 0 1038252 70120 468648 0 0 0 0 9488 16373 11 39 50 0 2 0 0 1037788 70120 468648 0 0 0 0 9382 16174 12 39 50 0 2 0 0 1038284 70120 468648 0 0 0 0 9205 15838 10 40 50 0 1 0 0 1037884 70120 468648 0 0 0 0 9582 16460 11 38 51 0 1 0 0 1038300 70120 468648 0 0 0 0 9498 16398 12 39 50 0 3 0 0 1037884 70120 468648 0 0 0 0 9304 16126 11 37 51 0 [mike@pygmytarsier ~]$ uptime && cat /proc/interrupts 18:34:36 up 2:59, 5 users, load average: 1.49, 1.40, 1.29 CPU0 CPU1 0: 1899738 1986042 IO-APIC-edge timer 1: 7561 7887 IO-APIC-edge i8042 6: 2 1 IO-APIC-edge sony-laptop 8: 6 9 IO-APIC-edge rtc0 9: 22085708 21992064 IO-APIC-fasteoi acpi 12: 114445 120810 IO-APIC-edge i8042 20: 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb6, uhci_hcd:usb7, uhci_hcd:usb8, yenta 21: 977 953 IO-APIC-fasteoi HDA Intel, ohci1394 22: 0 0 IO-APIC-fasteoi mmc0 23: 202159 197711 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb3, uhci_hcd:usb4, uhci_hcd:usb5 761: 146325 150727 PCI-MSI-edge iwlagn 762: 25778 24263 PCI-MSI-edge i915@pci:0000:00:02.0 764: 13004 14253 PCI-MSI-edge ahci NMI: 0 0 Non-maskable interrupts LOC: 1998012 1935167 Local timer interrupts RES: 19789098 27011292 Rescheduling interrupts CAL: 28 66 Function call interrupts TLB: 165 189 TLB shootdowns TRM: 0 0 Thermal event interrupts SPU: 0 0 Spurious interrupts ERR: 0 MIS: 0 Note: I just guessed a bug component...
Created attachment 20398 [details] acpidump
Created attachment 20399 [details] dmesg
please attach the result of "grep . /sys/firmware/acpi/interrupts/*"
Created attachment 20404 [details] grep . /sys/firmware/acpi/interrupts/*
> 9: 22085708 21992064 IO-APIC-fasteoi acpi > /sys/firmware/acpi/interrupts/sci: 26 the ACPI interrupts info in comment #4 is got when there is no ACPI interrupt storm, isn't it? please re-attach this info when the interrupt storm occurs, e.g. kacpid(_notify) start to use 60-70% of CPU time.
Uh right, sorry I didn't notice... Today I booted with AC not plugged in and kacpid keeps calm. I'll reboot as soon as I'm in the office.
Rebooted with AC plugged in--still behaves nicely. Anything I can provide in the meantime?
so the bug is hard to reproduce? hmm, please un/plug the ac adapter or battery, open/close the lid, etc. try to trigger as many kinds of ACPI event as possiblem, and check if the interrupt storm occurs.
Okay, this is a bit strange, but I had hibernated MS Vista before booting Linux the first time today. After resuming Vista and really rebooting into Linux kacpid got back its power.
Created attachment 20406 [details] grep . /sys/firmware/acpi/interrupts/*
Okay, just repeated what I was explaining earlier. Rebooted into Vista and hibernated. Then booted Linux and kacpid shut up.
does the problem still exist if you boot with "acpi_enforce_resources=strict"?
Yes, the probelm persists with this boot option.
Just tried again the Vista-hibernating approach, it reproducibly works. Shall I enable acpi debugging in my kernel, try a newer kernel, etc?
then how about removing the sony-laptop driver? From the acpidump, Method (_L15, 0, NotSerialized) { Store (0x44, P80H) If (\_SB.PCI0.LPC.SNC.FSTS) { Store (0x55, P80H) Store (One, \_SB.PCI0.LPC.SNC.INTS) \_SB.PCI0.SBUS.SWRB (0x72, 0x86, Zero) \_SB.PCI0.LPC.SNC.SNNE (0x012F) } } we know that GPE15 handler does a lot of work related with ACPI sony-laptop driver and SMBUS driver. It would be good to know if there is any previous kernel release that this problem doesn't exist in. CC Mattia.
Problem also occurs when sony-laptop is not loaded.
how do you reproduce the bug? we know that the laptop works well if we enter windows and do a hibernation, then when the problem comes back again? after a Linux reboot?
Exactly, after a cold boot or a reboot into Linux the problem occurs. When booting into Linux after hibernation of Windows, kacpid behaviour seems nice.
From the comment #18 it seems that it can work well after hibernation on windows. Will you please do the hibernate/resume on linux and then see whether the kcapid can work well? Will you please also try the debug patch in http://bugzilla.kernel.org/show_bug.cgi?id=11857#C62? thanks.
please attach the output of lspci -vvxxx
Please see http://bugzilla.kernel.org/show_bug.cgi?id=12816#c6
(In reply to comment #21) > Please see http://bugzilla.kernel.org/show_bug.cgi?id=12816#c6 > no, this is the lspci -vx please attach the lspci -vvxxx instead.
Sorry, here we go.
Created attachment 20638 [details] lspci -vvxxx sudo lspci -vvxxx after hibernating Windows
Will you please do the test as required in comment #19 and then see whether the kacpid can work well? Thanks.
how about not load i801_smbus driver? Since the _L15 method will use smbus, which might conflict with smbus driver.
Created attachment 20684 [details] try the custom DSDT Will you please try the custom DSDT and see whether the issue still exists? How to use the custom DSDT can be found in : http://www.lesswatts.org/projects/acpi/faq.php As the DSDT.hex is attached, the first four steps can be skipped. After the test, please attach the output of "grep . /sys/firmware/acpi/interrupts/*". Thanks.
ping Michael
close this bug because there is no response from the bug reporter for more than 1 month. please re-open it if you can provide the info requested in the above comments.