Bug 44876

I think a starting point is to compile intel_reg_dumper from http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ (which may actually be available from your local distributor now!) and grab the registers before and after closing the lid.

HDMI cable:

1. xdm/xorg started -> reg_dump via ssh
2. connected HDMI -> rebooted (screen corruption) -> reg_dump via ssh

LID:
1. xdm/xorg started -> reg_dump via ssh
2. lid closed and re-opened (screen corruption) -> reg_dump via ssh
(diff shows no differences)

Vanilla Kernel 3.2.1 and 3.1.9
Gentoo
Dell E6420

Created attachment 55730 [details]
without hdmi cable

Created attachment 55731 [details]
with hdmi cable

Created attachment 55732 [details]
lid open

Created attachment 55733 [details]
lid closed and reopened

the screen corruption is gone, as soon as the kernel? idle timer blanks the screen for power saving (after 5 minutes idle time?). After a key press the screen is normal till the next closing of lid.

No change whatsoever when closing/opening the lid. Plugging the HDMI cable obviously brings up the second pipe, and switches the first pipe to a new resolution. 

But no clues there I am afraid. Next up is append drm.debug=0xe to your kernel boot parameters and attach the debug logs. Hopefully one of the other guys has an inspired guess...

drm.debug=0xe

LID:

1. dmesg right after boot
2. dmesg after lid close cycle (screen corruption after reopening the lid)

Created attachment 55755 [details]
right after boot xdm start screen everything fine

Created attachment 55756 [details]
dmesg after closing, 5 seconds wait, re-opening lid with corrupted screen afterwards

Hm, maybe we've got a nice dpms issue here. Can you try to run

$ xset dpms force off
$ xset dpms force on

when the screen corruptions happens from a console within X? Also just to check: the "lid closed and reopened" reg dump, is that while the screen corruptions are still there or afterwards?

1. LID 

dpms force off/on doesnt change anything.

xdm -> logged in -> konsole prepared with xset dpms force off -> lid close -> screen corruption -> blind pressed enter and entered blind the xset dpms force on command -> nothing happened, screen corruption still there.

when the screen corruptions happens from a console within X? Also just to
check: the "lid closed and reopened" reg dump, is that while the screen
corruptions are still there or afterwards?

the reg dump was created while the screen corruption still there.

2. HDMI cable

System off -> connected HDMI cable -> system boot -> during kernel startup same content on hdmi and lvds -> xdm start -> hdmi OK xdm login screen -> lvds screen corruption (the screen corruption looks the same for lid close and for hdmi)

created dmesg.

Created attachment 55790 [details]
drm.debug connected hdmi cable screen corruption on lvds as soon as xdm starts

Created attachment 55791 [details]
picture of HDMI cable attached screen corruption

Created attachment 55792 [details]
HDMI cable run, waited for idle blank -> dmesg

Created attachment 55793 [details]
HDMI run, dmesg after key press after idle blank --> screen is good

news:

the directory /sys/class/backlight/ contained two subdirs.
"intel_backlight and dell_backlight"
I disabled the dell_laptop option under x86 and now, there is some different behavior.
Still screen corruption but when i close and reopen the lid the screen is now black. And there are some light/shady characters from the boot process like [drm] initialized drm 1.1.0 etc.

wrong. The change is not from the kernel option. The change is from the kernel command line acpi=off.

3.0.17 is _not_ affected --> this is a regression

cp .config 3.1.10 to 3.0.17 ; make oldconfig 
everything works. LID and HDMI --> no screen corruptions

On Fri, Jan 20, 2012 at 02:20:18AM +0000, bugzilla-daemon@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=44876
> 
> --- Comment #20 from daniel <sec@dschroeder.info> 2012-01-19 18:20:18 PST ---
> 3.0.17 is _not_ affected --> this is a regression
> 
> cp .config 3.1.10 to 3.0.17 ; make oldconfig 
> everything works. LID and HDMI --> no screen corruptions

Hm, that's bad and I've got no idea - it might very well be something
going on in acpi, too. Can you please bisect this one with git? Knowing
the bad commit usually helps a _lot_.

Thanks, Daniel

LKML thread with the same problem. Adding as reference:

http://lkml.org/lkml/2011/9/14/299

Did 3.1 have FBC enabled? One of the first side-effects of FBC was LVDS corruption during hotplug.

All the errors occurred whilst using FBC. Can you please try i915.i915_enable_fbc=0 or a more recent kernel?

tested this: i915.i915_enable_fbc=0 with Kernel 3.3.6.
tested how: booted -> xdm login screen -> closed the lid -> waited 10 seconds -> reopened -> screen corruption.

I am pretty sure, that this only happens on this type/model of notebook (E6420). A collegue using stock Ubuntu with the same notebook has the same troubles. If it would be more widespread more people would complain. So, possible no faults/errors in the Intel driver and may be a specific firmware/bios problem of the vendor...

You've mentioned in comment #20 that this is a regression. Can you please try to bisect this? I guess otherwise we're pretty much stuck.

kernel 3.1-rc3 ==> bad
kernel 3.1-rc2 ==> good

