Created attachment 60792 [details] dmesg output (the problem mentioned on the report is at the end of the file) What I'm going to describe did not happened on 2.6.38.x . I apologize if the bug report is incomplete and being my first time doing this can make that I have forgot to add some log. If that's the case, please, tell me. Something more to be said before the report itself: I'm using Kernel Mode Setting as I did on 2.6.38. Nothing else changes between 2.6.38.8 and 2.6.39 as I currently have both installed. Since the upgrade from kernel 2.6.38.8 to 2.6.39 and 2.6.39.1, whenever I plug my external VGA monitor to the laptop even if I do not set it tot be used, the messages log gets spammed with fragments like this: drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 [drm:drm_edid_block_valid] *ERROR* Raw EDID: <3>00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ Also, the resolution at which I can set the screen has been redoced from 1280x1024 to 1024x768. I can force it to work at 1280x1024 using xrandr to add a new mode but whenever I do this, the screen gets moved to the left, leaving a black vertical artifact at the right of the VGA screen. The area covered by that black artifact gets ignored as if it would not exist, and since I use the VGA screen at the left of the LVDS screen of the laptop, that black zone is trated as if the screen ended there, making the mouse or any window to appear on the LVDS screen. Aside from the external screen problem, everything else seems to work and no X or kernel crashes have been suffered.
Can you pinpoint the commit that broke the EDID retrieval via git-bisect?
I'm on it, but it will take some time as in the worst case 13 bisects are expected to be needed. I will report something as soon as I get that commit
Created attachment 63912 [details] Log of bisections
After loosing half day building kernel bisections with nearly the same config I use on my working kernel and having a ratio of 10 skips per 1 successfully build thanks to xen and binutils, I disabled xen and started bisecting from the beginning. First time doing this, and something that makes me curious about it is the date of the pointed as bad first commit: 8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f is the first bad commit commit 8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Feb 1 09:01:13 2011 +0000 drm/i915: Enable GMBUS for post-gen2 chipsets With the recent SDVO fix, this is working on all the machines I have to hand - except for an 845G. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> :040000 040000 eb835ca9bf353d1d548b69d415801720a577184a 3e0a9430c43030735dfe2f694a1ad694cc01d483 Mdrivers I've used the stable git tree and something that I don't know if it's normal or not but I'm going to say in case it's not and I have done something wrong, is that that commit happens on 2.6.38-rc2 or so does git say. Also, on some bisections git has jumped back to 2.6.37. I really hope nothing I have done is wrong, but I won't discard that it might be. In case there is something that neets to be done again because I did id wrong, just tell it.
No those old version tags are to be expected. git can only tell you what version a commit is _based_ upon[*]. People develop based upon older kernels (naturally, because the newer kernel doesn't exist yet) and that get's integrated into a new version. So that is why bisect gives you the wildest versions. It's just the ingredients to 2.6.39 that you are testing. That commit you found, has already been reverted in v3.0-rc4: commit 826c7e4147f902737b281e8a5a7d7aa33fd63316 Author: Jean Delvare <khali@linux-fr.org> Date: Sat Jun 4 19:34:56 2011 +0000 Revert "drm/i915: Enable GMBUS for post-gen2 chipsets" But I'm not shure it's on its way to the stable kernels though... Keith? Regards, Flo [*]: well, it can also tell you where a commit is included, but that is a costly search, try: git tag --contains 8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f which will output all tags that contain the commit.
Is this still a problem in v3.0-rc4 or later?
I've done two tests in the past few days: - 2.6.39 reverting the commit that git pointed out. No more resolution problems ore dmesg output about wrong remainder. - 3.0-rc5. Same as above. No issues with the resolution or the dmesg output.