Bug 52361 - [G4x] External Monitor is not detected
Summary: [G4x] External Monitor is not detected
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jani Nikula
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-05 19:56 UTC by Norman Rieß
Modified: 2013-03-11 18:55 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.6.0 - 3.8.0-rc2
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
dmesg of working 3.5.4 kernel (161.38 KB, text/plain)
2013-01-08 17:01 UTC, Norman Rieß
Details
dmesg of not working display on 3.8.0-rc2 kernel (133.57 KB, text/plain)
2013-01-08 17:07 UTC, Norman Rieß
Details
reg_dump-3.5.4 (13.58 KB, text/plain)
2013-01-09 17:35 UTC, Norman Rieß
Details
reg_dump-3.8.0-rc2 (13.53 KB, text/plain)
2013-01-09 17:36 UTC, Norman Rieß
Details
xrandr-3.5.4 (7.75 KB, text/plain)
2013-01-09 17:36 UTC, Norman Rieß
Details
xrandr-3.8.0-rc2 (3.63 KB, text/plain)
2013-01-09 17:37 UTC, Norman Rieß
Details
fixup hdmi hotplug definitions (1.17 KB, patch)
2013-01-09 20:20 UTC, Daniel Vetter
Details | Diff
dmesg patched (137.27 KB, text/plain)
2013-01-10 16:46 UTC, Norman Rieß
Details
reg_dump patched (13.53 KB, text/plain)
2013-01-10 16:46 UTC, Norman Rieß
Details
xrandr patched (3.63 KB, text/plain)
2013-01-10 16:47 UTC, Norman Rieß
Details
dmesg drm-intel-next (124.49 KB, text/plain)
2013-02-08 13:07 UTC, Norman Rieß
Details
dmesg drm-intel-next reverted (125.10 KB, text/plain)
2013-02-08 13:08 UTC, Norman Rieß
Details

Description Norman Rieß 2013-01-05 19:56:48 UTC
An external monitor is connected via an DVI to DP Adapter to the Display Port.
Till kernel 3.5.4 the external monitor is detected and works as expected.
On kernel 3.6.0 - 3.8.0-rc2 the monitor is not responding on startup nor is it detected on xrandr. Monitor say "no signal" and goes to stand by.

Following Controller is used. Machine is a Lenovo x301.

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
	Subsystem: Lenovo Device 20e4
	Flags: bus master, fast devsel, latency 0, IRQ 42
	Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 1800 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 3
	Kernel driver in use: i915

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
	Subsystem: Lenovo Device 20e4
	Flags: bus master, fast devsel, latency 0
	Memory at f0400000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [d0] Power Management version 3
Comment 1 Jani Nikula 2013-01-07 12:44:33 UTC
Please attach full dmesg from boot to trying to connect the monitor, with drm.debug=0xe module parameter, preferrably running 3.8.0-rc2.
Comment 2 Norman Rieß 2013-01-08 17:01:40 UTC
Created attachment 90781 [details]
dmesg of working 3.5.4 kernel
Comment 3 Norman Rieß 2013-01-08 17:07:19 UTC
Created attachment 90791 [details]
dmesg of not working display on 3.8.0-rc2 kernel
Comment 4 Norman Rieß 2013-01-08 17:09:46 UTC
I attached the dmesg output.
The output of 3.8.0-rc2 kernel also contains a disconnection and connection of the DP cable after the complete boot.
Comment 5 Daniel Vetter 2013-01-08 18:42:44 UTC
Since you're using a passive dp->dvi dongle we're using the hdmi encoder, so it's no the dp dithering gone wrong. Logs also don't suggest any other issues.

Can you please grab the latest git of

http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

