8086:0046 [Lenovo ThinkPad T510] Fuzzy and corrupted display after DPMS cycles

[Marc Deslauriers]

Since updating to 2:2.14.0-4ubuntu7.2 in natty-proposed, screen comes up fuzzy and corrupted when coming out of the screensaver. I'm using the blank screen screensaver. Screen is flickery and graphics are corrupted and fuzzy. See attached screenshots.

This has now happened three times since I installed the version from -proposed, and had never happened before.

 it's happened 3 times in the last day and each time, I've rebooted, as I haven't figured out what else to do.
The screensaver probably has activated 30 times in the last day.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: xserver-xorg-video-intel 2:2.14.0-4ubuntu7.2
ProcVersionSignature: Ubuntu 2.6.38-11.47-generic 2.6.38.8
Uname: Linux 2.6.38-11-generic x86_64
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,mousepoll,vpswitch,regex,animation,snap,expo,move,compiztoolbox,place,grid,imgpng,gnomecompat,wall,ezoom,workarounds,staticswitcher,resize,fade,unitymtgrabhandles,scale,session,unityshell]
CompositorRunning: compiz
Date: Thu Jul 21 18:18:03 2011
DistUpgraded: Fresh install
DistroCodename: natty
DistroVariant: ubuntu
GraphicsCard:
 Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:21d9]
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20110302)
MachineType: LENOVO 4313CTO
ProcEnviron:
 LANGUAGE=en_CA:en
 PATH=(custom, user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-11-generic root=UUID=66b32bb3-1e18-436e-8f6e-62b8419ed48d ro quiet splash vt.handoff=7
Renderer: Unknown
SourcePackage: xserver-xorg-video-intel
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/26/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 6MET81WW (1.41 )
dmi.board.name: 4313CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6MET81WW(1.41):bd10/26/2010:svnLENOVO:pn4313CTO:pvrThinkPadT510:rvnLENOVO:rn4313CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 4313CTO
dmi.product.version: ThinkPad T510
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.4+bzr20110606-0ubuntu1~natty2
version.ia32-libs: ia32-libs 20090808ubuntu13
version.libdrm2: libdrm2 2.4.23-1ubuntu6
version.libgl1-mesa-dri: libgl1-mesa-dri 7.10.2-0ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.10.2-0ubuntu2
version.xserver-xorg: xserver-xorg 1:7.6+4ubuntu3.1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.0-0ubuntu4.1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.14.0-4ubuntu7.2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu7

[Marc Deslauriers (mdeslaur)]

Here's my current dpkg.log

[Marc Deslauriers (mdeslaur)]

More info: when the problem occurs, it also happens on virtual consoles. Ctrl-Alt-F1 shows me a corrupted console also.

[Bryce Harrington (bryce)]

The 7.2 -intel update adds patch 121_fdo-28798-fix.patch. This patch significantly changes rendering behavior with 2D graphics acceleration, thus is definitely a strong suspect for this issue (although it's quite strange that it affects the console too!) To prove it is the patch's fault, downgrade to 7.1; if it no longer reproduces within ~1 day, then the patch is at fault and we should not proceed with the SRU. If it still reproduces, then we should examine dpkg.log for other possible suspects.

Corruption that affects the console indicates either a kernel bug, or an X bug that somehow put the GPU into a really bad state. Booting and reproducing on an earlier kernel would rule out it being due to a kernel update.

If it *is* pinpointed to the patch, would you mind also booting an oneiric livecd and see whether you can reproduce it there. I ask because we're already including this patch in oneiric and if the same issue exists there, we ought to look into it more closely. If it doesn't occur on oneiric, then presumably we can just forgo the 7.2 SRU and leave it at that.

[Bryce Harrington (bryce)]

upgrade bluefish 2011-07-20 08:04:37 2.0.2-1 2.0.2-1ubuntu1
upgrade bzr 2011-07-20 08:04:42 2.3.3-0ubuntu1 2.3.4-0ubuntu1
install eglibc 2011-07-21 13:41:23 <none> 2.13-0ubuntu13
upgrade linux 2011-07-19 16:05:37 2.6.38-10.46 2.6.38-11.47
install linux-headers-2.6.38-11 2011-07-19 16:05:31 <none> 2.6.38-11.47
install linux-headers-2.6.38-11-generic 2011-07-19 16:05:34 <none> 2.6.38-11.47
install linux-image-2.6.38-11-generic 2011-07-19 16:05:17 <none> 2.6.38-11.47
upgrade linux-meta 2011-07-19 16:05:28 2.6.38.10.25 2.6.38.11.26
upgrade nfs-utils 2011-07-20 08:04:48 1:1.2.2-4ubuntu5 1:1.2.2-4ubuntu5.1
install valgrind 2011-07-21 13:41:25 <none> 1:3.6.1-0ubuntu1
upgrade xserver-xorg-video-intel 2011-07-20 08:04:50 2:2.14.0-4ubuntu7.1 2:2.14.0-4ubuntu7.2

Either linux or -intel could be a suspect at this point, looks like nothing else of relevance got updated within the timeframe.

[Marc Deslauriers (mdeslaur)]

OK, looks like this isn't caused by the intel driver in proposed. I just had it happen with 2:2.14.0-4ubuntu7.1.
Next in line is the kernel update...

[Marc Deslauriers (mdeslaur)]

I've been running with 2.6.38-10 for the past week, and this problem has not come back. This could definitely be a kernel regression.

[Marc Deslauriers (mdeslaur)]

3 hours after trying 2.6.38-11 again, I've been hit by the bug. I'm pretty convinced this is a regression in the kernel currently in -proposed.

[Herton R. Krzesinski (herton)]

It's likely a drm/i915 change which is causing the regression. Probably one of these four candidates that we got through stable update to 2.6.38.8:
drm/i915: Fix gen6 (SNB) missed BLT ring interrupts.
drm/i915: disable PCH ports if needed when disabling a CRTC
drm: Send pending vblank events before disabling vblank.
drm/i915: fix user irq miss in BSD ring on g4x

In a hunch, I reverted "drm: Send pending vblank events before disabling vblank.", built, and uploaded amd64 packages at http://people.canonical.com/~herton/lp814325/r1/

Marc, can you test it?

If it works, then try the 11.48 when it hits -proposed, just to double check. If it fails, then we got our change which introduced the issue.

[Marc Deslauriers (mdeslaur)]

Thanks Herton, I'll install them now and let you know...It will take a day or two as I can't reproduce this at will, but it usually happens a couple of times a day.

[Marc Deslauriers (mdeslaur)]

I've ran your test packages for the past day and a half and didn't get the issue.
I have now installed the 11.48 packages in -proposed, to see if it will come back.

[Marc Deslauriers (mdeslaur)]

I've now hit the problem again with the 11.48 packages in -proposed. Since it took two days for me to hit it, I'm now switching back to your test packages to see if the commit you reverted was the right one. I think I didn't wait long enough.

[Marc Deslauriers (mdeslaur)]

Unfortunately, I have hit the issue with the test packages from comment #12.

@Herton: do you have a second candidate I could test? Thanks!

[Herton R. Krzesinski (herton)]

Ok, lets see if some of other remaining drm/i915 changes is at fault. Marc, please try the kernel from http://people.canonical.com/~herton/lp814325/r2/

[Marc Deslauriers (mdeslaur)]

Thanks for the updated package Herton, I'm testing them now.

[Marc Deslauriers (mdeslaur)]

Herton, I've been running your updated packages for three days now with no sign of the regression. I'll continue running it, but I think you've located the problematic commits.

[Herton R. Krzesinski (herton)]

Thanks for testing, hopefully the regression really is gone reverting the 3 patches. If you could find an way to reproduce the problem more easily, may be come and go many times in sequence from screen saver/blank would be great, problem is I think you'll get bored easily always having to check the corrupted screen many times in a row :)

The three remaining reverted patches in r2 were:
drm/i915: Fix gen6 (SNB) missed BLT ring interrupts.
drm/i915: disable PCH ports if needed when disabling a CRTC
drm/i915: fix user irq miss in BSD ring on g4x

We should identify now which one is introducing the problem. I took a deep look again at them, and compared now against your reported hardware (lspci). You have an "ironlake" vga. The first and last patches touches code paths only related to sandybridge or gm45/g45 hardware, which shouldn't affect/change your case. Hoping this isn't a timing/code shuffle issue, now I strongly believe we could have a problem with the remaining patch:

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

This was a backport for hardware enablement, and also it is missing a following fix to this change which is upstream but wasn't backported to natty: "drm/i915: DP_PIPE_ENABLED must check transcoder on CPT".

First lets try to double check and really see if "drm/i915: disable PCH ports if needed when disabling a CRTC" introduces your regression, now I built a new kernel only with it reverted, please try the package http://people.canonical.com/~herton/lp814325/r3/

If this one works, then next step is including also "drm/i915: DP_PIPE_ENABLED must check transcoder on CPT" on natty, and doing another test to see if issue is gone.

[Timo Aaltonen (tjaalton)]

Yes, we really need that commit, so identifying additional ones to fix this bug would be most welcome.

[Marc Deslauriers (mdeslaur)]

OK, with the attached script, I can reproduce the issue reliably with the -proposed kernel.

Your r3 kernel does not have the issue, so that's the right commit.

[Herton R. Krzesinski (herton)]

Marc, please try now the kernel from http://people.canonical.com/~herton/lp814325/r4/

It reapplies the fix plus the change "drm/i915: DP_PIPE_ENABLED must check transcoder on CPT"

[Marc Deslauriers (mdeslaur)]

Herton, unfortunately the regression is in r4 :(

[Herton R. Krzesinski (herton)]

@Timo: any idea on this one? looks like we have to revert "drm/i915: disable PCH ports if needed when disabling a CRTC" for now :-/ The followup fix didn't worked.

[Chris Halse Rogers (raof)]

I'm wondering if this isn't a spread-spectrum bug - http://article.gmane.org/gmane.linux.kernel/1173193 sounds similar, although not identical. Maybe the connector is being turned back on with SSC enabled?

The patch starting that thread is not going to be applied upstream, as it just adds an option to work around a bug, but that means it could be used to test this SSC hypothesis.

[Chris Halse Rogers (raof)]

Oooh. Looks like the thread starting with http://<email address hidden> is likely to be the upstream fix for the spread-spectrum bit.

[Robert Hooker (sarvatt)]

Marc: Can you post the intel_reg_dumper output from before and after triggering this?

[Marc Deslauriers (mdeslaur)]

@Robert: unfortunately, they are the same.

[Marc Deslauriers (mdeslaur)]

What's interesting is once the problem occurs, I can do xset dpms force off; xset dpms force on to make it go away again.

[Keng-Yu Lin (lexical)]

The following models are tested with epilepsy.sh in the comment #22

Lenovo ZHAOYANG E47 with Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz)
Acer eMachine AS4739Z with Intel(R) Pentium(R) CPU P6200 @ 2.13GHz
Dell Inspiron N311z with Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz

but I cannot reproduce the bug.

[Keng-Yu Lin (lexical)]

BTW, the three models above were reported having bug 791752.

[Keng-Yu Lin (lexical)]

Dell Vostro V130 with Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz

is tested for comparison. not able to reproduce either.

[Marc Deslauriers (mdeslaur)]

I can't reproduce it either on a Dell Mini 9. That's the only other intel chipset machine I have.

[Timo Aaltonen (tjaalton)]

Herton, Marc: maybe test a newer mainline kernel (2.6.39, 3.0) to see that this really is fixed there, and if not, the patch that Chris pointed out could be another candidate to give a try.

[Keng-Yu Lin (lexical)]

Does this bug exist in Oneiric too?

[Marc Deslauriers (mdeslaur)]

Unfortunately, I just tried with the Oneiric alpha3 amd64 live cd, and I have the same regression. Here are a couple of screenshots.

[Robert Hooker (sarvatt)]

Dell E6420 (gen6): can't reproduce
Dell Vostro 3750 (gen6): can't reproduce
Thinkpad T420s (gen6): can't reproduce
Acer Aspire One AOA150 (gen3): can't reproduce

Can anyone with a gen4 or gen5 intel (965 through 1st generation core integrated HD graphics) reproduce this with the script on comment #22 to help narrow down which generations are having the problem?

[Marc Deslauriers (mdeslaur)]

Please keep in mind that when running the script, the regression may occur during an attempt and immediately clear up at the next one, so you need to carefully look at the screen at each attempt.

[Herton R. Krzesinski (herton)]

To help out, I backported the patches Chris pointed in comment #27 out to the natty kernel in proposed. Marc, here is the kernel for you to try: http://people.canonical.com/~herton/lp814325/r5/

[Robert Hooker (sarvatt)]

Ah Keng-Yü did test a GMA 4500 (gen4) and an arrandale (gen5) so it looks like the impact of this might be even more limited than I thought. The patches RAOF posted most likely will not make it upstream because they caused these regressions

https://bugs.freedesktop.org/show_bug.cgi?id=40029
https://bugs.freedesktop.org/show_bug.cgi?id=40030

[Marc Deslauriers (mdeslaur)]

Unfortunately, the test kernel from comment #44 still contains the regression.

[Marc Deslauriers (mdeslaur)]

Oh, another detail: it's not just when I screen blank, sometimes my laptop boots in this condition also.

[Chris Van Hoof (vanhoof)]

Would it be worth while to find another T510 to see if we can mimic these results there as well?

[Marc Deslauriers (mdeslaur)]

I can't reproduce this on wife's Dell XPS 15 with Sandybridge.

[Chris Van Hoof (vanhoof)]

@Marc is that XPS nVidia based?

Just a quick re-cap of our testing so far:

== can not reproduce ==
 * Lenovo x220 (gen6)
 * Dell E6420 (gen6)
 * Dell Vostro 3750 (gen6)
 * Thinkpad T420s (gen6)
    * Intel/nVidia switchable config
 * Dell Inspiron N311z (gen6)
 * Lenovo E47 (gen6)
 * Dell Vostro v130 (gen5)
 * Acer eMachine AS4739Z (gen4)
 * Acer Aspire One AOA150 (gen3)
 * Dell Mini 9 (gen3)

I'm tracking down a t510 to see what we end up with there.

[Marc Deslauriers (mdeslaur)]

@Chris: it's a XPS 15 (L502X) with a nVidia Optimus in it, but by default it just runs on the internal Intel card:

[ 17.050] (--) PCI:*(0:0:2:0) 8086:0116:1028:050e rev 9, Mem @ 0xf1400000/419
4304, 0xe0000000/268435456, I/O @ 0x00004000/64
[ 17.050] (--) PCI: (0:1:0:0) 10de:0df4:1028:050e rev 161, Mem @ 0xf0000000/1
6777216, 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x00003000/128, BIOS @
 0x????????/524288
<snip>
[ 17.323] (II) intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge
[ 17.323] (--) intel(0): Chipset: "Sandybridge"

[James Ferguson (jamesf)]

I have a T510 here, graphics 8086:0046, kernel 2.6.38-11.48. I've done at least 4 runs of epilepsy.sh on kernel watching it like a hawk, with no failures.

[Marc Deslauriers (mdeslaur)]

I have the 1920x1080 LCD, I wonder if that makes a difference.

[James Ferguson (jamesf)]

Possible. The t510 I have has low res (1366x768). Previously I tested initial Natty + proposed kernel, but I did a full upgrade to -proposed and still no reproduction.

[Marc Deslauriers (mdeslaur)]

meh, updating my firmware to 1.46 didn't help.

[Chris Van Hoof (vanhoof)]

Would testing on a reduced resolution be of any benefit? Looking at the machines we've tested internally, especially those that are /not/ gen6 none of them are capable of such a high resolution.

[Marc Deslauriers (mdeslaur)]

I just tried lowering my resolution to 1360x768, and I can still reproduce with the script.

Uhm...I'm gen 5 and am certainly running 1920x1080...

Actually, now that I think about it, this laptop has a nVidia Optimus in it also, which I've disabled in the bios...maybe that's related...I didn't think of mentioning this as I have never enabled the nVidia chip in it.

[Chris Van Hoof (vanhoof)]

@Marc was just outlining the machines we tested today, not yours :)

Good pointer on the nvidia add-on. I just took a look at what we have t510 wise and we do have both configurations available, and the one used today looks to be the Intel only variant. We'll give the optimus config a test with it disabled in the BIOS.

--chris

[Robert Hooker (sarvatt)]

Ok so at this point it is a bug that is still a problem in the upstream kernel that is specific to this optimus machine and we have nothing in house available that can reproduce it. Can you please install this kernel

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.1-rc2-oneiric/

booting with drm.debug=0x5 added to the kernel command line and attach the dmesg after reproducing it so we can upstream this bug report?

[Chris Van Hoof (vanhoof)]

A quick note on our t510 testing.

The t510 we have in-house with nvidia graphics is in-deed a switchable/hybrid graphics system, however it does not have the ability to control which device is used in the BIOS.

The t510 Marc is reporting this against is a bit newer and does support the ability to choose which graphics device is used in the BIOS.

Due to this, we're not able to reproduce on our t510 in a way that mimics Marc's configuration:

http://www.bios-mods.com/forum/Thread-ThinkPad-T410-T510-Intel-IGP-Optimus-Unlock-Request

[Marc Deslauriers (mdeslaur)]

@Robert: can I install that test kernel on natty, or do I need to upgrade to oneiric first?

[Robert Hooker (sarvatt)]

natty is fine, it's just based on the oneiric kernel configuration but that shouldn't matter

[Marc Deslauriers (mdeslaur)]

Attached is results of dmesg comment (dmesg.txt) and /var/log/dmesg after booting the rc2 kernel and reproducing the issue.

[Robert Hooker (sarvatt)]

Marc: apologies, 5 is too much debug info and it was lost from the log there. can you try again with drm.debug=0xe instead?

[Marc Deslauriers (mdeslaur)]

Here are three log files:
dmesg-booted-regression.txt: booted directly into regression
dmesg-ok.txt: booted into working condition
dmesg-triggered-regression.txt: dmesg after triggering regression

[Chris Van Hoof (vanhoof)]

Quick update on today's testing.

In addition to the machines outlined in Comment #50 we were able to locate two Lenovo T510's in-house. One configuration is Intel graphics only, the other is a Intel/nVidia switchable configuration. Unfortunately only the /latest/ T510's provide the ability to switch graphics cards within the BIOS[0], Intel is disabled and nVidia is the default GPU used. Our T510 switchable config does not expose this option in the BIOS and there is not a BIOS update available which would expose this functionality.

We have not been able to reproduce this same behavior on either of the T510's we have access to.

Based on our testing to date, this issue does appear to be limited to one of the following:

 * /Newer/ Lenovo T510 (potentially T410) configurations with switchable graphics, using the Intel GPU as default GPU
 * Arrandale based platforms with switchable graphics using the Intel GPU as default GPU

The large majority of platforms the HWE Team has seen with switchable graphics configurations have been SandyBridge based, which in either the Intel or nVidia test case cannot reproduce this behavior.

--chris

[0] -- http://www.thinkwiki.org/wiki/Intel_HD_Graphics

[Marc Deslauriers (mdeslaur)]

I've now updated to Oneiric, and I can still reproduce this issue (not surprisingly).

[Robert Hooker (sarvatt)]

Created attachment 50311
Script to reproduce

Forwarding this for launchpad bug reporter Marc Deslauriers
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/814325

After f0575e92974d328e8816ed89704c985a7d7d90ac (drm/i915: DP_PIPE_ENABLED must check transcoder on CPT) was introduced in the kernel this person's Lenovo T510 machine started to come back from dpms fuzzy (see attached pictures) randomly, and another dpms cycle corrects it. This is still a problem on 3.1-rc2, and seems to be limited to this one machine with an optimus configuration (set to use only the integrated GPU) after testing on a wide variety of other machines including another T510 with an intel only config. He can reproduce the bug with the attached epilepsy.sh script which does rapid dpms off and on again easily.

System environment:
-- chipset: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046]
-- system architecture: amd64
-- xf86-video-intel/xserver/mesa/libdrm version: both ubuntu 11.04 and current 11.10 were tested. 11.04: libdrm 2.4.23, xf86-video-intel 2.14, mesa 7.10.2, xserver 1.10.1, kernel 2.6.38-11.48
11.10: libdrm 2.4.26, xf86-video-intel 2.15.901, mesa 7.11, xserver 1.10.2.902, kernel 3.0.1
-- kernel version: 2.6.38-11 (which has the above commit backported), 3.1-rc2, various other kernels in between those two
-- Linux distribution: Ubuntu 11.04, Ubuntu 11.10
-- Machine or mobo model: Lenovo T510 (4313CTO)
-- Display connector: LVDS

