Bug 52361

Please attach full dmesg from boot to trying to connect the monitor, with drm.debug=0xe module parameter, preferrably running 3.8.0-rc2.

Created attachment 90781 [details]
dmesg of working 3.5.4 kernel

Created attachment 90791 [details]
dmesg of not working display on 3.8.0-rc2 kernel

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.

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.

Created attachment 90881 [details]
reg_dump-3.5.4

Created attachment 90891 [details]
reg_dump-3.8.0-rc2

Created attachment 90901 [details]
xrandr-3.5.4

Created attachment 90911 [details]
xrandr-3.8.0-rc2

The info you asked for are now attached.
I hope they are sufficient.

Created attachment 90931 [details]
fixup hdmi hotplug definitions

Please test this patch.

Created attachment 90991 [details]
dmesg patched

Created attachment 91001 [details]
reg_dump patched

Created attachment 91011 [details]
xrandr patched

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.

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

The regression was introduced in 3.6.0.
3.5.7 is working fine.

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.

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.

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

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.

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

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.

Commit eeafaaca763408c099d2ade3a69e0716f296a97b is still bad.

Any news yet?

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

Yes, eeafaaca763408c099d2ade3a69e0716f296a97b with the patch is indeed working.

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.

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)

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.

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.

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.

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?

Just apply it on top of drm-intel-next - we've merged a few #defines just yesterday.

Created attachment 92671 [details]
dmesg drm-intel-next

Created attachment 92681 [details]
dmesg drm-intel-next reverted

Norman, so do these two behave differently?

No, these are both working.

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?

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

v3.9-rc1 is indeed detecting the external monitor, but video performance is unusable sluggish. Even mouse movement triggers signifficant lag.

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.