Bug 36662 - Intel GM45: Low resolution on external screen.
Intel GM45: Low resolution on external screen.
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel)
x86-64 Linux
: P1 normal
Assigned To: drivers_video-dri-intel@kernel-bugs.osdl.org
:
Depends on:
Blocks: 32012
  Show dependency treegraph
 
Reported: 2011-06-04 17:37 UTC by Alex Ferrando
Modified: 2011-07-04 08:47 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.39, 2.6.39.1
Tree: Mainline
Regression: Yes


Attachments
dmesg output (the problem mentioned on the report is at the end of the file) (49.20 KB, text/plain)
2011-06-04 17:37 UTC, Alex Ferrando
Details
Log of bisections (5.30 KB, application/octet-stream)
2011-06-30 00:01 UTC, Alex Ferrando
Details

Description Alex Ferrando 2011-06-04 17:37:00 UTC
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.
Comment 1 Florian Mickler 2011-06-26 15:20:27 UTC
Can you pinpoint the commit that broke the EDID retrieval via git-bisect?
Comment 2 Alex Ferrando 2011-06-26 23:29:05 UTC
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
Comment 3 Alex Ferrando 2011-06-30 00:01:57 UTC
Created attachment 63912 [details]
Log of bisections
Comment 4 Alex Ferrando 2011-06-30 00:04:45 UTC
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.
Comment 5 Florian Mickler 2011-06-30 08:49:23 UTC
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.
Comment 6 Florian Mickler 2011-07-03 11:20:00 UTC
Is this still a problem in v3.0-rc4 or later?
Comment 7 Alex Ferrando 2011-07-03 18:52:28 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.