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.
Created attachment 46475 [details] dmesg (May 8 - drm.debug=0xe, kernel 2.6.39-rc6)
Created attachment 46476 [details] Xorg.0.log (May 8)
Created attachment 46477 [details] dmesg (March 4 - drm.debug=0xe, kernel 2.6.38-rc6)
Created attachment 46478 [details] Xorg.0.log (March 4)
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?
Whilst i2c on this machine is dysfunctional we will never be able to query outputs. Did you try a BIOS update?
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.