Created attachment 79040 [details] dmesg of calltrace caused by S3 System Environment: -------------------------------------------- The Linux Kernel, the operating system core itself Kernel: (drm-intel-next-queued)38f6e314f7e0eee4cd5e4495ae58ff3b5645ce62 Some additional commit info: Author: Damien Lespiau <damien.lespiau@intel.com> Date: Fri May 3 18:48:11 2013 +0100 drm/i915: Add references to some workaround we implement Bug detailed description: -------------------------------------------- Call trace will happen after resume from S3. The machine can suspend to S3 successfully, but resume from S3 with call trace. I attached the dmesg in the attachment. Bisect result: -------------------------------------------- 24576d23976746cb52e7700c4cadbf4bc1bc3472 is the first bad commit commit 24576d23976746cb52e7700c4cadbf4bc1bc3472 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Mar 26 09:25:45 2013 -0700 drm/i915: enable VT switchless resume v3 With the other bits in place, we can do this safely. v2: disable backlight on suspend to prevent premature enablement on resume v3: disable CRTCs on suspend to allow RTD3 (Kristen) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> :040000 040000 72fb279ebc4c48824015f43eac459d046dde3204 6797fd617ffd75b6e2a457aaabf5e90f9a4021c0 M drivers
Missing hw state readout for the ddi pll tracking afaict. Hooray!
You didn't boot with drm.debug=0xe, so we can't really know what's going on. Can you please try with drm.debug=0xe and reattach the dmesg? Which outputs are you using? Do you remove/attach outputs while suspending/resuming?
(In reply to comment #2) > You didn't boot with drm.debug=0xe, so we can't really know what's going on. > Can you please try with drm.debug=0xe and reattach the dmesg? > Yeah,this is my mistake.I try with drm.dubug=0xe on latest drm-intel-next-queued kernel and attach the dmesg again. > Which outputs are you using? Do you remove/attach outputs while > suspending/resuming? I just got the dmesg info by "dmesg" in terminal, don't remove/attach any other outputs. It's the original what the system outputs.
Created attachment 80374 [details] S3 calltrace with debug
Right, this is quite nasty. The bug is a deeper issue that only really came to light with Jesse's patch. What is happening is that our hardware state trackers (like pll) suddenly no longer the registers upon takeover and we get extremely confused. This should be fixed up by Daniel and his extreme pipe_config recovery on takeover (or sanitized).
Yeah, my pll state recovery should help here, unfortunately I don't yet have support for haswell written. And like Chris' said the current pile is pretty extreme (and big) so will take a while just to get the rework for ilk/snb/ivb in.
*** Bug 65533 has been marked as a duplicate of this bug. ***
*** Bug 66296 has been marked as a duplicate of this bug. ***
*** Bug 67515 has been marked as a duplicate of this bug. ***
Any news?
(In reply to comment #10) > Any news? Always exist.. I reproduced it with a latest -next-queued kernel on hsw desktop and attached it's dmesg. Btw, you can see two call trace in the dmesg, the first one is coming with system boots up, I think it's just like bug#67462, but need to confirm further. The second one is caused by S3. :)
Created attachment 83953 [details] system booting up and S3 dmesg
Sorry, that was aimed at Daniel/Jesse as to whether they've made progress on extending the pll fixes to handle hsw.
Is there any fix right now that could be tested?
Created attachment 91615 [details] [review] Fix candidate Hi I believe this fixes the bug. At least for me :) Can you please test? Thanks, Paulo
Created attachment 91638 [details] dmesg of s3 with patched kernel and plugged with VGA I patched the attachment in Comment 15 on Daniel's tree drm-intel-next-queued branch(bd6025). And tested it on a HSW desktop. When plugged with VGA, the desktop can suspend and resume from S3 successfully. And there's no any Call trace again. S3 also works well without any Call trace when I changed VGA to HDMI. :) You can check the dmesg in the attachment.
commit 0882dae983707455e97479e5e904e37673517ebc Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Wed Jan 8 11:12:27 2014 -0200 drm/i915: fix DDI PLLs HW state readout code has landed in -fixes.
Closing old verified.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.