Bug 39108

The laptop is a popular HP EliteBook 2540p got from the Intel IT, it shouldn't be hard to found.

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.

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?

(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.

*** Bug 39161 has been marked as a duplicate of this bug. ***

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?

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.

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

(Applies to xf86-video-intel.git)

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.

Yeah, we do have to revert that in userspace for the time being as don't yet have a fix for the kernel.

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 ***

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...