This is a weird issue but I haven't noticed it before, i.e. with previous cpufreqd. With this version the laptop CPU goes 100% a 2 seconds after closing the lid. Currently the when the Lid is closed the hardware generates about 2 events per second. So basically it's kinda like flooding acpid. In this situation, at start kacpid module goes from 10% to 30% while the lid button is pressed and quickly down after releasing the button. After releasing the lid button acpid goes to 3% and stays there until the events stop (checked the log for that) and cpufreqd goes to 33% but the total CPU is at 100%. After acpid stops logging cpufreqd stops too and CPU goes back to 1%~3%. cpufreqd uses pmu acpi acpid uses logrotate This problem was noticed with cpufreqd-2.1.1. Latest cpufreqd (2.2.0-r2) has the same issues. 2.1.0 was not tested, and 2.0.0 works fine. With cpufreqd-2.0.0, even when the lid is closed, the CPU is never above 7%. PS: Also logging all the events can cause huge logs, 8 hours with the lid closed generated an 800Mb log. But that's another story... If anyone knows a way to prevent these huge logs besides logrotate I would appreciate the tip.
Hello, I suppose an easy workaround would be to disable cpufreqd ACPI events processing by setting a bogus path in the [acpi] section just after the [General] one: [acpi] acpid_socket=/some/nonexistent/path [/acpi] BTW: cpufreqd should spit some error in the logs or stderr if started with -D Can you test it? Thanks Mattia
Ok did a little testing. 1st try was to disable the acpi flag, but that disables the whole acpi system so without any flag cpufreqd does not give the 100% CPU but also doesn't react to acpi events such as AC plug, battery and temperature events. with the suggested -D it shows: init_configuration : Unknown [acpi]: nobody handles it. (...) parse_config_rule : WARNING! skipping config option "acpi_temperature" which is obvious. I noticed that the default cpufreqd behavior is to connect to the acpid.socket. I had the acpi socket part commented and still the cpu overuse happened. By using the suggested setting problem was solved: cpufreqd -D acpi_event_init : Couldn't connect to acpid socket /nowhere/acpid.socket (No such file or directory). This way it no longer abuses cpu and still reacts to AC plug, battery and temperature events. (I only tested AC and battery, but I assume that temperature works fine too). I would suggest disabling by default the acpid.socket and only enable it if defined in the conf. Either that or some sort of "flood" prevention measures. acpid deals with this flooding by delaying the reaction time. Sometimes I open the lid and acpid keeps processing the events for quite a long time (depending on the number of events generated meanwhile) even if I no longer have the lid closed. This might not be the right approach cause if I define an action in acpid that reacts to the lid event, well you see the picture... Thanks for you suggestion it solves the problem. I hope you can solve this nasty bug in the next release. Cheers PS: I believe this bug is fixed for now.
Please inform upstream. I can't reproduce that, but my laptop with closed lid isn't producing events every 2 secs, just once...
I'm cc-ed to the bug, thanks :)
