http://bugzilla.kernel.org/show_bug.cgi?id=11000
Summary: kacpi_notify still takes 90% of cpu Product: ACPI Version: 2.5 KernelVersion: 2.6.25.6 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Distribution: Fedora 9 (problem has been seen in Ubuntu Hardy and earlier versions of both Fedora and Ubuntu). Hardware Environment: HP Pavilion 503n, Intel Celeron 1.7GHz and Pentium 4 Northwood (single core). Problem Description: Like the bugs mentioned at http://ubuntuforums.org/showthread.php?t=399619http://ubuntuforums.org/showthread.php?t=399619 and http://bugzilla.kernel.org/show_bug.cgi?id=10224http://bugzilla.kernel.org/show_bug.cgi?id=10224 , the kacpi_notify workqueue process consumes 90% of the CPU after things like a suspend or the CPU getting hot. After a lot of printk tracing, I found that acpi_thermal_notify (in thermal.c) with event type ACPI_THERMAL_NOTIFY_THRESHOLDS is triggered, leading to acpi_power_off_device (in power.c). When it gets to: status = acpi_evaluate_object(resource->device->handle, "_OFF", NULL, NULL); It does turn down the fan like it should, but it also triggers the acpi_ex_opcode_2A_0T_0R opcode, leading to a notify event, and the cycle begins again. Moreover, the ACPI driver can't determine the state of the fan (I've only heard it in high power and low power, never off). It also thinks it should turn down the fan when the CPU gets hot. However, these are separate issues that I'm not too concerned about. The kacpid and kacpi_notify problems appear in many different manifestations, and all of them are ostensibly due to buggy ACPI BIOS implementations. What I posted above is likely going to be a different call chain than someone else's. Nevertheless, these problems indicate that the ACPI driver should be able to detect when a workqueue is getting flooded and queue delayed events when it is. Steps to reproduce: On my system, letting the CPU get above 51C or so for a while or suspending and resuming will turn down (that's right, turn down) the fan and trigger the infinite CPU hogging. echo 3 > /proc/acpi/fan/FAN1/state will turn down the fan, but will not trigger the spinning. Proposed solution: Create a flood protection mechanism for events queued to kacpid and kacpi_notify. For instance, if more than 10 events are sent to one of these queues within a tenth of a second, more events should be delayed by 10 seconds until a timer elapses. Thus, normal operation should not be interfered with to a severe extent, and the kacpi_notify and kacpid queue flooding will cause unnoticeable impact. However, if a whole bunch of ACPI activity happens before the timer is put in place (e.g. the timer source is based on ACPI), my proposed general solution could possibly stall correct ACPI operation and not get the timer up and running at all. Thus, flood protection should be disabled until, say, ten seconds of ACPI driver uptime (thus verifying that the clock works). -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla