| Summary: | [HSW desktop mobile bisected] ddi pll tracking botch-up due to vt-switchless resume | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | cancan,feng <cancan.feng> | ||||||||||||
| Component: | DRM/Intel | Assignee: | Jesse Barnes <jbarnes> | ||||||||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||
| Severity: | major | ||||||||||||||
| Priority: | medium | CC: | cancan.feng, huax.lu, jinxianx.guo, maxmusterm, przanoni, qingshuai.tian, seanvk, yangweix.shui | ||||||||||||
| Version: | unspecified | ||||||||||||||
| Hardware: | Other | ||||||||||||||
| OS: | All | ||||||||||||||
| Whiteboard: | |||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
cancan,feng
2013-05-09 05:52:17 UTC
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.