Bug 675212

Summary: EDID info missing after re-connecting monitor
Product: [Fedora] Fedora Reporter: David Juran <djuran>
Component: xorg-x11-drv-nouveauAssignee: Ben Skeggs <bskeggs>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: airlied, ajax, bskeggs, gansalmon, itamar, jcm, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-06 06:33:40 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Xorg.log none

Description David Juran 2011-02-04 11:19:13 EST
Description of problem:
Taking part in the Test day for Gnome3, I noticed that when I re-connect my old  SUN  Model: 577 CRT, the kernel doesn't seem to get any EDID info from it. DO note that on boot-up, everything worked fine and EDID was (apparently) received. But after disconnecting and re-connecting the screen, the following messages appeared in syslog:

Feb  4 16:14:03 localhost kernel: [ 8485.113141] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 161
Feb  4 16:14:03 localhost kernel: [ 8485.113147] [drm:drm_edid_block_valid] *ERROR* Raw EDID:
Feb  4 16:14:03 localhost kernel: [ 8485.113173] 
Feb  4 16:14:03 localhost kernel: [ 8485.211911] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 161
Feb  4 16:14:03 localhost kernel: [ 8485.211914] [drm:drm_edid_block_valid] *ERROR* Raw EDID:
Feb  4 16:14:03 localhost kernel: [ 8485.211938] 
Feb  4 16:14:03 localhost kernel: [ 8485.310699] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 161
Feb  4 16:14:03 localhost kernel: [ 8485.310702] [drm:drm_edid_block_valid] *ERROR* Raw EDID:
Feb  4 16:14:03 localhost kernel: [ 8485.310725] 
Feb  4 16:14:03 localhost kernel: [ 8485.409490] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 161
Feb  4 16:14:03 localhost kernel: [ 8485.409493] [drm:drm_edid_block_valid] *ERROR* Raw EDID:
Feb  4 16:14:03 localhost kernel: [ 8485.409517] 
Feb  4 16:14:03 localhost kernel: [ 8485.409521] nouveau 0000:01:00.0: DVI-I-1: EDID block 0 invalid.
Feb  4 16:14:03 localhost kernel: [ 8485.409525] [drm] nouveau 0000:01:00.0: DDC responded, but no EDID for DVI-I-1
Feb  4 16:14:03 localhost kernel: [ 8485.422020] [drm] nouveau 0000:01:00.0: Load detected on output A

and xrandr doesn't report any mode higher then 1024x768



Version-Release number of selected component (if applicable):
kernel-2.6.38-0.rc3.git0.1.fc15.x86_64
xorg-x11-server-Xorg-1.9.99.1-3.20101201.fc15.x86_64
xorg-x11-drv-nouveau-0.0.16-17.20110117git38e8809.fc15.x86_64
xorg-x11-server-utils-7.5-3.fc15.x86_64

Steps to Reproduce:
1. Unplug your old CRT running nicely at 1600x1200
2. plug it back in again
3. Run xrand
4. Note how it doesn't annoucne any mode above 1024x768

Additional info:
Attaching Xorg.log
Comment 1 David Juran 2011-02-04 11:19:58 EST
Created attachment 477056 [details]
Xorg.log
Comment 2 David Juran 2011-02-06 06:33:40 EST
Uhm, on closer inspection it seems that the un-plugging and re-plugging the screen actually was the straw that broke the camels back. Don't ask me why, but the screen now doesn't send any EDID no matter what you plug it in to. Oh well, guess it's time to give in and get a TFT...
Comment 3 Ben Skeggs 2011-02-06 18:45:03 EST
It might be worth trying to completely remove power from the monitor for a while (unplug from mains, *and* the graphics card), and seeing if DDC comes back.
Comment 4 David Juran 2011-02-17 13:18:49 EST
Nope, that didn't help, seems the era of the CRT is truly over for me... <sniff>
Comment 5 Jon Masters 2011-02-22 23:36:25 EST
It's worth adding that a lot of monitors send/receive EDID info without even needing a powered monitor, since the I2C chip in the monitor is powered by the host PC. Therefore, IMO you might just be SOL.