git bisect log
git bisect start
# bad: [fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c] Linux 3.1-rc3
git bisect bad fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c
# good: [93ee7a9340d64f20295aacc3fb6a22b759323280] Linux 3.1-rc2
git bisect good 93ee7a9340d64f20295aacc3fb6a22b759323280
# bad: [fbad8991ef9d41d1fad587dff23fa6deff01af83] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
git bisect bad fbad8991ef9d41d1fad587dff23fa6deff01af83
# bad: [870d3be1249b1397395ed3164987397993a16d91] Merge branch 'docs-move' of git://git.kernel.org/pub/scm/linux/kernel/git/rdunlap/linux-docs
git bisect bad 870d3be1249b1397395ed3164987397993a16d91
# good: [cedf03bd9aa54d1d7a9065dddc9e76505f476b12] x86: fix mm/fault.c build
git bisect good cedf03bd9aa54d1d7a9065dddc9e76505f476b12
# good: [798c794df81e0a1af62c1d7e48b464f4096f3b9a] Docs: MSI-HOWTO: MSI -> MSIs
git bisect good 798c794df81e0a1af62c1d7e48b464f4096f3b9a
# bad: [c3613de92ebea302137d21d8938421c3f88d8741] drm/i915: Can't do accurate vblank timestamps with UMS
git bisect bad c3613de92ebea302137d21d8938421c3f88d8741
# bad: [4e6343898fe7eed6b3c0c3c809347bc88d5b4a1e] drm/i915: Remove unused 'reg' argument to dp_pipe_enabled
git bisect bad 4e6343898fe7eed6b3c0c3c809347bc88d5b4a1e
# good: [ed10fca9c351c83ab89a97f3515089e0d36bdccc] drm/i915: Leave LVDS registers unlocked
git bisect good ed10fca9c351c83ab89a97f3515089e0d36bdccc
# bad: [1519b9956eb4b4180fa3f47c73341463cdcfaa37] drm/i915: Fix PCH port pipe select in CPT disable paths
git bisect bad 1519b9956eb4b4180fa3f47c73341463cdcfaa37

Ok, so according to your bisect log this commit should be the culprit:

commit 13d83a672e9bbd52ae82c2f611dfd845a957e8b4
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Aug 3 12:59:20 2011 -0700

    drm/i915: split out PCH refclk update code

Can you also please test the latest 3.4 release? The pch refclock code changed quite a bit lately, so double-checking whether you still have the same problem would be good (and any patches to fix things would be on top of the latest code anyway).

tested it already with linux-3.4-rc6 ==> bad. Should I test it again with 3.4 final?

No, 3.4-rc6 should be good enough. Can you also please double-check the bisect result? I.e. whether 13d83a672e9bbd52 is really broken and the commit right before that really works (i.e. da64c6fc4aba6f02aa800db)? I'm asking because that commit only extracts a bit of code into a separate function, so it should have zero effect.

this was the final bisect screen:
cat bisect-final.txt 
git bisect bad | tee -a /root/bisect.log
1519b9956eb4b4180fa3f47c73341463cdcfaa37 is the first bad commit
commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37
Author: Keith Packard <keithp@keithp.com>
Date:   Sat Aug 6 10:35:34 2011 -0700

    drm/i915: Fix PCH port pipe select in CPT disable paths
    
    CPT pipe select is different from previous generations (using two bits
    instead of one). All of the paths from intel_disable_pch_ports were
    not making this distinction.
    
    Mode setting with pipe A turned off would then also force all outputs                                                                                                                                                         
    on pipe B to get turned off as the disable code would mistakenly                                                                                                                                                              
    decide that all of these outputs were on pipe A and turn them off.                                                                                                                                                            
                                                                                                                                                                                                                                  
    This is an extension of the CPT DP disable fix (why didn't I fix this then?)                                                                                                                                                  
                                                                                                                                                                                                                                  
    Signed-off-by: Keith Packard <keithp@keithp.com>                                                                                                                                                                              
    Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>                                                                                                                                                                          
                                                                                                                                                                                                                                  
:040000 040000 5fb94b34dcaeed70c5da97a371fc2c13a62ddc60 99272b6f031b75fc9f91d8c08abba0d70cc9a527 M      drivers

Oops, I've mixed things up, that makes quite a bit more sense.

Ok let's try to tackle these one at a time.  With current kernels, is the register dump still identical between the fresh boot and after a lid close & open?

If so, does this patch help?  Also try "intel_reg_write 0xc7204 0x3" as root before doing the close/open.


--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1885,8 +1885,8 @@ static void intel_disable_pch_ports(struct drm_i915_privat
 {
        u32 reg, val;
 
-       val = I915_READ(PCH_PP_CONTROL);
-       I915_WRITE(PCH_PP_CONTROL, val | PANEL_UNLOCK_REGS);
+//     val = I915_READ(PCH_PP_CONTROL);
+//     I915_WRITE(PCH_PP_CONTROL, val | PANEL_UNLOCK_REGS);
 
        disable_pch_dp(dev_priv, pipe, PCH_DP_B, TRANS_DP_PORT_SEL_B);
        disable_pch_dp(dev_priv, pipe, PCH_DP_C, TRANS_DP_PORT_SEL_C);

Please test this patch here:

http://cgit.freedesktop.org/~danvet/drm-intel/patch/?id=e9a851ed634628489ca4a392740694d0ded78cb9

Symptoms seem to match, and if it tests out ok I can forward it to -fixes for 3.6, cc: stable.

(In reply to comment #36)
> Please test this patch here:
> 
> http://cgit.freedesktop.org/~danvet/drm-intel/patch/?id=e9a851ed634628489ca4a392740694d0ded78cb9
> 
> Symptoms seem to match, and if it tests out ok I can forward it to -fixes for
> 3.6, cc: stable.

tested.good. yay! I am happy now :) thx!

A patch referencing this bug report has been merged in Linux v3.6-rc4:

commit b70ad586162609141f0aa9eb34790f31a8954f89
Author: Xu, Anhua <anhua.xu@intel.com>
Date:   Mon Aug 13 03:08:33 2012 +0000

    drm/i915: fix wrong order of parameters in port checking functions