Bug 31901

Created attachment 40552 [details]
dmesg from problematic boot

Created attachment 40553 [details]
Xorg.0.log from problematic boot

Created attachment 40554 [details]
Image which exhibits the problem

Created attachment 40558 [details]
intel_reg_dumper output with flicker

Created attachment 40559 [details]
intel_reg_dumper output without flicker

Using an Ubuntu 10.04.1 live image, I see no flickering.

kernel: 2.6.32-24-generic 2.6.32.12
libdrm: 2.4.18-1ubuntu3
mesa: 7.7.1-1ubuntu3
xf86-video-intel: 2:2.9.1-3ubuntu5

The difference appears to simply be that in the working setup all 4 fdi lanes are used, whereas in the stripy broken setup, just 1 lane. This suggests that we are running too close to the bandwidth limit on a single lane.

On drm-intel-fixes, I've tweaked the fdi m/n calculation which may help, but that uses the same computed number of lanes.

Can you first try that branch and then (if it still fails) apply this tweak to print out the details of the computation and up the lane count to 2 (increase to 3 and then 4 until the display is stable):


diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index d9b7092..a9645fb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3790,6 +3790,9 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
                         */
                        u32 bps = target_clock * bpp * 21 / 20;
                        lane = bps / (link_bw * 8) + 1;
+                       printk(KERN_ERR "target=%d, bpp=%d, bps=%d, link_bw=%d, 
+                              target_clock, bpp, bps, link_bw, lane);
+                       lane = 2;
                }
 
                intel_crtc->fdi_lanes = lane;

Created attachment 40887 [details]
intel_reg_dumper output with forced lanes=4

The patch made no difference, even with lane = 4.

The calculation comes out as target=74080, bpp=18, bps=1400112, link_bw=270000, lanes=1

Attached is the intel_regs_dumper output with lane = 4

So all the registers that are dumped are the same. The stripy pattern is reminiscent of CxSR/FBC failure, but I can rule that out as you found the same issue on 2.6.37-rc3. I am back to being stumped, x201s happens to be our favourite laptop so is well tested... The only thing left to test is whether any of the fixes in drm-intel-fixes/drm-intel-next help. The LVDS SSC frequency fix might be relevant, but the symptom for that one is a failure to enable the pipe, i.e. a blank screen as opposed to stripy.

Created attachment 41156 [details]
intel_reg_dumper output with drm-intel-next

I still get flicker with drm-intel-next (using the amd64 package from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2010-12-15-natty/)

Ok, that doesn't yet have the SSC refclk fix, which is my remaining hope. I haven't yet merged that from -fixes into -next. If that fails, we have two choices: (1) randomly disable bits until it works or (2) bisect and hope to find a single rogue commit.

(In reply to comment #10)
> Ok, that doesn't yet have the SSC refclk fix, which is my remaining hope. I
> haven't yet merged that from -fixes into -next. If that fails, we have two
> choices: (1) randomly disable bits until it works or (2) bisect and hope to
> find a single rogue commit.

If by "the SSC refclk fix" you mean "drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks", that did not fix it.  I'm currently running 608ca70d22c0ea0d52aa71f52b8e326055c274d1 (http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2010-12-24-natty/) and still see the flickering.

Created attachment 41479 [details]
intel_reg_dumper output with drm-intel-next as of 608ca70d

I've tuned the watermarks to account for TLB misses, and we've tweaked the SSC settings. Can you please test drm-intel-next [http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git]?

Hmm, can you please retest with drm-intel-fixes for this

commit 2704cf5fbd248871a745d210733c6319959d2b0c
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Jul 28 11:52:45 2011 -0700

    drm/i915: flush plane control changes on ILK+ as well
    
    After writing to the plane control reg we need to write to the surface
    reg to trigger the double buffered register latch.  On previous
    chipsets, writing to DSPADDR was enough, but on ILK+ DSPSURF is the reg
    that triggers the double buffer latch.
    
    v2: write DSPADDR too to cover pre-965 chipsets
    v3: use flush_display_plane instead, that's what it's for
    v4: send the right patch
    
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Tested-by: Keith Packard <keithp@keithp.com>
    Reviewed-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>

fixed the flickering on one Arrandale eDP which might be related, along with plenty of other fixes.

Which repository is that commit available in? I can't find it in http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git, and Google doesn't know about the SHA1.

My apologies, I thought I had included the address in the cases where it did not appear before:

 git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git

Finally got around to testing with the kernel at
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2011-07-30-oneiric/, which is built from commit 9b546e571b94cacccf1091cc9cc0bd8a6a207a66 and contains 2704cf5fbd248871a745d210733c6319959d2b0c, but I'm still seeing the flickering.

Can you please retest with latest stable kernel (3.3 at this moment) and also please test whether adding i915.lvds_use_ssc=0 to your kernel bootline helps. In any case, please add drm.debug=0xe to your kernel bootline and attach the full dmesg.

I am no longer seeing the flicker with Ubuntu 12.04, which has the the following versions:

libdrm-intel1 2.4.32-1ubuntu1
libdrm2 2.4.32-1ubuntu1
libgl1-mesa-dri 8.0.2-0ubuntu3
linux-image-3.2.0-24-generic 3.2.0-24.38
xserver-xorg-video-intel 2:2.17.0-1ubuntu4

Ok, it's unclear what fixed things, but things seem fixed. Thanks for reporting this issue, I'll close it as unreproducible, please reopen if this shows up again for you.