and attach the output of intel_reg_dump from both a good and a broken kernel? Please make sure that you have the same xrandr configuration (also check crtcs with xrandr --verbose) for otherwise comparing the register dumps will be a pain.
Comment 6 Norman Rieß 2013-01-09 17:35:29 UTC
Created attachment 90881 [details]
reg_dump-3.5.4
Comment 7 Norman Rieß 2013-01-09 17:36:07 UTC
Created attachment 90891 [details]
reg_dump-3.8.0-rc2
Comment 8 Norman Rieß 2013-01-09 17:36:33 UTC
Created attachment 90901 [details]
xrandr-3.5.4
Comment 9 Norman Rieß 2013-01-09 17:37:02 UTC
Created attachment 90911 [details]
xrandr-3.8.0-rc2
Comment 10 Norman Rieß 2013-01-09 17:38:07 UTC
The info you asked for are now attached.
I hope they are sufficient.
Comment 11 Daniel Vetter 2013-01-09 20:20:15 UTC
Created attachment 90931 [details]
fixup hdmi hotplug definitions

Please test this patch.
Comment 12 Norman Rieß 2013-01-10 16:46:19 UTC
Created attachment 90991 [details]
dmesg patched
Comment 13 Norman Rieß 2013-01-10 16:46:59 UTC
Created attachment 91001 [details]
reg_dump patched
Comment 14 Norman Rieß 2013-01-10 16:47:26 UTC
Created attachment 91011 [details]
xrandr patched
Comment 15 Norman Rieß 2013-01-10 16:48:53 UTC
I applied the patch, but i am affraid that nothing has changed, as far as i can see.
I attached all information for 3.8.0-rc2_patched.
Comment 16 Daniel Vetter 2013-01-10 16:59:49 UTC
(In reply to comment #15)
> I applied the patch, but i am affraid that nothing has changed, as far as i
> can
> see.
> I attached all information for 3.8.0-rc2_patched.

Well, some things changed, the kernel now tries to read the EDID, but fails at that step ... which still suggests that I'm completely missing what's amiss.

Can you try to bisect where this regression has been introduced?
Comment 17 Norman Rieß 2013-01-11 06:34:04 UTC
The regression was introduced in 3.6.0.
3.5.7 is working fine.
Comment 18 Daniel Vetter 2013-01-11 08:25:09 UTC
Can you please attempt a git bisect to figure out where the breakage between 3.5 and 3.6 has been introduced? http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ is my preferred howto.
Comment 19 Norman Rieß 2013-01-11 08:50:03 UTC
Ah sorry, i misunderstood what was ment by bisect.
Is there a way of telling if the monitor is working without sitting in front of it? I have network access to the machine, but i do not see the display right now.
Comment 20 Daniel Vetter 2013-01-11 13:34:08 UTC
(In reply to comment #19)
> Ah sorry, i misunderstood what was ment by bisect.
> Is there a way of telling if the monitor is working without sitting in front
> of
> it? I have network access to the machine, but i do not see the display right
> now.

Networked webcam would work, but everything else is highly unreliable. So you really need to check somehow whether something shows up on screen and whether it looks right.
Comment 21 Norman Rieß 2013-01-11 13:38:08 UTC
Networked webcam is not in line of sight of the screen unfortunately.
I am doing a dmesg | HDMI right now to test the result.
Will double check when i am back in the room.
Comment 22 Norman Rieß 2013-01-12 09:26:55 UTC
8ec22b214d76773c9d89f4040505ce10f677ed9a is the first bad commit
commit 8ec22b214d76773c9d89f4040505ce10f677ed9a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri May 11 18:01:34 2012 +0100

    drm/i915/hdmi: Query the live connector status bit for G4x
    
    Similar to g4x_dp_detect() we should probe the PORT_HOTPLUG_STATUS as to
    whether the connector is active prior to attempting to retrieve the EDID.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

:040000 040000 0eb62d5d7c32c940a5ce2e06f9f8f21f04b0c1e5 fe4526c389923ef8a47ef60ef41f16ee034709c5 M	drivers
Comment 23 Jani Nikula 2013-01-14 11:07:04 UTC
Norman, the bisected bad commit was indeed bad, and was fixed shortly after with:

commit eeafaaca763408c099d2ade3a69e0716f296a97b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri May 25 10:23:37 2012 +0100

    drm/i915/hdmi: Fix reg values for g4x_hdmi_connected

This is like 8 commits after your bisected bad commit. We want to make sure we have the right culprit here. Please test this commit as well.

If eeafaaca is good, we have bad commits 8ec22b21..eeafaaca that you should exclude from your bisect. You can replay your bisect log apart from anything between those commits, i.e. you should skip commits between 8ec22b21..eeafaaca^ inclusive.

If eeafaaca is bad, please just report that. Thanks.
Comment 24 Norman Rieß 2013-01-14 12:15:39 UTC
Commit eeafaaca763408c099d2ade3a69e0716f296a97b is still bad.
Comment 25 Norman Rieß 2013-01-30 11:35:20 UTC
Any news yet?
Comment 26 Daniel Vetter 2013-02-06 10:40:03 UTC
Can you please retest eeafaaca763408c099d2ade3a69e0716f296a97b with https://bugzilla.kernel.org/attachment.cgi?id=90931 applied on top?

It looks like there's a bunch of issues intermingled for your box, so we need to figure out what's going on exactly :(
Comment 27 Norman Rieß 2013-02-07 08:09:24 UTC
Yes, eeafaaca763408c099d2ade3a69e0716f296a97b with the patch is indeed working.
Comment 28 Daniel Vetter 2013-02-07 09:32:17 UTC
Ok, this will be messy, since now we need to hunt down where the second regression has been introduced.

Can you please bisect between eeafaaca763408c099d2ade3a69e0716f296a97b and 3.8-rc. Please attach the bugfix each time before compiling a kernel, but also remove it again (e.g. git reset --hard) before continuing the bisect. Otherwise git will complain about dirty working directory and not check out the new bisect point for testing.

I'll meanwhile try to figure out whether docs are indeed wrong (or whether there's only something funny going on on your machine) and try to come up with a real patch for inclusion.
Comment 29 Daniel Vetter 2013-02-07 11:41:03 UTC
I think a need a few more things, apparently the register values _are_ right. At least on my machine here ... So a few more things to check:

How many physical outputs does your machine have? Is there a docking station available for it?

Can you please paste the output of

# intel_reg_read 0x61114

from intel-gpu-tools for the following cases:
- nothing connected (use sleep 10 ; intel_reg_read if you have no ssh connection set up)
- just the dvi connection (to all outputs you can find)
- native DP connected (if you have such a screen around)
Comment 30 Norman Rieß 2013-02-07 11:53:12 UTC
Ok, i am bisecting the kernel from remote right now.

There is no docking station available and there is a VGA Port, Display Port and of cause the internal display.
I will gather the other information tonight. But i will not be able to perform the test for native DP, because i have no such device.
Comment 31 Norman Rieß 2013-02-08 07:58:35 UTC
So here is the bisect.

fbfcc4f3a0cf8bbde87646b74241faa8e37426bf is the first bad commit
commit fbfcc4f3a0cf8bbde87646b74241faa8e37426bf
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Oct 22 16:12:18 2012 +0300

    drm/i915/sdvo: restore i2c adapter config on intel_sdvo_init() failures
    
    SDVOB may be multiplexed with HDMIB. If it's not SDVOB, the same i2c
    adapter may be used for HDMIB, with the adjusted config (i.e. with GPIO
    bit-banging instead of gmbus). Restore i2c adapter config before error
    return from intel_sdvo_init(), letting HDMIB enjoy the joys of gmbus.
    
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

:040000 040000 3429618188b3c92f854a3236ccd3214261cad4fd bc3edb9f509ef57efac5a03efb54083cb8245026 M	drivers

I will have to deliver the other data today, as i only just finished the bisect.
Comment 32 Jani Nikula 2013-02-08 09:23:34 UTC
Norman, please pick a recent kernel, such as some 3.8-rc or drm-intel-next-queued branch from http://cgit.freedesktop.org/~danvet/drm-intel/. Then do the following:

1) apply Daniel's patch from comment #26.

2) boot with drm.debug=0xe module parameter, attach dmesg.

