(re-adding Ben to the Cc because he was apparently dropped somewhere in this thread)
On 2012-05-01 09:23 -0400, Nick Bowler wrote:
On 2012-04-30 11:07 +0200, Maarten Maathuis wrote:
On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov dmitry.torokhov@gmail.com wrote:
On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
On 2012-04-28 02:19 -0400, Alex Deucher wrote:
On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler nbowler@elliptictech.com wrote:
While tracking down the black screen issue, I've been having the monitor directly connected to the video card the whole time, but now when I'm connected through my KVM switch (an IOGear GCS1804), it appears that something's going wrong with reading the EDID, because the available modes are all screwed up (both console and X decide they want to drive the display at 1024x768).
[...]
Also, looking at /sys/class/drm/card0-VGA-1/edid I see that it is empty on 3.4-rc4+ and it is correct on 3.2.15. Things seem to work OK when the KVM is not involved.
Were you ever able to fetch a EDID with the KVM involved? KVMs are notorious for not connecting the ddc pins.
Yes, it works on 3.2.15 as described above.
I have the same (or similar) KVM (not in the office at the moment) and I can confirm that with newer kernels EDID fecthing in flaky. It's 50/50 if EDED retrieval succeeds or if it fails with:
Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 208
[...]
Earlier kernels were able to retrieve EDEDs reliably.
FWIW, for me EDID failure on new kernels is 100% reproducible, and there are no such checksum errors in the log. It's just missing.
Just a crazy thought, but didn't we change some timings related to EDID retrieval? To make it faster.
OK, this time bisecting started off relatively smoothly (doing the same "backwards" bisect on the branch-o-reverts as last time), but then my disk died halfway through...
[...]
OK, system is back online and I finished the bisection. The commit that broke it for me is the following, and reverting it on top of 3.3.4 + the "make VGA work at all" patch fixes this particular issue for me.
commit f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d Author: Ben Skeggs bskeggs@redhat.com Date: Wed Dec 21 18:09:12 2011 +1000
drm/nouveau/i2c: handle bit-banging ourselves
i2c-algo-bit doesn't actually work very well on one card I have access to (NVS 300), random single-bit errors occur most of the time - what we're doing now is closer to what xf86i2c.c does.
The original plan was to figure out why i2c-algo-bit fails on the NVS 300, and fix it. However, while investigating I discovered i2c-algo-bit calls cond_resched(), which makes it a bad idea for us to be using as we execute VBIOS scripts from a tasklet, and there may very well be i2c transfers as a result.
So, since I already wrote this code in userspace to track down the NVS 300 bug, and it's not really much code - lets use it.
Signed-off-by: Ben Skeggs bskeggs@redhat.com
Cheers,