Bug 37010

Summary: No screens found on Intel DH67CL(B3)/i7-2600K system
Product: DRI Reporter: Robert Kaiser <kairo>
Component: DRM/IntelAssignee: Daniel Vetter <daniel>
Status: CLOSED WORKSFORME QA Contact:
Severity: normal    
Priority: medium CC: ben, chris, daniel, jbarnes
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg (May 8 - drm.debug=0xe, kernel 2.6.39-rc6)
none
Xorg.0.log (May 8)
none
dmesg (March 4 - drm.debug=0xe, kernel 2.6.38-rc6)
none
Xorg.0.log (March 4) none

Description Robert Kaiser 2011-05-09 05:01:53 UTC 
I was enthusiastic about a completely open graphics stack and so bought an Intel DH67CL mainboard (meanwhile swapped for a DH67CLB3) and an i7-2600K CPU.

The problem is that now I need to run it with nomodeset=1 and therefore vesafb because the intel drivers tell me they don't find a screen attached, though there are in fact two monitors connected, one on the normal DVI port, one on the HDMI port with an HDMI-to-DVI cable. (On the BIOS and vesafb, interestingly, only the newer of the two gets a signal, even if I swap the cables between them - but at least that one gets a signal with those variants.)

I have tested this with two mainboards now (due to the mentioned swap) and with kernels 2.6.37, 2.6.38 and now 2.6.39-rc6 and I'm seeing the same everywhere. BIOS and the very start of kernel boot are visible on the screen, once it activates the intel driver, everything goes blank, the monitor telling it has no signal.

I posted about this on March 4th on intel-gfx, and Chris Wilson pinpointed where the problem is coming in but without an idea why this is happening:
------------------------------------------------------------------------
This is the cause of the trouble:

[    3.042320] i915 GPIOB: SDA stuck high!
[    3.045553] i915 GPIOA: SDA stuck low!
[    3.045625] i915 GPIOC: SDA stuck high!
[    3.049540] i915 GPIOD: SDA stuck low!
[    3.049612] i915 GPIOE: SDA stuck high!
[    3.049694] i915 GPIOF: SDA stuck high!

First time I've ever seen that, though that is maybe because it is in a
non-default debugging path.

However, failing the i2c bitbanging adapter being created, we would be
using the GMBUS interface. That appears to be failing as well. (Not too
surprising since it uses the same ports internally.)

Not sure how to proceed, maybe someone else has a better idea?
-Chris
------------------------------------------------------------------------

No further replies happened - but of course, may problem persists.
I'll attach dmesg (with drm.debug=0xe) and Xorg.0.log from both now and back then in case further looks into them are helpful.
Comment 1 Robert Kaiser 2011-05-09 05:06:27 UTC 
Created attachment 46475 [details]
dmesg (May 8 - drm.debug=0xe, kernel 2.6.39-rc6)
Comment 2 Robert Kaiser 2011-05-09 05:08:38 UTC 
Created attachment 46476 [details]
Xorg.0.log (May 8)
Comment 3 Robert Kaiser 2011-05-09 05:10:09 UTC 
Created attachment 46477 [details]
dmesg (March 4 - drm.debug=0xe, kernel 2.6.38-rc6)
Comment 4 Robert Kaiser 2011-05-09 05:10:46 UTC 
Created attachment 46478 [details]
Xorg.0.log (March 4)
Comment 5 Robert Kaiser 2011-06-02 05:59:08 UTC 
Hmm, now I completely unplugged the HDMI-to-DVI cable and plugged in the monitor via the DVI port, and now everything seems to work on a single screen.

Could that error be a cable problem (which still would sound somewhat questionable given that vesafb worked fine over that cable) or some signature inherent to a HDMI-to-DVI connector?
Comment 6 Chris Wilson 2012-04-24 09:14:56 UTC 
Whilst i2c on this machine is dysfunctional we will never be able to query outputs. Did you try a BIOS update?
Comment 7 Robert Kaiser 2012-04-24 10:57:43 UTC 
Actually, I completely forgot that this bug is still around here.

A few weeks back, not sure if still on a 3.2 or already on a 3.3-rc kernel, I tried this again after a long time, and now both screens work fine in a dual screen setup.

I'll close this as WFM, thanks for checking back!

(It was not a BIOS update that fixed it as I did none since then, most likely a kernel fix somewhere, but the road from 2.6.39 to 3.2 or even 3.3 surely had a lot of those.)

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.