Bug 48170

Summary: [regression arrandale] X blanks when external HDMI/DVI connected since 3.2.7 and 3.3
Product: DRI Reporter: Brice Goglin <brice.goglin>
Component: DRM/IntelAssignee: Daniel Vetter <daniel>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: medium CC: ben, chris, daniel, jbarnes, jrnieder
Version: XOrg gitKeywords: regression
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 42991    
Attachments:
Description Flags
dmesg
none
dmesg with drm.debug=0xe
none
sprinkle a few printks
none
dmesg with more printk
none
Print out the bw required and bw products
none
dmesg with more printk + bw
none
properly compute dp dithering
none
dmesg after applying "59486: properly compute dp dithering"
none
properly compute dp dithering v2
none
properly compute dp dithering v3
none
dmesg after applying "59683: properly compute dp dithering v3" none

Description Brice Goglin 2012-04-02 00:08:11 UTC
Created attachment 59360 [details]
dmesg

Hello,

Linux 3.2.6 worked fine on this machine. 3.2.7 and 3.3 blank when X starts with an external DVI monitor connected to one of the HDMI/DVI outputs of the dock station. KMS starts fine, but X cannot start. dmesg says:

[drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:3]


If I unplug the DVI monitor, eDP works fine.


I only found two references to i915 in the 3.2.7 changelog, and the Debian kernel guys told me the bad commit was likely:

 commit 3d794f87238f
 Author: Keith Packard <keithp@keithp.com>
 Date:   Wed Jan 25 08:16:25 2012 -0800

     drm/i915: Force explicit bpp selection for intel_dp_link_required

     commit c898261c0dad617f0f1080bedc02d507a2fcfb92 upstream.


The machine is a Dell Latitude E6410 with westmere hardware:
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
	Subsystem: Dell Device 040a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 43
	Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
	Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Region 4: I/O ports at 60b0 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: <access denied>
	Kernel driver in use: i915


I am using Debian testing with Xserver 1.11.4, Intel driver 2.18.0, libdrm 2.4.30.

I am attaching dmesg. I don't have anything interesting in the Xorg log from the failure obviously.

Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666360
Comment 1 Daniel Vetter 2012-04-02 01:28:57 UTC
Please boot with drm.debug=0xe attached on your kernel commandline and attach the entire dmesg.
Comment 2 Brice Goglin 2012-04-02 02:15:33 UTC
Created attachment 59363 [details]
dmesg with drm.debug=0xe

Here's what you requested.
Comment 3 Daniel Vetter 2012-04-02 02:44:03 UTC
Created attachment 59365 [details] [review]
sprinkle a few printks

Please grab dmesg with drm.debug=0xe and this patch again - I need to double-check whether what's exactly going wrong.
Comment 4 Brice Goglin 2012-04-02 03:33:13 UTC
Created attachment 59367 [details]
dmesg with more printk

Added your debug printk
Comment 5 Chris Wilson 2012-04-03 08:13:30 UTC
Created attachment 59428 [details] [review]
Print out the bw required and bw products
Comment 6 Brice Goglin 2012-04-04 09:28:05 UTC
Created attachment 59481 [details]
dmesg with more printk + bw

Here's the new dmesg. In short, your new printk say:
[    4.571661] [drm:intel_dp_mode_fixup], dp link requires bw=173160 for clock=96200 and bpp=18
[    4.571663] [drm:intel_dp_mode_fixup], max-data-rate for clock 6 nad 1 lanes: 18
[    4.571664] [drm:intel_dp_mode_fixup], max-data-rate for clock 10 nad 1 lanes: 18
[   57.862489] [drm:intel_dp_mode_fixup], dp link requires bw=230880 for clock=96200 and bpp=24
[   57.862494] [drm:intel_dp_mode_fixup], max-data-rate for clock 6 nad 1 lanes: 24
[   57.862499] [drm:intel_dp_mode_fixup], max-data-rate for clock 10 nad 1 lanes: 24
[   57.862524] [drm:intel_dp_mode_fixup], dp link requires bw=173160 for clock=96200 and bpp=18
[   57.862529] [drm:intel_dp_mode_fixup], max-data-rate for clock 6 nad 1 lanes: 18
[   57.862534] [drm:intel_dp_mode_fixup], max-data-rate for clock 10 nad 1 lanes: 18
Comment 7 Daniel Vetter 2012-04-04 11:29:48 UTC
So the issue is that we want to turn it on with 24bpp instead of 18bpp. And there's not enough bw for that.
Comment 8 Daniel Vetter 2012-04-04 11:57:43 UTC
Created attachment 59486 [details] [review]
properly compute dp dithering

