Created attachment 78994 [details]
Xorg log of the session

[   15.165920] evbug: Event. Dev: input3, Type: 4, Code: 4, Value: 19

Lines like this are not present in 3.8.x kernels. This is probably another, unrelated regression. 

A correction on behavior on bad resume: Sometimes it resumes with backlight on, text with resume log can be briefly seen, and then on key press the display truns off. I can still VT switch and restart X.

A few questions for clarification:
- Is this a regression?
- When you vt-switch to the console, does that always work? Does restarting X fix then also fix X?
- Are you using sna or the uxa xf86-video-intel backend? Can you please test what happens when using the other one?

Note that recompiling the DDX with --enable-debug=full will also give a lot more information and indicate whether the userspace sanity checks are happy with the crtc state post resume.

0. i upgraded my kernel to 3.9.3. the problem still persists
1. yes, this is a regression. however, downgrading DDX or kernel
doesn't seem to fix it, and I've tried going way back to
xf86-video-intel-2.16.902 and kernel 3.2.x so maybe it's a bug in
Xserver or something else
2. yes, VT switching always works, and restarting X always makes X usable again
3. i've tried with uxa, same results

4. I've tried compiling DDX with --enable-debug=full, but it failed like this
sna_accel.c:13801:12: warning: cast discards '__attribute__((const))'
qualifier from pointer target type [-Wcast-qual]
make[4]: *** [sna_accel.lo] Error 1

There were some gcc warnings above those lines, but no errors. the
same source compiles without errors without --enable-debug=full. I'm
using gcc 4.7.3 from Debian, and tried with gcc-4.8, with same
results.


On Tue, May 21, 2013 at 1:10 AM,  <bugzilla-daemon@freedesktop.org> wrote:
> Comment # 4 on bug 64329 from Chris Wilson
>
> Note that recompiling the DDX with --enable-debug=full will also give a lot
> more information and indicate whether the userspace sanity checks are happy
> with the crtc state post resume.
>
> ________________________________
> You are receiving this mail because:
>
> You reported the bug.

Also if you attach the logs from across the non-lid suspend, I think we will find that it forces a VT switch...

Chris fixed debug=full build so I'll add the non-lid and lid suspend logs to the bug.

Created attachment 79677 [details]
drm.debug=6 dmesg with lid suspend and resume

Created attachment 79678 [details]
Xorg log with debug=full of lid suspend-resume session

Created attachment 79679 [details]
drm.debug=6 dmesg with non-lid suspend and resume

Created attachment 79680 [details]
Xorg log with debug=full of non-lid suspend-resume session

Looks like the CRTC state is consistent after all following the lid suspend. There is a VT switch involved, and X performs a modeset upon resume and the kernel reports everything is hunky dory.

Next clutching at straws: how about an intel_reg_dumper comparing working/broken resume?

Can you also please try the latest drm-intel-nightly kernel git branch from http://cgit.freedesktop.org/~danvet/drm-intel/ ?

We've fixed up the pfit/lvds enable sequence a bit recently, so this might help ...

Daniel, tested with e1aa11a0043f913f58722bef54e7a185761a2023 version from this location:
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/

Problem persists. 

Chris, this is the diff or intel_reg_dumper, full dumps attached to bug


--- lid-suspend-resume-dump	2013-05-23 14:52:41.279022930 +0200
+++ non-lid-suspend-resume-dump	2013-05-23 14:51:44.323227835 +0200
@@ -110,9 +110,9 @@
              PIPEB_GMCH_DATA_N: 0x00000000
                PIPEB_DP_LINK_M: 0x00000000
                PIPEB_DP_LINK_N: 0x00000000
-                 CURSOR_B_BASE: 0x00000000
-              CURSOR_B_CONTROL: 0x00000000
-             CURSOR_B_POSITION: 0x00000000
+                 CURSOR_B_BASE: 0x35494000
+              CURSOR_B_CONTROL: 0x14000027
+             CURSOR_B_POSITION: 0x017d0213
                           FPB0: 0x00020f04 (n = 2, m1 = 15, m2 = 4)
                           FPB1: 0x00030f04 (n = 3, m1 = 15, m2 = 4)
                         DPLL_B: 0x98046100 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 3, p2 = 14, using FPx1!, SDVO mult 1)
@@ -210,8 +210,8 @@
                    AUD_GRP_CAP: 0x00000000
                       FENCE  0: 0x00400231 (enabled, X tiled, 4096 pitch, 0x00400000 - 0x00800000 (4096kb))
                       FENCE  1: 0x01500031 (enabled, X tiled, 4096 pitch, 0x01500000 - 0x01600000 (1024kb))
-                      FENCE  2: 0x04a00011 (enabled, X tiled, 1024 pitch, 0x04a00000 - 0x04b00000 (1024kb))
-                      FENCE  3: 0x04b00011 (enabled, X tiled, 1024 pitch, 0x04b00000 - 0x04c00000 (1024kb))
+                      FENCE  2: 0x00000000 (disabled)
+                      FENCE  3: 0x00000000 (disabled)
                       FENCE  4: 0x00000000 (disabled)
                       FENCE  5: 0x00000000 (disabled)
                       FENCE  6: 0x00000000 (disabled)

Created attachment 79705 [details]
lid suspend resume intel_reg_dumper output (working resume)

Created attachment 79706 [details]
lid suspend resume intel_reg_dumper output (broken resume)

Created attachment 79707 [details]
non lid suspend-resume intel_reg_dumper output (working resume)

Shot in the dark:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index d63bb3fa..f363be2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3632,7 +3632,7 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc)
 
        intel_enable_pipe(dev_priv, pipe, false);
        intel_enable_plane(dev_priv, plane, pipe);
-       if (IS_G4X(dev))
+       //if (IS_G4X(dev))
                g4x_fixup_plane(dev_priv, pipe);
 
        intel_crtc_load_lut(crtc);

This needs a kernel with

commit 61bc95c1fbbb6a08b55bbe161fdf1ea5493fc595
Author: Egbert Eich <eich@suse.com>
Date:   Mon Mar 4 09:24:38 2013 -0500

    DRM/i915: On G45 enable cursor plane briefly after enabling the display plane.

Well, this is embarrassing. 

The whole thing is an invalid bug. Somehow 'slock' become my default screen lock program and this is the whole issue. 

Sorry for wasting your time, at least DDX debug=full works here.