3) git revert fbfcc4f3a0cf8bbde87646b74241faa8e37426bf

4) repeat step 2.

This should confirm the bisected culprit, and see the difference in dmesgs to help us get further.
Comment 33 Norman Rieß 2013-02-08 11:43:32 UTC
Daniels patch is not working for latest drm-intel-next-queued branch.

Hunk #1 FAILED at 1664.
1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/i915/i915_reg.h.rej
loki drm-intel # less drivers/gpu/drm/i915/i915_reg.h
loki drm-intel # cat drivers/gpu/drm/i915/i915_reg.h.rej
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1664,9 +1664,9 @@
 #define   DPC_HOTPLUG_INT_STATUS		(3 << 19)
 #define   DPB_HOTPLUG_INT_STATUS		(3 << 17)
 /* HDMI bits are shared with the DP bits */
-#define   HDMIB_HOTPLUG_LIVE_STATUS             (1 << 29)
+#define   HDMID_HOTPLUG_LIVE_STATUS             (1 << 29)
 #define   HDMIC_HOTPLUG_LIVE_STATUS             (1 << 28)
-#define   HDMID_HOTPLUG_LIVE_STATUS             (1 << 27)
+#define   HDMIB_HOTPLUG_LIVE_STATUS             (1 << 27)
 #define   HDMID_HOTPLUG_INT_STATUS		(3 << 21)
 #define   HDMIC_HOTPLUG_INT_STATUS		(3 << 19)
 #define   HDMIB_HOTPLUG_INT_STATUS		(3 << 17)