A quick patch for you to try. This will likely conflict with the debug patches, so please drop them.
Comment 9 Brice Goglin 2012-04-05 00:48:42 UTC
Created attachment 59504 [details]
dmesg after applying "59486: properly compute dp dithering"

No, still fails the same. dmesg attached.
Comment 10 Daniel Vetter 2012-04-05 01:01:02 UTC
Created attachment 59505 [details] [review]
properly compute dp dithering v2

Oops, broken logic in the patch. And I've added a printk to check it, too. Please retest.
Comment 11 Brice Goglin 2012-04-05 07:41:47 UTC
Still broken:

[drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:3]
dp mode_fixup, bpp: 24
[drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:3]
detected fb_set_par error, error code: -22
dp mode_fixup, bpp: 24
[drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:3]

and so on.

And eDP seems broken now too: it just blanks when KMS starts, even when the DVI monitor isn't plugged.

By the way, I screwed up my testing earlier with your first patch. It's basically broken as the last one: same CRTC:3 messages in dmesg, and eDP blanks.
Comment 12 Daniel Vetter 2012-04-09 08:47:37 UTC
Created attachment 59683 [details] [review]
properly compute dp dithering v3

As long as we have "dp mode_fixup, bpp: 24" in the dmesg, I've failed to write the correct patch and massive breakage is expected. The right thing is 18 bpp. So it looks like my brain has already been on leave for the easter w/e and v2 contained yet another goof-up.

New patch (this time hopefully correct) for you to test attached.
Comment 13 Brice Goglin 2012-04-10 00:20:57 UTC
Created attachment 59708 [details]
dmesg after applying "59683: properly compute dp dithering v3"

Yeah this one seems to work. eDP doesn't blank anymore. X starts fine with and without HDMI/DVI plugged, and I get my usual modes.

Thanks!

Reported-and-tested-by: Brice Goglin <Brice.Goglin@ens-lyon.org>
Comment 14 Chris Wilson 2012-04-14 05:51:44 UTC
commit c4867936474183332db4c19791a65fdad6474fd5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 10 10:42:36 2012 +0200

    drm/i915: properly compute dp dithering for user-created modes
    
    We've only computed whether we need to fall back to 6bpc due to dp
    link bandwidth constrains in mode_valid, but not mode_fixup. Under
    various circumstances X likes to create new modes which then lack
    proper 6bpc flags (if required), resulting in mode_fixup failures and
    ultimately black screens.
    
    Chris Wilson pointed out that we still get things wrong for bpp > 24,
    but that should be fixed in another patch (and it'll be easier because
    this patch consolidates the logic).
    
    The likely culprit for this regression is
    
    commit 3d794f87238f74d80e78a7611c7fbde8a54c85c2
    Author: Keith Packard <keithp@keithp.com>
    Date:   Wed Jan 25 08:16:25 2012 -0800
    
        drm/i915: Force explicit bpp selection for intel_dp_link_required
    
    v2: Fix indentation and tune down the too bold claim that this should
    fix the world. Both noticed by Chris Wilson.
    
    v3: Try to really git add things.
    
    Reported-and-tested-by: Brice Goglin <Brice.Goglin@ens-lyon.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48170
    Cc: stable@kernel.org
    Reviewed-by: Adam Jackson <ajax@redhat.com>
    Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 15 Jari Tahvanainen 2016-11-03 12:16:27 UTC
Closing resolved+fixed. Verified by Reporter. Code CommitDate: Thu Apr 12 2012.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.