Bug 39108 - [Arrandale][Dual Display] Regression: X freezes on start when external monitor connected via dock with 2.6.39 and newer kernels
Summary: [Arrandale][Dual Display] Regression: X freezes on start when external monito...
Status: RESOLVED DUPLICATE of bug 38012
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Jesse Barnes
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 39161 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-10 01:28 UTC by Yan Li
Modified: 2011-08-01 11:10 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
X output (18.26 KB, text/plain)
2011-07-10 01:38 UTC, Yan Li
no flags Details

Description Yan Li 2011-07-10 01:28:22 UTC
Bug description:
When an VGA external monitor is connected to the laptop via the dock, the Xorg freezes during start.

If the external monitor is not connected when the laptop is powered on, Xorg can start correctly. After X starts, I can connect the external monitor and it works fine. So the freeze only occurs during the X start process.

This problem is a regression since 2.6.39. Old 2.6.38 kernel works perfectly fine.

System environment: 
-- chipset: Arrandale Integrated Graphics Controller [8086:0046] (rev 02)
-- system architecture: 64-bit
-- xf86-video-intel: Debian package 2:2.15.0-3
-- xserver: Debian package: 2:1.10.2.902-1
-- mesa: Debian package: libgl1-mesa-dri 7.10.3-3
-- libdrm: Debian libdrm-intel1 2.4.26-1
-- kernel: Debian 3.0.0~rc6-1~experimental.1
-- Linux distribution: Debian unstable
-- Machine or mobo model: HP EliteBook 2540p
-- Display connector: laptop screen: eDP, external monitor: VGA via dock

Reproducing steps:
At the beginning, the laptop is powered off. Connect the external monitor to the dock, put the laptop into the dock, power on the laptop. Watch the kernel boots correctly and progresses to GDM starting X, both laptop panel and external monitor turn black and the machine freezes, an unblinking cursor can be seen at the top left corner of the external monitor.

I can also boot the kernel to runlevel 1 command-line correctly, then I starts the X manually from command-line, it also freezes.
Comment 1 Yan Li 2011-07-10 01:31:30 UTC
The laptop is a popular HP EliteBook 2540p got from the Intel IT, it shouldn't be hard to found.
Comment 2 Yan Li 2011-07-10 01:38:01 UTC
Created attachment 48931 [details]
X output

The machine freezes right after this line:
(II) intel(0): Initializing HW Cursor

Please see the attached X output.

On a correct boot (without an external monitor attached), the steps following would be like:
(II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
(==) intel(0): DPMS enabled
(II) intel(0): Set up textured video
(II) intel(0): direct rendering: DRI2 Enabled
(==) intel(0): hotplug detection: "enabled"
...

There's no interesting message in dmesg when the machine freezes.
Comment 3 Chris Wilson 2011-07-10 02:41:27 UTC
Jesse, just in case it is machine specific issue, I believe you have an EliteBook 2540p.

Sounds very peculiar. Can you enable mutex debuging (under kernel hacking) [and a bunch of other checks, like the hung task] and see if that gives a hit?
Comment 4 Yan Li 2011-07-10 16:47:47 UTC
(In reply to comment #3)
> Sounds very peculiar. Can you enable mutex debuging (under kernel hacking) [and
> a bunch of other checks, like the hung task] and see if that gives a hit?

Will try. Also will take a bisect between 2.6.38 and 2.6.38 if I can find some more free time.
Comment 5 Chris Wilson 2011-07-12 01:38:02 UTC
*** Bug 39161 has been marked as a duplicate of this bug. ***
Comment 6 Chris Wilson 2011-07-12 01:40:30 UTC
Brice, your machine [eDP+DVI] has a similar hang (although it may be even more severe), are you able to bisect? Or at least narrow down the range of known working kernels?
Comment 7 Brice Goglin 2011-07-12 02:44:04 UTC
I only know that it appeared between .38 and .39-rc4. I'll try to bisect but I won't have access to my dock station very often in the near future so it will take some time.
Comment 8 Chris Wilson 2011-07-12 13:38:55 UTC
There is another Arrandale eDP bug report that correlates a hang with applying GTF modes to the panel, and the workaround for that, or confirmation of, is:


diff --git a/src/intel_display.c b/src/intel_display.c
index e75819d..44e21fb 100644
--- a/src/intel_display.c
+++ b/src/intel_display.c
@@ -693,8 +693,7 @@ intel_crtc_init(ScrnInfoPtr scrn, struct intel_mode *mode, int num)
 static Bool
 is_panel(int type)
 {
-	return (type == DRM_MODE_CONNECTOR_LVDS ||
-	       	type == DRM_MODE_CONNECTOR_eDP);
+	return 0;
 }
 
 static xf86OutputStatus
Comment 9 Chris Wilson 2011-07-12 13:39:17 UTC
(Applies to xf86-video-intel.git)
Comment 10 Yan Li 2011-07-12 19:32:21 UTC
Chris, thanks for the patch. I can confirm that it fixed this bug here (applied to Debian's xserver-xorg-video-intel_2.15.0-3).

I knew it's just a workaround. So shall I recommend it to distro package maintainers or wait for a real fix?

Another thing worries me is that why the kernel is so easily borked by a user-space program. This bug shouldn't have caused machine freeze. There must be something wrong within the kernel that need addressing too.
Comment 11 Chris Wilson 2011-07-13 13:07:49 UTC
Yeah, we do have to revert that in userspace for the time being as don't yet have a fix for the kernel.
Comment 12 Chris Wilson 2011-07-13 13:11:01 UTC
Duping to the older report as that has the bisection, please do double check and reopen if I'm in error.

*** This bug has been marked as a duplicate of bug 38012 ***
Comment 13 Jesse Barnes 2011-08-01 11:10:36 UTC
If it's a non-native panel issue, it may be related to the lut loading fix, which I think is upstream now.  I don't have an HP elitebook to test with though...


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.