2013-03-18 14:48:59

by Sergio Callegari

[permalink] [raw]
Subject: Stable kernel 3.8.3 appears to break displayport on intel gen4

Hi,

hope sending this message here is OK. In case it is not please take my
apology.

This is just a short note to let you know that after installing 3.8.3, display
port stopped working on my laptop. Going back to 3.8.2 brought it back to life.
This has been tested with the ubuntu mainline kernels that should be vanilla
stable kernels. Hope this is not an incorrect report due to something wrong on
their side. Laptop is a DELL E6500 with intel gen4 integrated graphics (Intel
Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)).
With 3.8.3, xrandr does not report anymore the external monitor when it is
actually attached via displayport.

Thanks for the attention and best regards,

Sergio Callegari


2013-03-18 15:59:45

by Bjørn Mork

[permalink] [raw]
Subject: Re: Stable kernel 3.8.3 appears to break displayport on intel gen4

Sergio Callegari <[email protected]> writes:

> This is just a short note to let you know that after installing 3.8.3,
> display port stopped working on my laptop. Going back to 3.8.2 brought
> it back to life.
> This has been tested with the ubuntu mainline kernels that should be
> vanilla stable kernels. Hope this is not an incorrect report due to
> something wrong on their side. Laptop is a DELL E6500 with intel gen4
> integrated graphics (Intel Corporation Mobile 4 Series Chipset
> Integrated Graphics Controller (rev 07)).
> With 3.8.3, xrandr does not report anymore the external monitor when
> it is actually attached via displayport.

I can confirm seeing this bug on:

# lspci -nnvvvs 00:02.0
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device [17aa:20e4]
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 45
Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 1800 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4152
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915



Looking through the changes from v3.8.2 to v3.8.3, there weren't really
that many suspects. This partial (to avoid having to change any
following patches) revert of commit 2a98104 ("drm/i915: reorder setup
sequence to have irqs for output setup") fixes the problem for me. I
have no idea why, so I leave it to Daniel and the other wise men working
on this driver to explain and cleanup :)


---
drivers/gpu/drm/i915/i915_dma.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5206f24..b15b65d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1297,21 +1297,19 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_vga_switcheroo;

- ret = drm_irq_install(dev);
- if (ret)
- goto cleanup_gem_stolen;
-
- /* Important: The output setup functions called by modeset_init need
- * working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);

ret = i915_gem_init(dev);
if (ret)
- goto cleanup_irq;
+ goto cleanup_gem_stolen;
+
+ intel_modeset_gem_init(dev);

INIT_WORK(&dev_priv->console_resume_work, intel_console_resume);

- intel_modeset_gem_init(dev);
+ ret = drm_irq_install(dev);
+ if (ret)
+ goto cleanup_gem;

/* Always safe in the mode setting case. */
/* FIXME: do pre/post-mode set stuff in core KMS code */

2013-03-18 19:21:42

by Daniel Vetter

[permalink] [raw]
Subject: Re: Stable kernel 3.8.3 appears to break displayport on intel gen4

On Mon, Mar 18, 2013 at 04:59:35PM +0100, Bj?rn Mork wrote:
> Sergio Callegari <[email protected]> writes:
>
> > This is just a short note to let you know that after installing 3.8.3,
> > display port stopped working on my laptop. Going back to 3.8.2 brought
> > it back to life.
> > This has been tested with the ubuntu mainline kernels that should be
> > vanilla stable kernels. Hope this is not an incorrect report due to
> > something wrong on their side. Laptop is a DELL E6500 with intel gen4
> > integrated graphics (Intel Corporation Mobile 4 Series Chipset
> > Integrated Graphics Controller (rev 07)).
> > With 3.8.3, xrandr does not report anymore the external monitor when
> > it is actually attached via displayport.
>
> I can confirm seeing this bug on:
>
> # lspci -nnvvvs 00:02.0
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller])
> Subsystem: Lenovo Device [17aa:20e4]
> 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 45
> Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
> Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
> Region 4: I/O ports at 1800 [size=8]
> Expansion ROM at <unassigned> [disabled]
> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> Address: fee0300c Data: 4152
> Capabilities: [d0] Power Management version 3
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Kernel driver in use: i915
>
>
>
> Looking through the changes from v3.8.2 to v3.8.3, there weren't really
> that many suspects. This partial (to avoid having to change any
> following patches) revert of commit 2a98104 ("drm/i915: reorder setup
> sequence to have irqs for output setup") fixes the problem for me. I
> have no idea why, so I leave it to Daniel and the other wise men working
> on this driver to explain and cleanup :)

Already taken care of hopefully:

http://lists.freedesktop.org/archives/intel-gfx/2013-March/025767.html

My apologies to everyone who's suffering through this breakage, it looks
like I've managed to serious burn myself with an innocent looking stable
backport :(

Yours, Daniel

>
>
> ---
> drivers/gpu/drm/i915/i915_dma.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 5206f24..b15b65d 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1297,21 +1297,19 @@ static int i915_load_modeset_init(struct drm_device *dev)
> if (ret)
> goto cleanup_vga_switcheroo;
>
> - ret = drm_irq_install(dev);
> - if (ret)
> - goto cleanup_gem_stolen;
> -
> - /* Important: The output setup functions called by modeset_init need
> - * working irqs for e.g. gmbus and dp aux transfers. */
> intel_modeset_init(dev);
>
> ret = i915_gem_init(dev);
> if (ret)
> - goto cleanup_irq;
> + goto cleanup_gem_stolen;
> +
> + intel_modeset_gem_init(dev);
>
> INIT_WORK(&dev_priv->console_resume_work, intel_console_resume);
>
> - intel_modeset_gem_init(dev);
> + ret = drm_irq_install(dev);
> + if (ret)
> + goto cleanup_gem;
>
> /* Always safe in the mode setting case. */
> /* FIXME: do pre/post-mode set stuff in core KMS code */
>
>

--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch