I recently enabled KMS and UXA on my Dell Latitude D430 (x86_64 Ubuntu Karmic install). If I am only using the internal screen, suspend works well (and blazingly fast, I might add, wow!). However, I usually have the machine docked on an external 19" 1280x1024 TFT through DVI: $ xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2048 x 2048 VGA1 disconnected (normal left inverted right x axis y axis) LVDS1 connected (normal left inverted right x axis y axis) 1280x800 59.8 + DVI1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 340mm x 270mm 1280x1024 75.0*+ 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 TV1 disconnected (normal left inverted right x axis y axis) If I resume from that, the monitor stays blank with a "frequency not supported" message, i. e. as if nothing was connected to it. Linux 2.6.30rc5 -intel 2.7.0 libdrm 2.4.9 $ cat /etc/X11/xorg.conf Section "Device" Identifier "Configured Video Device" Option "FramebufferCompression" "off" Option "AccelMethod" "UXA" EndSection (FramebufferCompression is a workaround for bug 19304) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
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.
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.