Hi,
I've just started to play with a new Acer Aspire S5 test box and noticed that garbage is displayed after resume from suspend to RAM with the 3.10 kernel (under KDE 4.10.3 on openSUSE 12.3). The display corruption goes away after killing X and restarting it.
The CPU is a Core i5-3317U (Ivy Bridge), i915 graphics.
That doesn't happen with 3.9 (same config otherwise). It also doesn't happen with my older Sandy Bridge-based box (with 3.10), so I suspect Ivy Bridge specifics.
Is this known? Do you want me to bisect?
Rafael
On Sat, Jul 6, 2013 at 3:59 PM, Rafael J. Wysocki rjw@sisk.pl wrote:
Hi,
I've just started to play with a new Acer Aspire S5 test box and noticed that garbage is displayed after resume from suspend to RAM with the 3.10 kernel (under KDE 4.10.3 on openSUSE 12.3). The display corruption goes away after killing X and restarting it.
The CPU is a Core i5-3317U (Ivy Bridge), i915 graphics.
That doesn't happen with 3.9 (same config otherwise). It also doesn't happen with my older Sandy Bridge-based box (with 3.10), so I suspect Ivy Bridge specifics.
Is this known? Do you want me to bisect?
Screenshot of the garbage would be a good start I'd say. Also, does a vt-switch not resolve the issue? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Saturday, July 06, 2013 04:16:36 PM Daniel Vetter wrote:
On Sat, Jul 6, 2013 at 3:59 PM, Rafael J. Wysocki rjw@sisk.pl wrote:
Hi,
I've just started to play with a new Acer Aspire S5 test box and noticed that garbage is displayed after resume from suspend to RAM with the 3.10 kernel (under KDE 4.10.3 on openSUSE 12.3). The display corruption goes away after killing X and restarting it.
The CPU is a Core i5-3317U (Ivy Bridge), i915 graphics.
That doesn't happen with 3.9 (same config otherwise). It also doesn't happen with my older Sandy Bridge-based box (with 3.10), so I suspect Ivy Bridge specifics.
Is this known? Do you want me to bisect?
Screenshot of the garbage would be a good start I'd say.
Well, it's just garbage. Attached anyway.
When the "screen lock" password prompt screen starts it's completely garbled. When I blind-type in the password, the desktop shows up and it looks kind of OK until a new window is opened and then it looks like rectangular area full of horizontal lines.
Also, does a vt-switch not resolve the issue?
No, switching VTs back and forth doesn't help when this happens (it makes things worse actually).
It's not 100% reproducible (but close to that on the IVB machine) and I've seen it once on my other machine based on Sandy Bridge too.
Thanks, Rafael
On Saturday, July 06, 2013 10:26:28 PM Rafael J. Wysocki wrote:
On Saturday, July 06, 2013 04:16:36 PM Daniel Vetter wrote:
On Sat, Jul 6, 2013 at 3:59 PM, Rafael J. Wysocki rjw@sisk.pl wrote:
Hi,
I've just started to play with a new Acer Aspire S5 test box and noticed that garbage is displayed after resume from suspend to RAM with the 3.10 kernel (under KDE 4.10.3 on openSUSE 12.3). The display corruption goes away after killing X and restarting it.
The CPU is a Core i5-3317U (Ivy Bridge), i915 graphics.
That doesn't happen with 3.9 (same config otherwise). It also doesn't happen with my older Sandy Bridge-based box (with 3.10), so I suspect Ivy Bridge specifics.
Is this known? Do you want me to bisect?
Screenshot of the garbage would be a good start I'd say.
Well, it's just garbage. Attached anyway.
To be precise, the screen right after resume doesn't look like this (as I said in https://bugzilla.kernel.org/show_bug.cgi?id=60530 created to track this issue - more screens attached in there).
Thanks, Rafael
On Saturday, July 06, 2013 03:59:49 PM Rafael J. Wysocki wrote:
Hi,
I've just started to play with a new Acer Aspire S5 test box and noticed that garbage is displayed after resume from suspend to RAM with the 3.10 kernel (under KDE 4.10.3 on openSUSE 12.3). The display corruption goes away after killing X and restarting it.
The CPU is a Core i5-3317U (Ivy Bridge), i915 graphics.
That doesn't happen with 3.9 (same config otherwise). It also doesn't happen with my older Sandy Bridge-based box (with 3.10), so I suspect Ivy Bridge specifics.
Is this known? Do you want me to bisect?
Most likely, this has been introduced by this commit:
commit 19b2dbde5732170a03bd82cc8bd442cf88d856f7 Author: Chris Wilson chris@chris-wilson.co.uk Date: Wed Jun 12 10:15:12 2013 +0100
drm/i915: Restore fences after resume and GPU resets
At least I'm not able to reproduce it with that commit reverted. With that commit in I was able to reproduce it quite readily on machines with Ivy Bridge and Sandy Bridge processors.
Thanks, Rafael
dri-devel@lists.freedesktop.org