Created attachment 50312 [details]
Screenshot without the problem

Created attachment 50313 [details]
Screenshot with the problem

Created attachment 50314 [details]
Xorg.0.log

Created attachment 50315 [details]
dmesg with debug info (after reproducing the problem)

Created attachment 50316 [details]
dmesg with debug info (just before reproducing the problem)

Created attachment 50317 [details]
intel_reg_dumper output (before)

Created attachment 50318 [details]
intel_reg_dumper output (after)

Created attachment 50319 [details]
xrandr --verbose

I can't make sense of this based on the commit... I'm afraid this might be timing related rather than an actual register change, since the register dumps before & after are identical.

Can you isolate which part of the patch causes problems?

(In reply to comment #9)
> I can't make sense of this based on the commit... I'm afraid this might be
> timing related rather than an actual register change, since the register dumps
> before & after are identical.
> 
> Can you isolate which part of the patch causes problems?

Argh, I'm terribly sorry for this but the actual offending commit was 

drm/i915: disable PCH ports if needed when disabling a CRTC

Which needed a bit of fixing to apply to .38, but has the same failure in both the backport and the upstream kernel

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commit;h=bbeaf8811ba070fd186dfcabc957044c3a1149ac

Ah ok, that makes more sense.  Does this patch change anything?  We might be disabling LVDS incorrectly (i.e. without a corresponding panel power sequence):

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 35364e6..ab8a36d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1394,7 +1394,7 @@ static void intel_disable_pch_ports(struct drm_i915_privat
        val = I915_READ(reg);
        if (ADPA_PIPE_ENABLED(val, pipe))
                I915_WRITE(reg, val & ~ADPA_DAC_ENABLE);
-
+#if 0
        reg = PCH_LVDS;
        val = I915_READ(reg);
        if (LVDS_PIPE_ENABLED(val, pipe)) {
@@ -1402,7 +1402,7 @@ static void intel_disable_pch_ports(struct drm_i915_privat
                POSTING_READ(reg);
                udelay(100);
        }
-
+#endif
        disable_pch_hdmi(dev_priv, pipe, HDMIB);
        disable_pch_hdmi(dev_priv, pipe, HDMIC);
        disable_pch_hdmi(dev_priv, pipe, HDMID);

@Jesse,

Unfortunately no, I can still reproduce with the patch in comment 11.

(In reply to comment #12)
> @Jesse,
> 
> Unfortunately no, I can still reproduce with the patch in comment 11.

he tested on 3.0.1 there with this kernel

http://kernel.ubuntu.com/~sarvatt/fdo40172/

Can you try to isolate which part of the PCH port disable causes trouble?  My other guess would be the panel register unlock, which might allow a clock change or something else to sneak in and cause LVDS problems...

I wonder if this relates to drm/i915: Enable dither whenever display bpc < frame buffer bpc?

FYI, I still have this issue with 3.2.0.

Created attachment 59984 [details] [review]
manual revert of offending patch

Can you please try with the latest 3.3 kernel (or maybe even 3.4-rc) and check whether this patch still solves your issues?

Any update?  I think this must have been fixed by one of the dither fixes...

Sorry for the delay. I've just tried, and I can still reliably reproduce this with 3.4rc5.

Do you want me to try with 3.4rc5 and the patch in comment 17?

OK, unfortunately I can still reproduce the issue with 3.4rc5 and the patch in comment 17.

Ok, so the manual revert doesn't help any longer. Which means something else changed, too.

Can you please try the modeset-rework branch from my personal git repo at:

http://cgit.freedesktop.org/~danvet/drm

Among other things, this undoes the offending commit in a rather through-rough manner.

2 months have passed since the last request for patch feedback, and the modeset-rework has landed upstream... Presuming fixed.

Sorry for the lack of feedback. I can still reproduce this reliably with 3.5.0 and 3.8.0.

I can verify this occurs occasionally with my Lenovo T510 ThinkPad on Trusty Tahr (14.04 Ubuntu). Please let me know if any supporting documentation is needed on my end.

I can confirm that this is still an issue with 3.13 and 3.16.

Can someone lease retest with latest drm-intel-nightly from http://cgit.freedesktop.org/drm-intel Thanks. Still no idea though what's amiss here ...

i would try this if someone could walk me through downloading, applying and installing this patch - i don't know what i'm doing here.

(In reply to D B from comment #29)
> i would try this if someone could walk me through downloading, applying and
> installing this patch - i don't know what i'm doing here.

Long shot but if you're on debian or ubuntu you can install a new one from here http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/

trying to install from there gives me "Dependency is not satisfiable: linux-headers-3.18.0-994"

(In reply to Daniel Vetter from comment #28)
> Can someone lease retest with latest drm-intel-nightly from
> http://cgit.freedesktop.org/drm-intel Thanks. Still no idea though what's
> amiss here ...

Ping for the testing.

I would do the testing, but I'm unable to successfully install the new kernel. It would be appreciated if someone could give me a walk-through of how to accomplish this.

The good news is I no longer seem to be able to reproduce this with kernel 3.18 in the current Ubuntu daily.

The bad news is running the test script three times in a row has given me a headache :)

(In reply to D B from comment #33)
> I would do the testing, but I'm unable to successfully install the new
> kernel. It would be appreciated if someone could give me a walk-through of
> how to accomplish this.

I'm afraid that's beyond our scope here; please try to look at your distro's documentation and wikis.

(In reply to Marc Deslauriers from comment #34)
> The good news is I no longer seem to be able to reproduce this with kernel
> 3.18 in the current Ubuntu daily.

Thanks for testing. I'm optimistic today, and closing the bug based on this. Please don't hesitate to reopen if the problem reappears on v3.18 or later.

> The bad news is running the test script three times in a row has given me a
> headache :)

I'm sorry to hear that, clearly RESOLVED NOTOURBUG though. ;)