Bug 9151
| Summary: | Something broke cpufreq on laptop with lid behavior between 2.6.17 and 2.6.23 | ||
|---|---|---|---|
| Product: | Power Management | Reporter: | steve (stevenm) |
| Component: | cpufreq | Assignee: | Thomas Renninger (trenn) |
| Status: | CLOSED DUPLICATE | ||
| Severity: | normal | CC: | acpi-bugzilla, deller, lenb |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.23 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | Dmesg output with odd behavior and cpufreq.debug=7 | ||
|
Description
steve
2007-10-12 10:07:15 UTC
Please boot with cpufreq.debug=7 and after it's done some strange behaviour, capture dmesg, and attach that here. Created attachment 13148 [details]
Dmesg output with odd behavior and cpufreq.debug=7
There is the debug info. Messages starting with ** are echoed by me into kmsg so that you can see what I tried to do then. The system was booted up using battery power and then an AC adapter was attached when indicated. This time it didn't do any odd things with throttling, but it definitely magically shot up to 2GHz and wouldn't go to 600MHz unless I set it to 800MHz first. The test was done in a console environment without any windowing stuff or KDE battery monitor running. ACPID and laptop_mode were removed from rc.d before the system was booted with this kernel.
Is there any new information on this issue? I'm still stuck on 2.6.17 or thereabouts. I guess I should point out that this is the speedstep-centrino driver that driver has been deprecated for quite a while in favour of acpi-cpufreq. Does that driver work ? Switched to acpi-cpufreq. Still occurring as far as I can tell. Will do more testing soon. > When AC power is unplugged, the system clocks to its lowest speed but it also > throttles to 25%. I don't want the throttling and have to un-throttle it by > hand. I've seen this bug before in the SuSE user-space. Somebody got the idea that T-states save energy, so they enable them when on battery. I thought that they fixed it, but apparently they only disabled this nonsense on MP systems, and UP systems remain broken. There should be a check box someplace in the powersaved GUI to disable this. The mystery is why you didn't see it also in 2.6.17. Also, if the system is idle and running a sane governor like ondemand, you should be in the lowest P-state both before and after the transition from AC->DC. > ... The governor switches to powersave. If the lid is closed > on battery power, the CPU frequency begones the HIGHEST (2GHz). > scaling_min_freq and scaling_max_freq report 600MHz but scaling_cur_freq > reports 2GHz. This again sounds like broken user-space policy software. See if this still happens when in single-user mode and none of that junk is running. But again, the mystery is why you don't see the same issue with the same user-space and the 2.6.17 kernel. My tests were done in single-user mode, console, no X, no laptop-mode, no dbus or hal, nothing. As far as I could tell (and I stared at ps -e for a long time) nothing could be running that was changing the CPU frequency, not even acpid. The fact that the system was thinking it was at one frequency and actually being at another (hence refusing to change) tells me it is a kernel problem. Ie, I set it to 600. It is stuck at 2000. Setting it to 600 has no effect. But setting it to 800 and then 600 worked fine. Go figure I see this problem sometimes too. (acpi-cpufreq driver does not speed down) System: HP NC6000 Laptop, Pentium M 1.6GHz, Fedora7, Kernel 2.6.24-rc4. When running on AC at full CPU speed, then plugging AC, CPU speed stays at 1600 MHz. Even when switching manually to powersafe governour, acpi-cpufreq does not change back to 600 MHz. It seems it thinks it is already running on 600 MHz. Only when I switch to ondemand and then back to powersafe governour the speed finally goes down to 600 MHz. Yup! Stiiilll happening! Extremely annoying. Unplug AC, open lid... 2GHz. And sometimes it gets STUCK there! That is, set to 600 and it jumps right back to 2GHz. Have to go through some intermediate speed first. Oh, and it insists on going into 25% throttling when on battery power, but at least THAT I can set to 0% and it will stay. Still annoying as crap, however. On a Dell, I expect this is because the BIOS itself sets the frequncy when (un-)plugging AC behind the kernel's back, instead of sending a ACPI notify 0x80 on the CPU and let the OS reevaluate _PPC and then let the kernel adjust frequency (it should do this also, but it also sets the freq itself AFAIK). I try to get a DELL and track this down. I take over this bug and hope I can set it to a duplicate to bug #9708, these are the same... *** This bug has been marked as a duplicate of bug 9708 *** |