[Robert Hooker (sarvatt)]

Created attachment 50312
Screenshot without the problem

[Robert Hooker (sarvatt)]

Created attachment 50313
Screenshot with the problem

[Robert Hooker (sarvatt)]

Created attachment 50314
Xorg.0.log

[Robert Hooker (sarvatt)]

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

[Robert Hooker (sarvatt)]

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

[Robert Hooker (sarvatt)]

Created attachment 50317
intel_reg_dumper output (before)

[Robert Hooker (sarvatt)]

Created attachment 50318
intel_reg_dumper output (after)

[Robert Hooker (sarvatt)]

Created attachment 50319
xrandr --verbose

[Timo Aaltonen (tjaalton)]

The problematic commit also fixed bug 745112, which happens to haunt (other) arrandale users :/

[Jesse Barnes (jbarnes-virtuousgeek)]

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?

[Robert Hooker (sarvatt)]

(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

[Jesse Barnes (jbarnes-virtuousgeek)]

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);

[Marc Deslauriers (mdeslaur)]

@Jesse,

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

[Robert Hooker (sarvatt)]

(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/

[Jesse Barnes (jbarnes-virtuousgeek)]

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...

[Chris Wilson (ickle)]

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

[Marc Deslauriers (mdeslaur)]

Anybody want to try and figure out which part of the patch is causing the issue, as suggested in the upstream bug? This is really annoying with Oneiric...

[Herton R. Krzesinski (herton)]

The commit which caused this regression is now reverted on natty kernel, currently available in -proposed. These reverts are not subject to verification, marking as verification-done-natty.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.38-12.51

---------------
linux (2.6.38-12.51) natty-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #860832

  [ Alex Bligh ]

  * SAUCE: net/netfilter/nf_conntrack_netlink.c: fix Oops on container
    destroy
    - LP: #843892

  [ Jesse Sung ]

  * SAUCE: Unregister input device only if it is registered
    - LP: #839238

  [ Leann Ogasawara ]

  * SAUCE: x86: reboot: Make Dell Latitude E6220 use reboot=pci
    - LP: #838402
  * SAUCE: x86: reboot: Make Dell Latitude E6520 use reboot=pci
    - LP: #833705

  [ Ming Lei ]

  * SAUCE: fireware: add NO_MSI quirks for o2micro controller
    - LP: #801719

  [ Stefan Bader ]

  * [Config] Include all filesystem modules for virtual
    - LP: #761809

  [ Tim Gardner ]

  * [Config] kernel preparation cannot be parallelized
  * [Config] Linearize module/abi checks
  * [Config] Linearize and simplify tree preparation rules
  * [Config] Build kernel image in parallel with modules
  * [Config] Set concurrency for kmake invocations
  * [Config] Improve install-arch-headers speed
  * [Config] Fix binary-perarch dependencies
  * [Config] Removed stamp-flavours target
  * [Config] Serialize binary indep targets
  * [Config] Use build stamp directly
  * [Config] Restore prepare-% target
  * [Config] Fix binary-% build target

  [ Upstream Kernel Changes ]

  * Revert "drm/i915: disable PCH ports if needed when disabling a CRTC"
    - LP: #814325, #838181
  * drm/i915: restore only the mode of this driver on lastclose (v2)
    - LP: #848687
  * cifs: fix possible memory corruption in CIFSFindNext, CVE-2011-3191
    - LP: #834135
    - CVE-2011-3191
  * befs: Validate length of long symbolic links, CVE-2011-2928
    - LP: #834124
    - CVE-2011-2928
  * gro: Only reset frag0 when skb can be pulled, CVE-2011-2723
    - LP: #844371
    - CVE-2011-2723
  * inet_diag: fix inet_diag_bc_audit(), CVE-2011-2213
    - LP: #838421
    - CVE-2011-2213
  * si4713-i2c: avoid potential buffer overflow on si4713, CVE-2011-2700
    - LP: #844370
    - CVE-2011-2700
  * Bluetooth: Prevent buffer overflow in l2cap config request,
    CVE-2011-2497
    - LP: #838423
    - CVE-2011-2497
  * crypto: Move md5_transform to lib/md5.c, CVE-2011-3188
    - LP: #834129
    - CVE-2011-3188
  * net: Compute protocol sequence numbers and fragment IDs using MD5,
    CVE-2011-3188
    - LP: #834129
    - CVE-2011-3188
  * x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS
    - LP: #760131
  * x86, intel, power: Correct the MSR_IA32_ENERGY_PERF_BIAS message
    - LP: #760131
  * rt2x00: Serialize TX operations on a queue.
    - LP: #855239
  * ext4: Fix max file size and logical block counting of extent format
    file, CVE-2011-2695
    - LP: #819574
    - CVE-2011-2695
 -- Herton Ronaldo Krzesinski <email address hidden> Tue, 27 Sep 2011 16:19:57 -0300

[Orographic (temp850)]

I've also got this problem, using Lubuntu 11.10 and Ubuntu 11.10 (Unity). My screen tends to go fuzzy as soon as I log in, after boot up. It then disappears after about one minute. I'm no expert but am handy with computers.

When I enter this into terminal:

sudo lshw -C video

I get this as my video card:

 *-display
       description: VGA compatible controller
       product: Core Processor Integrated Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 12
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:47 memory:fb400000-fb7fffff memory:e0000000-efffffff ioport:ff00(size=8)

My motherboard is a GAH55-USB3 and I'm using a first generation Core i3 chip, with the on-chip GPU.

What logs can I show you? To help you with this? I don't think the problem occurs with Linux Mint 11 LXDE.

[Orographic (temp850)]

Hmm, interesting. I've changed my monitor to D-sub instead of DVI connection and this problem seems to have gone. Have only turned off and turned on five times but it hasn't occured. It occured every time via DVI.

My monitor is a BenQ E2200HD 22" at 1920 by 1080.

Will keep testing in Lubuntu to see if it stays good.

[Marc Deslauriers (mdeslaur)]

@Orographic: If you can't reproduce it with the script in comment #22, you probably don't have the same issue...

[Orographic (temp850)]

Thanks for that, I'm not sure how to use that script in comment #22 but could easily learn, I'm sure. I have four drives in my system (Two Windows 7 drives, testing and production, and the same for Linux) that are all imaged via Clonezilla and Acronis, so its easy to restore my Linux distros.

I've just changed my DVI cable over to a new one and the monitor has turned on no problems, five times in a row thus far. So, it seems my situation is related to a faulty DVI cable.

Thanks for all the work you guys are doing, its always appreciated.

[Marc Deslauriers (mdeslaur)]

Unfortunately, the problem persists with: :(

linux-image-3.2.0-999-generic 3.2.0-999.201111140405

[Ben (bhubu)]

I am not sure whether this bug is related to my issue, but I am also not sure how I could figure it out.

Since today I get a white screen on the X display when using an external display and switching from screen mirroring to split screens. Switching to console shows a drm intel_disable_transcoder failure. After reboot the problem occurs reproducible each time screen properties are changed from mirror to split screen.

Ubuntu 11.10
Kernel 3.0.0-13-generic x86_64
Sony Z21

[Marc Deslauriers (mdeslaur)]

OK, I am now upgraded to Precise running 3.2.0-7-generic, and am still getting this issue, unfortunately.

[Marc Deslauriers (mdeslaur)]

FYI, I still have this issue with 3.2.0.

[Brian (rephorm)]

I am also affected by this (or at least a very similar) bug on a Sony VAIO VPCEA laptop on kernel 3.0.0-14-generic (oneiric).

After the display blanks (e.g. if `xset s blank` is set), the laptop display is corrupted (pink and white vertical stripes) after resuming. An externally connected monitor turns back on correctly.

I can manually trigger by running `sleep 1 && xset dpms force off`
Running `xset dpms force off` (without the sleep) causes the display to cycle off and back on quickly, upon which it recovers correctly.

lspci lists the video card as:
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)

lshw says:

 *-cpu
       description: CPU
       product: Intel(R) Core(TM) i5 CPU M 450 @ 2.40GHz
       vendor: Intel Corp.
       physical id: 4
       bus info: cpu@0
       version: Intel(R) Core(TM) i5 CPU M 450 @ 2.40GHz
       serial: N/A
       slot: N/A
       size: 1199MHz
       capacity: 1199MHz
       width: 64 bits
       clock: 133MHz
       capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp x86-64 constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid cpufreq

  *-display
       description: VGA compatible controller
       product: Core Processor Integrated Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 02
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:42 memory:f0000000-f03fffff memory:e0000000-efffffff ioport:e080(size=8)

[Daniel-ffwll (daniel-ffwll)]

Created attachment 59984
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?

[Jesse Barnes (jbarnes-virtuousgeek)]

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

[Marc Deslauriers (mdeslaur)]

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

[Marc Deslauriers (mdeslaur)]

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

[Marc Deslauriers (mdeslaur)]

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

[Marc Deslauriers (mdeslaur)]

I can still reproduce this reliably with 3.4rc5

[Daniel-ffwll (daniel-ffwll)]

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

[Simon Bateman (batemans-25)]

just upgraded from oneric to precise

Screen now a DISASTER ZONE!
=========================
When exiting any application the 'old app.screen' blurrs and fails to close at all
Some LaunchPad Icons disappear, clicking in the right spot does activate task.

Log-off icon has vanished to right of top menu bar

Using WORKSPACE SWITCHER to refresh screen does work to remove old app.

Last month (early MAY), I tried a 12.04 beta CD (from Linux User) without any screen problems.

using LENOVO 4151 laptop

[Marc Deslauriers (mdeslaur)]

@Simon: your bug has _nothing_ to do with this bug. Please file a new one, thanks.

[Daniel-ffwll (daniel-ffwll)]

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.

[Chris Wilson (ickle)]

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

[dino99 (9d9)]

https://wiki.ubuntu.com/Releases

[Marc Deslauriers (mdeslaur)]

I still have this issue with Raring and kernel 3.8.0.

[Marc Deslauriers (mdeslaur)]

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

[Marc Deslauriers (mdeslaur)]

FYI, I just upgraded to bios 1.52 and can still reproduce this this saucy.

 Version: 6MET92WW (1.52 )

[penalvch (penalvch)]

Marc Deslauriers, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please just make a comment to this.

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Joseph Salisbury (jsalisbury)]

This bug was nominated against a series that is no longer supported, ie saucy. The bug task representing the saucy nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

This bug was nominated against a series that is no longer supported, ie raring. The bug task representing the raring nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

This bug was nominated against a series that is no longer supported, ie quantal. The bug task representing the quantal nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Dustin-backlund (dustin-backlund)]

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.

[Marc Deslauriers (mdeslaur)]

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

[Daniel-ffwll (daniel-ffwll)]

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 ...

[Dustin-backlund (dustin-backlund)]

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.

[Robert Hooker (sarvatt)]

(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/

[Dustin-backlund (dustin-backlund)]

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

[Jani-nikula (jani-nikula)]

(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.

[Dustin-backlund (dustin-backlund)]

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.

[Marc Deslauriers (mdeslaur)]

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 :)

[Jani-nikula (jani-nikula)]

(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. ;)

[Mathew Hodson (mhodson)]

The upstream bug has been marked fixed, so this needs to be tested to see if it's still an issue.

[Mathew Hodson (mhodson)]

Could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed.

[dino99 (9d9)]

That report refer to an old issue, and there is no activity; so closing it.