Bug 65301

Summary: Cores stuck at max frequency after resume from suspend (Haswell)
Product: Power Management Reporter: Mykal Valentine (zoku88)
Component: cpufreqAssignee: cpufreq
Severity: normal CC: marcin.konarski, tianyu.lan, tomas.ivanek
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: v3.12 Subsystem:
Regression: No Bisected commit-id:
Attachments: ver_linux, cpuinfo and lspci outputs

Description Mykal Valentine 2013-11-21 09:34:03 UTC
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.
Comment 1 tomasi 2013-11-24 07:16:23 UTC
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

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
Comment 2 Lan Tianyu 2013-11-25 02:08:57 UTC
Did the cpufreq work normally after system resume before?
Comment 3 Mykal Valentine 2013-11-25 03:09:26 UTC
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.
Comment 4 Lan Tianyu 2013-11-25 03:28:56 UTC
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.
Comment 5 Mykal Valentine 2013-11-25 09:08:34 UTC
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...
Comment 6 tomasi 2013-11-25 20:22:19 UTC
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.
Comment 7 Marcin Konarski 2013-11-25 22:15:04 UTC
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

Comment 8 Mykal Valentine 2013-11-26 01:20:00 UTC
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.
Comment 9 tomasi 2013-11-28 08:15:52 UTC
i have same symptoms as Mykal.
Suspend and resume doesn't fix the issue.
Comment 10 Lan Tianyu 2013-12-09 03:26:03 UTC
Hi all, could you check whether this bug is the same as bug 66581?
Comment 11 Mykal Valentine 2013-12-09 05:49:18 UTC
Looking at it, it looks like the exact same thing to me.
Comment 12 Lan Tianyu 2013-12-09 05:52:34 UTC
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 ***