Bug 21719

Created attachment 25824 [details]
dmesg

Created attachment 25825 [details]
register dump

Created attachment 25826 [details]
X.org log

Created attachment 25827 [details]
GPU dump

I can still ssh into the box after resuming (obviously, I got the logs). However, unlike with freeze bugs, all my processes were killed. Just X.org itself (and gdm) were still running.

The internal LVDS was off as well, so I couldn't really see more what was going on.

I see a similar issue, with
 Linux 2.6.30-6
 -intel 2.7.1

I usually use dual monitors:

Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 8192 x 8192
VGA1 connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   75.0
   1152x864       75.0
   1024x768       75.1     70.1     60.0
   832x624        74.6
   800x600        72.2     75.0     60.3
   640x480        72.8     75.0     66.7     60.0
   720x400        70.1
   640x350        70.1
LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800       59.9*+

If I hibernate and restart, it gets to the point of telling me it's restoring from the swap partition and then I see nothing further.  If I add:
  xrandr --output VGA1 --off

to my /etc/pm/sleep.d/30xrandr script, the resume works to the extent that everything is now usable, but as Martin reports, all my user processes are dead and I come back to a Kdm prompt.

Sounds like a possible dupe of #21708.  Does the resume work correctly if you VT switch to a text terminal first, then echo mem > /sys/power/state?

> Does the resume work correctly if you VT switch to a text terminal first, then echo mem > /sys/power/state?

No, same problem (maybe not entirely unsurprising with KMS).

However, I played around with this some more, right after login when gdm appears, but I'm not logged in yet. This is a bit different, and perhaps it's important for this bug, so let me elaborate:

Internal screen (LVDS): 1280x800
External screen (DVI): 1280x1024

VTs (with KMS) have always come up in 1280x1024 mode on DVI, and 1280x800 mode on LVDS; on DVI the VT just doesn't use the lower 224 pixels.

Until a few days ago, X.org autodetection (i. e. in gdm) came up as 1280x1024 (full resolution) on DVI. I guess/think, the LVDS was at 1280x800 and thus gdm got just "cut off" at the bottom. I don't care, though, the lid is closed and its docked (so ideally the LVDS wouldn't be active in the first place). In this setup, there was no way to reactivate DVI after suspend.

However, with the current drivers (xorg-edgers, thus pretty much "crack of the day"), X.org autodetection starts LVDS and DVI1 in 1024x768, and only my GNOME session's xrandr sets them back to 1280x1024 (DVI) and off (LVDS). Again, while the GNOME session is running, no way to recover DVI after suspend.

But if I don't log in and just let the gdm screen sit, switch to VT1, suspend, resume, and then open the lid (where the VT on the LVDS resumed correctly) and switch to gdm there, DVI gets back, apparently due to the modeswitch that happens. Once that's done, I can switch back to VTs and they work on the DVI as well, so the single mode switch helps to reenable DVI and get it fully working again.

Created attachment 27325 [details] [review]
restore the modeset for every activated crtc

Will you please try the attached patch on the latest linus git tree and see whether the issue still exists after resuming?
   Thanks.

I applied the patch in bug 20520 (which already made it to trunk) and this patch, to 2.6.31rc1, and confirm that suspend/resume is now perfect with both the internal LVDS and the external DVI. Many thanks!

(In reply to comment #9)
> I applied the patch in bug 20520 (which already made it to trunk) and this
> patch, to 2.6.31rc1, and confirm that suspend/resume is now perfect with both
> the internal LVDS and the external DVI. Many thanks!
> 
Thanks for the test. It seems that the box can work well if the two patches are applied.

How about the test result only if the patch from bug20520 is applied on the 2.6.31-rc1?
Thanks

> How about the test result only if the patch from bug20520 is applied on the
> 2.6.31-rc1?

Then resuming with internal LVDS works, but the external DVI stays blank (in the "powered off"/"standby" sense).

Comment on attachment 27325 [details] [review]
restore the modeset for every activated crtc

The patch is now in drm-intel-next.  Just to be sure, could you re-test with that branch, since some fixes went in on top of that patch?

> The patch is now in drm-intel-next.  Just to be sure, could you re-test with
> that branch, since some fixes went in on top of that patch?

Tested with drm-intel-next git head (5019914ca3), works perfect here. Thanks!

As it can work well on the latest drm-intel-next and the patch set is already shipped in the latest drm-intel-next tree, the bug will be marked as resolved.
Thanks.