Kernel Bug Tracker – Bug 60598
skip_vt_switch = true in linux 3.10.1 for i915 causes defects in X display after resume from RAM
Last modified: 2013-07-22 22:05:44 UTC
I recently upgraded to linux-3.10.1 (mainline) on an Ultrabook - see http://www.linlap.com/asus_ux32vd for all the hardware details.
I welcome that this commit tries to avoid switching back to console and forth to X upon suspend/resume: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=24576d23976746cb52e7700c4cadbf4bc1bc3472 - drivers/gpu/drm/i915/intel_fb.c - this indeed saves yet another 0.5s resume time :-)
Alas, whenever I resume from RAM, the X display looks somewhat distorted - the image looks similar to what it was before the suspend, but there are damaged pixels (some of which look as if they change whenever something is output on the console), and while the X server keeps running, the display becomes more and more distorted. Switching to a console and back after the resume does not fix the symptoms.
But when I switch to the console manually before suspending, and manually from console to X after resume, then everything is fine (just as it was with linux-3.8.8 before).
(In case it's important: I use "bbswitch" to always shut off the nvidia GPU, never use it.)
Most likely a duplicate of bug #60530, I'd need a screenshot of the corruptions to tell or alternatively please apply the patch on that bug report to check whether that fixes your issue. Thanks.
Yes, this is a duplicate of bug #60530, sorry for not finding that one, my search terms seem to have been insufficient.
I applied patch http://cgit.freedesktop.org/~danvet/drm-intel/patch/?id=94a335dba34ff47cad3d6d0c29b452d43a1be3c8 and - voila! - the display is now fine after resuming from S3.
Thanks a lot for your efforts!
BTW: I guess a screenshot of my corruptions would not have helped much, they looked very different from the screenshots I found attached to bug #60530.
*** This bug has been marked as a duplicate of bug 60530 ***
No problem, bug reports (even if there's the occasional dup) are always welcome. And generally when in doubt we prefer duplicated reports that we can coalesce once we have evidence that it's the same bug than needing to untangle a mess of a bug report with bazillion different issues ;-)