Bug 57160

Created attachment 70129 [details]
correct background image

$ xrandr 
Screen 0: minimum 320 x 200, current 2960 x 1050, maximum 32767 x 32767
LVDS1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1680x1050      60.0*+   50.0  
   1400x1050      60.0  
   1280x1024      60.0  
   1280x960       60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 connected 1280x1024+1680+0 (normal left inverted right x axis y axis) 338mm x 270mm
   1280x1024      60.0*+   75.0  
   1280x960       60.0  
   1280x800       74.9     59.8  
   1152x864       75.0  
   1280x768       74.9     59.9  
   1024x768       75.1     70.1     60.0  
   1024x576       60.0  
   800x600        72.2     75.0     60.3     56.2  
   848x480        60.0  
   640x480        72.8     75.0     60.0  
   720x400        70.1  


To get correct background picture - only refresh event is usually required - i.e. to move some window over the background

(In reply to comment #0)
> When I suspend an undocked T61 with just LCD screen 
> and I make resume in docking station with attached 2nd
> display over standard VGA docking port - I get
> damaged background image.

Just so that I am clear on how to reproduce:

suspend; plug VGA in; resume

Where do you see the damage? On the LVDS, on the VGA or both?

(In reply to comment #2)
> (In reply to comment #0)
> > When I suspend an undocked T61 with just LCD screen 
> > and I make resume in docking station with attached 2nd
> > display over standard VGA docking port - I get
> > damaged background image.
> 
> Just so that I am clear on how to reproduce:
> 
> suspend; plug VGA in; resume
> 
> Where do you see the damage? On the LVDS, on the VGA or both?

I start gnome Xsession in  undocked configuration 
(Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 32767 x 32767)

then suspend
dock laptop (docking has attached VGA monitor)
and resume laptop

both screens are showing damaged background picture
(haven't tried to reproduce without docking station actually)

One thing to also check for is a GPU hang. Can you have a quick look in dmesg/Xorg.log for the warning?

Just tried to reproduce this on my i965gm... It seems that the HWS page was not restored... Instant death upon resume.

(In reply to comment #4)
> One thing to also check for is a GPU hang. Can you have a quick look in
> dmesg/Xorg.log for the warning?
> 
> Just tried to reproduce this on my i965gm... It seems that the HWS page was
> not restored... Instant death upon resume.

Speaking of hangs - yes I'm noticing recently significant problems with suspend resume - but usually the scenario:

suspend undock home/resume dock work/suspend dock work/resume undock home works.
(with 1 per week failure - see my recent lkml post:
https://lkml.org/lkml/2012/11/15/369
unsure wheather it's related or not)

However  if I try multiple  suspend/resume in dock - it doesn't take long
to experience black-screen death.

Unfortunately also my 'serial line' debugging now fails since after resume I get just garbage on my serial line.  But currently I do not have much free time to play with all this.

So my 'resume' deadlock has been fully resolved here:

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

so the problem with broken 'background' is left ;)

I should probably also aim for fixing the serial line problem.

Haven't had this happen to me yet. Is it still a regular occurrence for you?

Ye still happens to me all the time with current gnome2 environment I'm using on my rawhide.

To clarify: Is this with suspend-to-mem or hibernate-to-disk?

(In reply to comment #9)
> To clarify: Is this with suspend-to-mem or hibernate-to-disk?

Suspend to ram - I'm not using hibernation

Hmm, I've seen that pattern when I kill nautilus. Coincidence? Unlikely.

And it's gone...

Now that I try to actually reproduce that pattern with nautilus it just works. So perhaps it is related to the recent bug fixes - except that your report is older than that chunk of code. I think my nautilus reproducer was pure coincidence.

Hi,

I have a similar issue, without the suspend/resume cycle on gen4.

For me it is sufficient to attach an external screen with display port and

xrandr --output DP1 --auto --primary --output LVDS1 --off

This is 100% reproducible.

curiously enough if I do

xrandr --output DP1 --primary --auto --output LVDS1 --auto --right-of DP1

and then

xrandr --output DP1 --auto --primary --output LVDS1 --off

things are fine.

Please see the attachment for an illustration of the issue.

Created attachment 75673 [details]
Corrupted display

This is my rendering issue. It does not only involve the 'background' but every element on the screen. When in this state, even new windows do not show up correctly.

commit 4878cae22a2405b6d33318e2dc99a9c1367fee44
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Feb 18 19:08:48 2013 +0200

    drm/i915: Really wait for pending flips when panning

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

(In reply to comment #15)
> commit 4878cae22a2405b6d33318e2dc99a9c1367fee44
> Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Date:   Mon Feb 18 19:08:48 2013 +0200
> 
>     drm/i915: Really wait for pending flips when panning

Is this supposed to be fixed in 3.9.0-0.rc5 ? What I reported in bug 62724 just happened on this kernel too.

The mentioned patch is in linux-next and targeting 3.10.