Regression: Borked display on second output with Intel G45 in 3.0-rc2

After upgrading to 3.0-rc2, my second display is no longer working correctly on a desktop with an Intel G45 graphics chip. The system has two displays, one connected by HDMI and the other by VGA.

Both displays work fine in the console; the troubles begin after starting X. It *looks* as if one of the displays is still scanning out from the old framebuffer: what I see on the VGA monitor after starting X is a black screen with a console cursor at the top -- this is just like an empty VT except that the cursor is not blinking. If I switch to VT 1 and then back to X, the display contains all the bootup text that was on VT 1. In any case, the mouse cursor works properly on the display. There are no unusual messages in dmesg or the Xorg log in any case.

If I fiddle around with the xrandr tool (e.g. do an xrandr --output VGA1 --same-as HDMI1 && xrandr --output VGA1 --right-of VGA1) , it's possible to get both displays showing the right thing. But then if I switch back to the console, I end up with one display showing the console text and the other is still showing my X session! (In this instance, the VGA was working and the HDMI was showing the wrong thing).

This is a regression from 2.6.39, but that's not the whole story: this problem appears to have been introduced very briefly late in the 2.6.39 -rc cycle and subsequently fixed on mainline. It then reappeared during the 3.0 merge window. Unfortunately, this fact seems to make it impossible to bisect to a specific commit.

What I do know is that the problem was originally introduced by 49183b2818de ("drm/i915: Only enable the plane after setting the fb base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert "drm/i915: Only enable the plane after setting the fb base (pre-ILK)""). The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
Unfortunately, I cannot be more specific than that because it appears that the entire drm side of that merge consists of 'bad' commits and git bisect gets very confused.

Let me know if you need any more info,

Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

* Nick Bowler -- Monday 06 June 2011:

[...]

That's apparently the bug that I've submitted a patch for on 2011/5/31:
https://lkml.org/lkml/2011/5/31/393
I assume/hope it's still in someone's queue.

m.

Yup, that fixes it right up, thanks.

Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Yeah, we "shouldn't" need to call intel_enable_plane from i9xx_crtc_mode_set as it is called immediately afterwards from i9xx_crtc_enable.

In any case, there's a bogus call in ironlake_crtc_mode_set which clearly belongs in i9xx_crtc_mode_set:

index 81a9059..aa43e7b 100644
@@ -4687,6 +4687,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
 
 	I915_WRITE(DSPCNTR(plane), dspcntr);
 	POSTING_READ(DSPCNTR(plane));
+	intel_enable_plane(dev_priv, plane, pipe);
 
 	ret = intel_pipe_set_base(crtc, x, y, old_fb);
 

@@ -5217,8 +5218,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 
 	I915_WRITE(DSPCNTR(plane), dspcntr);
 	POSTING_READ(DSPCNTR(plane));
-	if (!HAS_PCH_SPLIT(dev))
-		intel_enable_plane(dev_priv, plane, pipe);
 
 	ret = intel_pipe_set_base(crtc, x, y, old_fb);
 

We need to figure out why this call (in i9xx_crtc_mode_set) is required, but that will require finding hardware that reproduces the bug and fixing it there.

[email protected]

_______________________________________________
dri-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dri-devel