The lines in question do not exist in the file any more. In HOTPLUG_LIVE_STATUS the HDMI seems to be renamed to PORT.

Shall i proceed without the patch?
Comment 34 Daniel Vetter 2013-02-08 11:50:31 UTC
Just apply it on top of drm-intel-next - we've merged a few #defines just yesterday.
Comment 35 Norman Rieß 2013-02-08 13:07:52 UTC
Created attachment 92671 [details]
dmesg drm-intel-next
Comment 36 Norman Rieß 2013-02-08 13:08:22 UTC
Created attachment 92681 [details]
dmesg drm-intel-next reverted
Comment 37 Jani Nikula 2013-02-08 13:30:20 UTC
Norman, so do these two behave differently?
Comment 38 Norman Rieß 2013-02-08 13:31:46 UTC
No, these are both working.
Comment 39 Daniel Vetter 2013-02-12 12:44:36 UTC
Oh right, drm-intel-next doesn't contain the offending patches. Can you please retest on drm-intel-testing and then proceed with the bisect?
Comment 40 Florian Mickler 2013-03-04 21:26:11 UTC
A patch referencing this bug report has been merged in Linux v3.9-rc1:

commit 202adf4b9f5957b26a1cb97267d78e0edb319c5e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Feb 22 00:53:04 2013 +0100

    drm/i915: Revert hdmi HDP pin checks
Comment 41 Norman Rieß 2013-03-08 18:55:33 UTC
v3.9-rc1 is indeed detecting the external monitor, but video performance is unusable sluggish. Even mouse movement triggers signifficant lag.
Comment 42 Daniel Vetter 2013-03-11 18:55:32 UTC
Thanks for confirming, I'll close this now.

For your new sluggishness bug I think that's a new bug. I'd start with checking with top/vmstat 1 whether there's a process/irq source or something like that which blows through way too much cpu time. Could very well be that it's not i915's fault.

Note You need to log in before you can comment on or make changes to this bug.