Bug 57871
| Summary: | Cpu frequency scaling not working after waking up from suspend. | ||
|---|---|---|---|
| Product: | Power Management | Reporter: | Robert Csordas (xdever) |
| Component: | cpufreq | Assignee: | Rafael J. Wysocki (rjw) |
| Status: | CLOSED DUPLICATE | ||
| Severity: | normal | CC: | antonisp, lenb, rjw, rui.zhang, tianyu.lan, viresh.kumar |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.9 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | Dmesg, cpuinfo and kernel config | ||
If it is possible, can you bisect where this broke? If we can identify the offending commit, then changes of a prompt fix are very high. BTW. how are you measuring the 0.2 watts greater power used when using the intel_pstate driver -- and do you also observe any difference in performance? What do You mean under bisecting? To try out every version from the last working one (binary search may help :))? Before this I used 3.8.5, and there it was working properly (except e1000e bug, which was needed to be patched manually, but in 3.9 it's finally fixed). I measured the power consumption with powertop. I "simulated" reading a pdf paper by opening one. I disabled network connections (wireless disabled, ethernet cable pulled out) and measured the power usage with powertop. With intel_pstate, the power usage when iddle is about 6.8W, but without it it's about 6.6 (with minimal brightness in both cases). I doesn't checked the power usage under load. Now I will try out the newest kernel and if I have time (probably tomorrow) I will try out older versions. > --- Comment #3 from Robert Csordas <xdever@gmail.com> 2013-05-14 09:23:41 > --- > What do You mean under bisecting? To try out every version from the last > working one (binary search may help :))? https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html Sorry about rare answering, but I'm super busy now with exam period on the university. The problem is that testing a single kernel takes up to 20 minutes. Now I'm on 3.9.3, with P-state enabled. It really consumes less power when CPU is not iddle. But the problem still present with this version too. And when waking up, the CPUs run at >3GHz speed (typically 3.2GHz). Also, the minimal frequency of my CPU I can see with P-state enabled is 1.7GHz, whereas without it it's 800MHz. Is this normal? As soon as I finish my exams I will bisect the kernels. Thank You and sorry about the delay Last friday I finished with my exams, so I can finally work on debugging this issue. I made another search before started bisecting, and I found the following thread: https://bugzilla.kernel.org/show_bug.cgi?id=58971 Here Alexander Kaltsas have bisected that a comit related to i915 causes the problem (comit 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9). So I tried to remove these changes from my current kernel (3.9.5). It works now MUCH better, but it's not good yet. Now I tried it 20-25 times, and it locked only once to max speed. This is significant improvement from the 1 out of 3, but also makes the testing much harder. Another interesting thing: My CPUs are 2.7GHz rated. The turbo mode is enabled by default. I tried yesterday to manually disable turbo by writing 38th bit of msr 0x1a0 to 1. Now i7z says TURBO DISABLED as expected, but when the max frequency bug happens, it always locks to 3.3-3.4GHz. I can confirm that the same issue of frequency scaling working inadequately after suspend (not 100% of the times, suspending and awaking a few times helps). The kernel version I have is 3.9.8-300.fc19.x86_64 and the cpu is Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz (Thinkpad t520). (In reply to Robert Csordas from comment #6) > Last friday I finished with my exams, so I can finally work on debugging > this issue. I made another search before started bisecting, and I found the > following thread: > > https://bugzilla.kernel.org/show_bug.cgi?id=58971 > > Here Alexander Kaltsas have bisected that a comit related to i915 causes the > problem (comit 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9). So I tried to > remove these changes from my current kernel (3.9.5). It works now MUCH > better, but it's not good yet. Now I tried it 20-25 times, and it locked > only once to max speed. This is significant improvement from the 1 out of 3, > but also makes the testing much harder. From this result, this is the same issue as bug 58971. So mark this as duplicated bug and keep all infos in the bug 58971. > > Another interesting thing: My CPUs are 2.7GHz rated. The turbo mode is > enabled by default. I tried yesterday to manually disable turbo by writing > 38th bit of msr 0x1a0 to 1. Now i7z says TURBO DISABLED as expected, but > when the max frequency bug happens, it always locks to 3.3-3.4GHz. You'd better to disable turbo via echo " echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo". *** This bug has been marked as a duplicate of bug 58971 *** |
Created attachment 101031 [details] Dmesg, cpuinfo and kernel config Environment: Thinkpad X220, Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz, Gentoo Description. I use 3.9 mainline kernel, with intel_pstate disabled (with intel pstate it uses ~0.2W more power when reading pdf document than without it). Since kernel 3.9, when my machine wakes up from suspend, in about 1 cases out of 3 the CPU scaling won't work and the CPU-s are stucked at 2.7GHz maximal speed. The machine becomes hot. Top shows nothing using the cpu. When I notice that the machine is hot, I put it back to suspend, and when I wake it up again it works as it should. Attachements: I attached dmesg, cpuinfo and my kernel configuration. The dmesg is long since the machine is running more than 1 days, but in the resume before the last it was overheating and in the last one it is not overheating.