Created attachment 115381 [details] ver_linux, cpuinfo and lspci outputs The problem is that even though CPU usage is at ~0%, the cores are always stuck at their max frequency after resume. I thought this was related to https://bugzilla.kernel.org/show_bug.cgi?id=58971 However, I cloned the kernel git repo and checked out the commit that fixed that bug (7dcd2677ea912573d9ed4bcd629b0023b2d11505), and the fix had no effect (maybe SNB only?). So, this seems like it might have a different cause. I have attached my system information. As I've only had this laptop since around the time linux 3.11 came out, I'm not really sure when the last time this didn't happen, though that commit seems to have been made on top of one of the linux 3.10 rc's.
I can confirm on Lenovo T440s with Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz after resume cpu is set on max bio@dell-xps:/sys/devices/system/cpu/cpu0/cpufreq$ sudo cat cpuinfo_cur_freq 2543476 Linux dell-xps 3.12.0-031200-generic #201311031935 SMP Mon Nov 4 00:36:54 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Did the cpufreq work normally after system resume before?
I'm not really sure. I know it definitely didn't work normally in 3.11 or that version of 3.10rc that I pulled that had the i915 bug fix either. I think versions before that commit would run into the i915 bug, though. which I think also causes the frequency for the cores to stay high after resume.
This origin bug is introduced by commit 15239099 "drm/i915: enable irqs earlier when resuming." which is merged v3.9-rc5. So the v3.8 or v3.9-rc1~rc4 maybe safe to test.
Just tried, it doesn't seem like I'm able to boot with 3.8 or 3.9 rc kernels... Not really sure why? The screen turns black at some point during boot sequence, some point after fsck. Maybe those kernels miss some commits needed for haswell IGPs or something...
Hi, Whole CPU frequency managment is broken somehow. i5-4200U CPU @ 1.60GHz CPU should support 800 Mhz, But i see it's running at least on 1.6 Ghz. (After suspend/resume It's running in Turbo mode) bio@dell-xps:/sys/devices/system/cpu/intel_pstate$ cpufreq-info cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 0.97 ms. hardware limits: 800 MHz - 2.60 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 800 MHz and 2.60 GHz. The governor "powersave" may decide which speed to use within this range.
I can confirm on Lenovo T420i with Intel(R) Core(TM) i3-2370M CPU @ 2.40GHz, after resume from hibernation CPU is stuck at 2.4GHz although top show that system has 0% load. When system is stuck at maximum frequency I can unstuck it by performing suspend to RAM and waking up. Linux ubiquitous 3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13) x86_64 GNU/Linux Regards.
Marcin: I'm not sure if that's the exact same problem, given that resuming from suspend to RAM was what I was filing the bug on, which seems to function as a workaround for another issue that you're seeing. Unfortunately, I wasn't very clear with the original bug report to state that. Incidentally, I haven't tested resume from hibernate. Also, since there was a bug in i915 for SNB, you should make sure that you're not hitting that bug. I wasn't sure what version that bug fix got in (either 3.11 or 3.12), but I would recommend trying 3.12 on your system to see if the problem persists, just in case 3.11 didn't have the fix. Or checking out/compiling commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 to see if that fixes your problem.
Hi, i have same symptoms as Mykal. Suspend and resume doesn't fix the issue.
Hi all, could you check whether this bug is the same as bug 66581?
Looking at it, it looks like the exact same thing to me.
Ok. Let's reply all in the bug 66581 and mark this bug as duplicate. *** This bug has been marked as a duplicate of bug 66581 ***