Bug 58971

Just a correction. Last good kernel was 3.8.11 not 3.8.7.

Please provide the output of acpidump. Could you do a bisect between v3.8.11 and v3.9 to find which commit causing this issue?

I started a git bisect but I couldn't use the produced kernel (kernel panic at early boot). I trying to solve it and continue.

Something else. git tag out is

v3.8
v3.8-rc1
v3.8-rc2
v3.8-rc3
v3.8-rc4
v3.8-rc5
v3.8-rc6
v3.8-rc7
v3.9
v3.9-rc1
v3.9-rc2
v3.9-rc3
v3.9-rc4
v3.9-rc5
v3.9-rc6
v3.9-rc7
v3.9-rc8

I used v3.8 good, v3.9 bad. I did it correctly? No version 3.8.11.

I am attaching the acpidump output.

Created attachment 102991 [details]
acpidump output.

(In reply to comment #3)
> I used v3.8 good, v3.9 bad. I did it correctly? No version 3.8.11.
Yes. Please go head. Currently have no more clue.

As far the git bisect:

There is a point in the git bisect piece (3.8 to 3.9) that makes the build kernel un-bootable (really early kernel panic. .... Not syncing: attempted to kill init! ... exitcode=0x00000009). I have tried anything I could to debug the kernel panic without success. Every time this point is included to a bisect step I must make an assumption. Either the build kernel is git bisect good or bad. That doubles the steps every time it occurs. It almost impossible to try every combination. I don't know what to try next.

I had also posted my problem to the following bug report. 

https://bugzilla.kernel.org/show_bug.cgi?id=58801

You can use "git bisect skip" to avoid commits that break your system entirely.

Anyway, does 3.10-rc4 still have the problem?

I will give it a try with the 3.10-rc4.

3.10-rc4 is also bad.

When this happens the cpu frequency is always at max. Even If I change the governor to powersave.

I will give bisect another try.

I wonder what powertop says when this is happening?

Some screenshots of powertop while the problem present.

http://i.imgur.com/bwMriTI.png
http://i.imgur.com/z2ikZtx.png
http://i.imgur.com/IvVrlJ6.png
http://i.imgur.com/AkIqUS5.png
http://i.imgur.com/DOC3OVk.png

This problem is much more prominent on my i7-2620M Intel Sandybridge system. After waking up from suspend temperature soars to over 80C and power consumption reaches 30-40W.

Created attachment 103601 [details]
acpidump

Here are some more htop & powertop screenshots

http://imgur.com/VC7b9lz
http://imgur.com/zS45WNR
http://imgur.com/v91HLgl
http://imgur.com/274Ne5W
http://imgur.com/v108Saw

Hi,

same behaviour here, with the only difference that the platform is amd64 and the cpu is a i7-2670M .
Moreover I am quite sure that another bug report is opened here regarding the same issue but I can't find it.
Regards,

https://bugs.freedesktop.org/show_bug.cgi?id=54089
https://bugzilla.kernel.org/show_bug.cgi?id=48721

(In reply to comment #14)
> Here are some more htop & powertop screenshots
> 
> http://imgur.com/VC7b9lz
> http://imgur.com/zS45WNR
> http://imgur.com/v91HLgl
> http://imgur.com/274Ne5W
> http://imgur.com/v108Saw

What about "frequency stats"?

(In reply to comment #14)
> Here are some more htop & powertop screenshots
> 
> http://imgur.com/VC7b9lz

This shows that 80% of the time is spent in the turbo range, which isn't correct.  The idle states statistics look OK.

So, it appears to be a problem with frequency scaling.

(All of you) please tell me what's there in
/sys/devices/system/cpu/cpu*/cpufreq/scaling_driver

It would be awesome if someone able to reproduce this problem could carry out a binary search for the bad commit with

$ git bisect start -- drivers/cpufreq/

intel_pstate.

The main change between 3.8 and 3.9 I believe is Intel PSTATE. I thought the problem was Intel PSTATE.

As I mentioned before I tried:

Compiled a kernel 3.9.2 and 3.9.4 with CONFIG_X86_INTEL_PSTATE disabled

Used the intel_pstate=disable option.

I will try the suggested git bisect.

(In reply to comment #20)
> intel_pstate.
> 
> The main change between 3.8 and 3.9 I believe is Intel PSTATE. I thought the
> problem was Intel PSTATE.
> 
> As I mentioned before I tried:
> 
> Compiled a kernel 3.9.2 and 3.9.4 with CONFIG_X86_INTEL_PSTATE disabled
> 
> Used the intel_pstate=disable option.

In which case it should use acpi-cpufreq instead.  Does it?  If so, does it have the same problem?

(In reply to comment #21)
> I will try the suggested git bisect.

If you only see the problem with intel_pstate, it would be good to verify if it's always been there with intel_pstate or only from a certain point.  You can further restrict your search to drivers/cpufreq/intel_pstate.c for that.

Yes, when I disable Intel PSTATE the scaling driver reverts to acpi-cpufreq. But the problem is still present.

I can reproduce this bug in 3.7 long before intel_pstate drivers were released. So, intel_pstate could just have come at coincidental time. Also I am not affected by this after every suspend to resume but occasionally.

Idle frequency has gone from 800Hz to you can see in turbo range when I have made no changes to BIOS or efforts to enable turbo. It should go beyond 2.7GHz which is max range for my system in non-turbo setup. My reading tells me frequency is suppose to be high in intel_pstate drivers.

$ls /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver  /sys/devices/system/cpu/cpu2/cpufreq/scaling_driver
/sys/devices/system/cpu/cpu1/cpufreq/scaling_driver  /sys/devices/system/cpu/cpu3/cpufreq/scaling_driver
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
intel_pstate
$ cat /sys/devices/system/cpu/cpu2/cpufreq/scaling_driver
intel_pstate
$ cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_driver
intel_pstate
$ cat /sys/devices/system/cpu/cpu3/cpufreq/scaling_driver
intel_pstate

I don't know anything about git bisect but let me do some readings and I will try to do or ask any questions I have.

Thanks.

(In reply to comment #3)
> I used v3.8 good, v3.9 bad. I did it correctly? No version 3.8.11.

Can you try -rcs of 3.9 ? Maybe we can narrow down the problem a bit.

(In reply to comment #24)
> Yes, when I disable Intel PSTATE the scaling driver reverts to acpi-cpufreq.
> But the problem is still present.

In that configuration (i.e. PSTATE disabled, acpi-cpufreq in use), does this commit make any difference:

http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=pm-fixes&id=8673b83bf2f013379453b4779047bf3c6ae387e4

Anyway, I don't think this qualifies as a regression, at least not as a recent one.

Reverting 

http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=pm-fixes&id=8673b83bf2f013379453b4779047bf3c6ae387e4

and disabling intel_pstate doesn't solve the issue.

Powertop output with the issue present, Intel Pstate disabled and the above patch changed.

http://i.imgur.com/9OJiV8I.png
http://i.imgur.com/NMcSJdi.png
http://i.imgur.com/zgkzTys.png
http://i.imgur.com/fZS1aqV.png
http://i.imgur.com/VvfC6cB.png

Well, I'm not sure what you did, because the commit I asked about in comment #27 has not been merged yet, so it cannot be reverted. :-)

Or did you test linux-next with that commit reverted?

I downloaded linux-3.9.tar.xz, applied the patch patch-3.9.4.xz. After that I opened the file drivers/cpufreq/acpi-cpufreq.c

I located the lines 

cmd.addr.msr.reg = MSR_IA32_PERF_CTL; (line 350)

and 

cmd.addr.msr.reg = MSR_AMD_PERF_CTL; (line 354)

And changed it to cmd.addr.msr.reg = MSR_IA32_PERF_STATUS; and cmd.addr.msr.reg = MSR_AMD_PERF_STATUS;.

Ok, I did it wrong. Just  realize I was working in wrong place. I have to sleep tbh.

This time I think I did it correctly.

I applied the patch to kernel 3.9.4 and disabled Intel pstate. No change. The issue is still present.

Do you want me to test it with 3.10-rc4?

No, thanks.

I think it's better to focus on intel_pstate from now on.  I'll get back to you later today.

I promised to get back to you, but I didn't manage to do that on Friday.  Sorry about that.

intel_pstate has a couple of tunables under /sys/devices/system/cpu/intel_pstate one of which is 'no_turbo'.

When you reproduce the bug after a system resume, does writing 1 and then 0 to that file make any difference?

Also, if you write 1 to /sys/devices/system/cpu/intel_pstate/no_turbo before suspend, is the problem reproducible after writing 0 to it right after the subsequent resume?

In other words, are you able to see the problem after a sequence like this:

# echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
# echo mem > /sys/power/state
# echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo

It may be i915 related after all. I need to make test. I will reply soon.

Even so, can you please do the comment #36 check anyway?

ok.

No, using

# echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
# echo mem > /sys/power/state
# echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo

When the problem is present doesn't change anything.

So I am a little confused here is intel_pstate implicated here or not most of the thread explicitly took intel_pstate off the table.

Anyway maybe the output from turbostat when the system is in the bad state would help shed some light on what is going on.

Ok, I managed to complete a git bisect. The result was:

First bad commit: [15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9] drm/i915: enable irqs earlier when resuming.

http://o.cs.uvic.ca:20810/perl/cid.pl?cid=15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9

I removed the above patch from kernel 3.9.4, 3.9.5 and it seems to work ok after suspend and resume. With Intel PSTATE enabled.

The temperature is back to normal and the cpu frequency doesn't "lock" to the 
highest value.



Just a side note. Don't know if related at all:

I have noticed that when using Intel PSTATE. If the system starts with frequency
scaling to powersave the frequency is around to 800~900 MHz. If I change it to 
performance it will go up. After changing it back to powersave the frequency will
stay to ~2000 MHz. If I suspend and resume it will be around to 800~900 MHz again.
This doesn't seem to effect the temperature of the system'

(In reply to comment #41)
> So I am a little confused here is intel_pstate implicated here or not most of
> the thread explicitly took intel_pstate off the table.

intel_pstate does not cause that problem to happen, but it's just much easier to work with intel_pstate than with acpi-cpufreq.

Since we have a bisection result now (thanks Alexander!), I'm reassigning this bug to the i915 people.

I don't have to open a new request. Right?

Thanks you for your time.

(In reply to comment #44)
> I don't have to open a new request. Right?

Right, it's better to keep all of the relevant info in one place.

Problem seems to have aggravated for me. Since 3.9.6, I am booting directly into a system which is running at full frequency 3.4GHz, consuming 35W and a system temperature of 95-97C. This is has happened more than a few times since I installed 3.9.6 last night.

http://imgur.com/vYyJ0fj
http://imgur.com/1pEwtSg
http://imgur.com/i0PMRSD
http://imgur.com/Fa9LtX4
http://imgur.com/6ALw4El

related?
https://bugzilla.kernel.org/show_bug.cgi?id=48791

if you use ondemand governor, what's about runnign this after s2ram :
for g in performance ondemand; do for i in 3; do echo $g > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor; done; done

?

I have this problem too (I reported it as https://bugzilla.kernel.org/show_bug.cgi?id=57871). I have just found this thread. I removed the commit 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 (what Alexander have found), and it became much better but the problem still not solved. Originally 1 times out of 3 my CPUs become locked to max freq, and now I tested 20-25 times and the problem showed up only once. But this also makes the testing much harder.

Since I removed the commit I can no more replicate the problem. Everything is fine. Tested on kernel versions 3.9.4, 3.9.5, 3.9.6.

On Sunday, June 23, 2013 10:20:36 AM you wrote:

> --- Comment #50 from Alexander Kaltsas <alexkaltsas@gmail.com>  2013-06-23
> 10:20:35 ---
> Since I removed the commit I can no more replicate the problem. Everything is
> fine. Tested on kernel versions 3.9.4, 3.9.5, 3.9.6.

Can you both please attach the output of /proc/cpuinfo from your systems
(or provide pointers to that information)?

Created attachment 105811 [details]
My /proc/cpuinfo

Now I continued trying to lock the frequency. After 35 tries (!!!) it was working perfectly. After that I removed the charger to run
from battery. After 3 tries, the cpus were locked at 3.3GHz. I continued and after another 3 tries it happened again. After the 2nd
try after this the system was not coming back from suspend (the display remained off). After reboot, running from battery, on the 4th
try the CPU's are at 3.3GHz again.

Before removing the comit there was no difference bethween charger attached or not.

Also, as on the other thread I have said, I disabled turbo mode by writing 38th bit of msr 0x1a0 to 1. Still when the problem happens my 2.7 GHz CPUs are running at 3.3-3.4GHz

My cpu infos are already attached to the bug.

@ Robert Csordas. I could always replicate the issue by changing the frequency governor to performance (sudo cpupower frequency-set -g performance) and suspending.

For me cpupower frequency-set -g performance make no noticable difference (i915 early IRQ removed, kernel 3.9.5).

It seems that the problem is related to some uggly race condition. Because the "later enabling of IRQ" made the problem much less frequent, I tought it may be that something in resuming of i915 still happening "to early". I put a couple of msleep(100)'s in the __i915_drm_thaw function, where I tought it may be good. After that my machine resumed itself 30 out of 30 without any problems running from battery. Later I "hand binary searched" the right sleep that solves the problem. So my machine is now working with one msleep(100); before the line intel_modeset_init_hw(dev); (the early IRQ commit already removed). With this one sleep added the machine resumed 20 out of 20 tries without problem (running from battery).

Interestingly putting the sleep early in the function doesn't helps (this may indicate that the race condition is in i915 itself and not bethween i915 and some other module???).

So the uggly solution which works for me:

1. remove commit 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9
2. locate function __i915_drm_thaw in i915_drv.c
3. find line intel_modeset_init_hw(dev); and put msleep(100); one line before it.

Thanks a lot for that detective work and the information!

I have Dell Vostro 3350 with similar issue. The temperature may rise up after resuming from suspend. The fix for my problem was to suspend repeatedly until temperature is stable. This problem can be reliably reproduced on my system.

@Robert Csordas: thanks for the msleep hint! I've been running into this issue bigtime with the 3.10-rc series kernel, where roughly four out of every five suspend/resumes cycles will trigger the high CPU frequency/power usage. As per your step 2, I applied an msleep(100) just before intel_modeset_init_hw(dev) in __i915_drm_thaw, and early results look promising: with this new kernel I was able to perform 9 suspend/resumes in a row without hitting this bug. (The tenth resume completely failed - the screen backlight didn't even turn on and the system was completely unresponsive, but I'm going to assume for now that this is a different bug.)

Note that I didn't revert commit 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9, I just inserted the msleep call.

Created attachment 105901 [details]
Patch with msleep(100)

I created a patch (with reverted early irq and sleep(100)) for those who want to experiment. It may be a temporary solution unitl the bug will be fixed (of course if it works for other people too). I'm using it since yesterday and seems to work fine.

On Monday, June 24, 2013 02:34:35 PM you wrote:
> --- Comment #58 from Way-Chuang Ang <wcang79@gmail.com>  2013-06-24 14:34:34
> ---
> I have Dell Vostro 3350 with similar issue. The temperature may rise up after
> resuming from suspend. The fix for my problem was to suspend repeatedly until
> temperature is stable. This problem can be reliably reproduced on my system.

Can you please attach the contents of /proc/cpuinfo from your system?

(In reply to comment #60)
> Created an attachment (id=105901) [details]
> Patch with msleep(100)
> 
> I created a patch (with reverted early irq and sleep(100)) for those who want
> to experiment. It may be a temporary solution unitl the bug will be fixed (of
> course if it works for other people too). I'm using it since yesterday and
> seems to work fine.

If you change /sys/power/pm_async to 0, do you still need the msleep() patch?

Created attachment 105911 [details]
My /proc/cpuinfo

This system only has Intel IGP.

Hm, the mdelay() that seems to be helping is put just before a function where we enable RC6 and some other power setup.  The msleep() might help make sure some other resume activities are complete before we talk to the Punit for example, or enable RC6 (which would be entered immediately).

The question is, what other activity might interfere with the Punit communcation, or ring frequency changes that RC6 or ring freq scaling might cause?

I'm curious to hear the result from setting pm_async to 0...

Here are the results form pm_async:

With original kernel (3.9.5) it makes no difference.

With kernel with commit 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 removed, but no msleep, it seems to work fine (30 out of 30 resumes worked).

Created attachment 105951 [details]
Patch with msleep(100)

I'm sorry about it but my last patch was not working since my original file was in my root folder.

I use 3.9.7 (as shipped with Arch linux) on a thinkpad x220, i5-2520M CPU, and setting pm_async to 0 has fixed the issue for me so far.

I will install the stock kernel and give pm_async a try.

Setting pm_async to 0 has no effect for me. I set it to zero, suspended and when resumed the frequency locked at max and the temperature went up.

Can you try the drm-intel-nightly branch from git://people.freedesktop.org/~danvet/drm-intel with the attached min_freq patch applied?

Created attachment 106011 [details]
set min GPU frequency when idle

(In reply to comment #65)
> Here are the results form pm_async:
> 
> With original kernel (3.9.5) it makes no difference.
> 
> With kernel with commit 15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 removed, but
> no msleep, it seems to work fine (30 out of 30 resumes worked).

OK, thanks.

Please boot with initcall_debug in the kernel command line, set pm_async back to 1 and try to reproduce the issue (by suspending and resuming).  Once you've reproduced it, please attach the part of dmesg corresponding to the last ("failing") suspend-resume cycle.

I have the same system as Apostolis (x220, 3.9.7), and pm_async=0 seems to fix it for me as well. I would experience the max cpu / high fan about 1 out of 4 resumes, with pm_async disabled I haven't had a problem.

(In reply to comment #73)
> I have the same system as Apostolis (x220, 3.9.7), and pm_async=0 seems to
> fix
> it for me as well. I would experience the max cpu / high fan about 1 out of 4
> resumes, with pm_async disabled I haven't had a problem.

I have the same machine too (x220), but with i7 CPU, kernel 3.9.5, and pm_async doesn't helps. You may try testing from battery: for me from battery the problem is happening much more often.

Created attachment 106061 [details]
dmesg of falied resume with intitcall_debug

Here is my dmesg of a failed wakeup.

I have not mentoined yet but I have quite many i915 power management tweaks in my kernel command line: i915.i915_enable_rc6=7 i915.lvds_downclock=1 i915.i915_enable_fbc=1 i915.semaphores=1 i915.modeset=1 drm.vblankoffdelay=1

pm_async=0 doesn't help for my case either. The temperature still increases after a few times of suspends and resumes.

Hi Jesse Barnes. I want to try out the min_freq patch, do you have a patch for 3.10-rc7? 
Thanks.

No, I don't have anything against 3.10-rc7, that would be a bigger backport.  Can you try to repro on the kernel I pointed at instead?

I'm sorry if I missed out something, but I cannot find any reference to the kernel version that your patch should apply to.

I believe you should do something like:

git clone -b drm-intel-nightly --depth 1 git://people.freedesktop.org/~danvet/drm-intel

and then apply the patch with:

patch -Np1 -i "i915-min-freq.patch"

(In reply to Jesse Barnes from comment #70)
> Can you try the drm-intel-nightly branch from
> git://people.freedesktop.org/~danvet/drm-intel with the attached min_freq
> patch applied?

Has anyone tried this now?

I have the same problem on 3.9 and 3.10 kernels, whereby idle temperature is approx 10 degrees hight after a resume suspend which resulst in a constant running of the fan at higher speed than is normal on idle.

As others have reported, repeated suspend/resume cycles can often return the system to normal after a few attempts.

*** Bug 57871 has been marked as a duplicate of this bug. ***

Another patch to try, see comment #72 in https://bugs.freedesktop.org/show_bug.cgi?id=54089.

It seems to be ok with the above patch. v3.9.9. I will to do furter testing.

Created attachment 106891 [details]
intel_pm.c patch against linux 3.10.1

So far the changes in that patch are working well in linux 3.10.1 as well (I've done five suspend/resume cycles without any issues).

I had to modify it slightly for 3.10 though, so I've attached what I'm trying in case anyone else wants to try it out.

Also so far so good with that latest patch on 3.10.1 after 10+ s2ram/resume cycles. Will keep running for a while to make sure.

commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date:   Wed Jul 17 10:22:58 2013 +0400

    drm/i915: fix long-standing SNB regression in power consumption after resume

Link/patch? 

Had anything to do with my git bisect findings?

drm/i915: enable irqs earlier when resuming.

I suppose this is the patch he is referring to: https://lkml.org/lkml/2013/7/17/48

(In reply to Alexander Kaltsas from comment #89)
> Link/patch? 
> 
> Had anything to do with my git bisect findings?
> 
> drm/i915: enable irqs earlier when resuming.

If the fix in that patch is correct it's extremely timing dependent and small juggling of stuff around could uncover the underlying bug easily. Testing will tell.

(In reply to Philip Munksgaard from comment #90)
> I suppose this is the patch he is referring to:
> https://lkml.org/lkml/2013/7/17/48

Yes.

What kernel version will include the patch?

I tried manually "insert" to 3.9.9 but I believe there is many other changes.

(In reply to Alexander Kaltsas from comment #92)
> What kernel version will include the patch?


It's in the 3.11 tree I think? And therefore I would expect it's heading for the stable queue for 3.9.x/3.10.x point releases soon?

*** Bug 59571 has been marked as a duplicate of this bug. ***

Just an info.

I have applied the patch to kernel 3.10.2 and I noticed image degradation after resume.

http://i.imgur.com/WgRpBLr.png

After some mouse movement the display is ok (with minor artifacts that eventualy goes away).

And some dmesg errors:

[ 7073.391125] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung

[ 7073.391130] [drm] capturing error event; look for more information in /sys/kernel/debug/dri/0/i915_error_state

[ 7073.402402] [drm:kick_ring] *ERROR* Kicking stuck semaphore on render ring
[13137.145779] [drm] Wrong MCH_SSKPD value: 0x16040307
[13137.145780] [drm] This can cause pipe underruns and display issues.
[13137.145780] [drm] Please upgrade your BIOS to fix this.
[13138.285473] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp on

I am attaching the i915_error_state file.

Created attachment 107051 [details]
i915 error state

i915 error state

(In reply to Alexander Kaltsas from comment #95)
> Just an info.
> 
> I have applied the patch to kernel 3.10.2 and I noticed image degradation
> after resume.
> 
> http://i.imgur.com/WgRpBLr.png

This is bug #60530

> After some mouse movement the display is ok (with minor artifacts that
> eventualy goes away).
> 
> And some dmesg errors:
> 
> [ 7073.391125] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed...
> GPU hung
> 
> [ 7073.391130] [drm] capturing error event; look for more information in
> /sys/kernel/debug/dri/0/i915_error_state
> 
> [ 7073.402402] [drm:kick_ring] *ERROR* Kicking stuck semaphore on render ring
> [13137.145779] [drm] Wrong MCH_SSKPD value: 0x16040307
> [13137.145780] [drm] This can cause pipe underruns and display issues.
> [13137.145780] [drm] Please upgrade your BIOS to fix this.
> [13138.285473] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp on
> 
> I am attaching the i915_error_state file.

And this is bug #53571

Thanks you.

*** Bug 48721 has been marked as a duplicate of this bug. ***

Quetion about the resolution for this bug.

I'm using a laptop with a HSW CPU and HD4500 integrated graphics on linux 3.12 and am seeing what seems to be a similar issue to this (seeing max frequency after resume.)

I'm pretty sure the fix is in linux 3.12.  I looked at the source and the change i915_dma.c is still there,but the intel_pm.c change doesn't seem to be anymore, though it's hard to tell since I can't even find the function...

What should I do to see if this is the same bug or a new bug?