Created attachment 367985 [details]
2.6.31.5-96.fc12 dmesg drm.debug=1

Created attachment 367986 [details]
2.6.31.5-96.fc12 Xorg.0.log

Created attachment 367987 [details]
2.6.31.5-96.fc12 messages

Created attachment 367988 [details]
2.6.31.5-97.fc12 dmesg drm.debug=1

Created attachment 367989 [details]
2.6.31.5-97.fc12 Xorg.0.log

Created attachment 367990 [details]
2.6.31.5-97.fc12 messages

adding radeon.modeset=0 to the kernel command line makes Xorg work again.

Created attachment 367991 [details]
2.6.31.5-97.fc12 dmesg radeon.modeset=0

Created attachment 367992 [details]
2.6.31.5-97.fc12.x86_64 Xorg.0.log radeon.modeset=0

Created attachment 367993 [details]
2.6.31.5-97.fc12 Xorg.0.log KMS finding no screens

wow, amazingly this reporter knew just what information to provide ;)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

For some reason, yes :)

In the first post, "black screen" means no console login, not really fully black.
The printks are displayed (if -quiet, obviously) and then the boot messages too.
However, since Xorg does not start, and is supposed to start in VT-1, we don't get a login prompt, so switching to VT-2 is the only way to log in. Confusing for some users it could be.

The only workaround I could find was radeon.modeset=0 so Xorg starts in fail-safe mode (800x600), and then adding the necessary modes via xrandr. I suppose using a xorg.conf would work as well.

Matej, since we have a workaround, even if it's nomodeset, I think Severity should be Medium instead of high.

I'll update the F12 Common Issues document as needed.

You have 2 monitor connected ? Or is the screen connected through DVI ? I guess we need more cleverness in face of  broken EDID like adding safe mode.

All the logs except the last one were generated with the problematic CRT hooked to VGA-0 and a TFT hooked to DVI.

The last log ("2.6.31.5-97.fc12 Xorg.0.log KMS finding no screens") was generated with the CRT only. Xorg completely fails to start at this point, and if the user never removed the quiet boot option, there is only a blinking cursor in VT-1...

To recap:
EDID errors + KMS + quiet boot option => black screen in VT-1, no Xorg
EDID errors + KMS => messages in VT-1 (but no login), no Xorg
EDID errors + nomodeset => Xorg in 800x600

Yes, a safe mode in this case would be better :)

Created attachment 368467 [details]
Add default 800x600 mode when getting wrong EDID

Can you please try if the attached patch which should apply cleanly on top of :
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-next branch, fix your issue ?

*** Bug 522288 has been marked as a duplicate of this bug. ***

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

kernel-2.6.31.6-142.fc12 in koji should contain this fix please give it a try.

*** Bug 538522 has been marked as a duplicate of this bug. ***

*** Bug 537647 has been marked as a duplicate of this bug. ***

tried latest koji kernel (2.6.31.6-149), and  bug #537647 seems fixed. 

However, when booting with KMS enabled, the EDID detects resolution only up to 1024x768  

If booting with KMS disabled, the EDID reports up to 1280x1024 available resolution.

Still, it's a nice improvement and i can live with that.

"However, when booting with KMS enabled, the EDID detects resolution only up to
1024x768"

it is likely actually not reading the EDID correctly and going to fallback resolution, which is 1024x768 in latest kernels. Can you post the logs?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]

"Could you please reply to the previous question? If you won't reply in one
month, I will have to close this bug as INSUFFICIENT_DATA. Thank you."

At the time had some issues with KDE crashing to the login screen when trying to attach logs on bugzilla. So i put this task on the backlog. 
As a status update the monitor I have seems to be failing on the hardware side (occasionally needs some punching to get going) and is soon to be replaced, as such my input on the matter at hand is not relevant and it's counterproductive to do a "quirk" fix for some failing hardware.

Would love to see if the issue is fixed for original "François Cami" bug reporter tho.

Mine (bug 537647) was still broken when I tested it last time. Maybe my EDID is really wrong (it does not work even in Windows) but it works (and always worked) fine without KMS.

This bug is still present in gfx_test_week_20100414_i686.iso:
[drm:edid_is_valid] *ERROR* Raw EDID:
<3>00 ff ff ff ff ff ff 00 26 cd 48 17 51 ac 31 01  ........&.H.Q.1.
<3>0e 0b 01 01 0e 20 18 94 c8 00 b8 a0 57 49 9b 26  ..... ......WI.&
<3>10 48 4c 3f ef 80 31 4a 49 4f a9 40 81 8f 61 59  .HL?..1JIO.@..aY
<3>01 01 01 01 01 01 00 00 00 fe 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 fe 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 fe 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe  ................
<3>0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e1  ................

radeon 0000:01:00.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID

Sorry, one line was missing:
[drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 244
[drm:edid_is_valid] *ERROR* Raw EDID:
<3>00 ff ff ff ff ff ff 00 26 cd 48 17 51 ac 31 01  ........&.H.Q.1.
<3>0e 0b 01 01 0e 20 18 94 c8 00 b8 a0 57 49 9b 26  ..... ......WI.&
<3>10 48 4c 3f ef 80 31 4a 49 4f a9 40 81 8f 61 59  .HL?..1JIO.@..aY
<3>01 01 01 01 01 01 00 00 00 fe 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 fe 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 fe 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe  ................
<3>0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e1  ................

radeon 0000:01:00.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID

FYI, I'm currently experiencing this problem while running Fedora 13 on a machine with a Radeon 9200 video card and a DELL P991 monitor (analog VGA CRT).  I've successfully used this hardware at 1600x1200 resolution @ 75Hz with earlier Fedora releases (most recently Fedora 10), as well as with Windows XP.

dmesg reports:

[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 80
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>50 ff ff ff ff ff ff 00 10 ac 78 51 58 32 30 30  P.........xQX200
<3>1f 0a 01 02 0e 25 1b 96 eb 0c c9 a0 57 47 9b 27  .....%......WG.'
<3>12 48 4c a5 4b 00 81 99 45 59 31 59 a9 4f a9 59  .HL.K...EY1Y.O.Y
<3>01 01 01 01 01 01 ea 24 00 60 41 00 28 30 30 60  .......$.`A.(00`
<3>13 00 60 08 11 00 00 1e 00 00 00 ff 00 38 33 37  ..`..........837
<3>36 54 30 37 4f 30 30 32 58 0a 00 00 00 fc 00 44  6T07O002X......D
<3>45 4c 4c 20 50 39 39 31 0a 20 20 20 00 00 00 fd  ELL P991.   ....
<3>00 30 78 1e 6b 17 00 0a 20 20 20 20 20 20 00 30  .0x.k...      .0


Kernel version is:

$ cat /proc/version 
Linux version 2.6.33.8-149.fc13.i686 (mockbuild.fedoraproject.org) (gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Tue Aug 17 22:45:56 UTC 2010


I may try building a custom kernel with the EDID checksum disabled and see what that does...

Interestingly, based on (an admittedly limited amount of) research, it looks like the first 8 bytes of the EDID are supposed to be 00 ff ff ff ff ff ff 00,
but my monitor is reporting 0x50 as the first byte.  0x50 is 80 decimal, which exactly coincides with the amount by which the checksum is wrong (i.e. the
remainder).  So, maybe my 10-year-old monitor is beginning to suffer Alzheimer's or something...

(BTW, custom kernel building now...)

Created attachment 443175 [details]
Investigative patch to test DELL P991 checksum theory

Here is a patch I wrote to ignore the EDID checksum error on my 10-year-old DELL P991 CRT monitor.  This is not intended as a real solution, just a way of gathering more information in order to better understand the problem.

With this patch installed, a normal Fedora 13 graphical boot now starts X in 1600x1200 mode @ 85Hz.  (I also happen to have an /etc/X11/xorg.conf file that specifies 1600x1200 mode; this was apparently still hanging around from my earlier troubleshooting efforts.  I'll try removing xorg.conf and see what happens without it.)

Since the data corruption on my monitor seems to be in the fixed 00 ff ff ff ff ff ff 00 header, I wonder if a more general solution approach would be to first test the checksum the normal way, then if it fails, try computing the checksum on only the non-header bytes and add 0xfa (the checksum portion contributed by a valid header).  If that result is valid, then accept the EDID data as "conditionally valid" and continue normally.  Just an idea...

(In reply to comment #30)
> (I also happen to have an /etc/X11/xorg.conf file that
> specifies 1600x1200 mode; this was apparently still hanging around from my
> earlier troubleshooting efforts.  I'll try removing xorg.conf and see what
> happens without it.)

After removing xorg.conf and rebooting, X now starts by default in 1024x768 mode but at 85Hz (yay!) instead of 60Hz.  After logging in, the Administration -> Display menu now shows a ton of different resolution options (including some higher than 1600x1200).  I was successfully able to select 1600x1200, logout and then log back in again.  A new xorg.conf was automatically created and I'm successfully running in 1600x1200 mode @ 85Hz again.

Cool.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

It appears that the original issue in this bug was that, for a monitor with a broken EDID, Fedora 12 left the user kind of high-and-dry with a system that did not provide any kind of working graphical login.

My experience suggests that things improved in Fedora 13 such that graphical login worked to some degree, but far less optimally (w.r.t. resolution and refresh rate) than in previous Fedora releases.

Ideally, I'd still like to see some additional improvement in this area.  Should we change the summary and version for this bug to describe the current situation, or should we close this bug and open a new one?

Ideally, I'd like to see a two-pronged solution along the lines of:

  1.  Tweak the kernel code a bit to be more tolerant of certain kinds of
      broken EDIDs (e.g. mine has a bad first byte, but that seems to be all.)

  2.  Provide a manual override option in the form of kernel command-line
      parameters for manually setting resolution and refresh rate.


I'm willing and interested in developing a kernel patch for this that could be pushed upstream.  (Unfortunately, the machine on which I originally experienced this bug has now died in a more serious manner:  bad capacitors on the motherboard and in the power supply...  Heh, maybe that was even responsible for my bad EDID...  Anyway, my machine is dead for some indefinite period of time, until I either replace the caps and/or buy/build a new machine...  *sigh*)

Solution 2 is already possible with, for example, video=1400x1050

(In reply to comment #34)
> Solution 2 is already possible with, for example, video=1400x1050

Ah.  Excellent!  Thanks!

(In reply to comment #35)
> (In reply to comment #34)
> > Solution 2 is already possible with, for example, video=1400x1050

OK, could I get reinstated what actually is this bug now and in F14 actually about? And if it is hugely different from “KMS:: Reacting badly in face of wrong EDID”, could we close this bug and open a new one about the new issue, please?

Thank you

(In reply to comment #36)
> OK, could I get reinstated what actually is this bug now and in F14 actually
> about? And if it is hugely different from “KMS:: Reacting badly in face of
> wrong EDID”, could we close this bug and open a new one about the new issue,
> please?
> Thank you

My experience has been with F13; my machine died so I haven't been able to try F14.

The F13 behavior is that, with a monitor that reports a bad EDID, F13 boots up in graphical boot mode in 1024x768 resolution at 60Hz.  Then, after logging in, there is no way to increase the resolution / refresh-rate from the GNOME menus.  This is on a machine that "worked fine" at higher resolutions with non-KMS versions of Fedora, such as F10.

After some Googling, I discovered how to disable KMS on the kernel command-line in grub.conf (at the moment, I forget the specific kernel command-line parameter).  This allowed me to use the old pre-KMS model and get the 1600x1200 resolution I wanted.

But I wanted to know why KMS wasn't working as designed, so I dug into it and determined that my monitor was reporting a bad EDID.

I'm now hearing that the "video=" kernel parameter is another possible workaround, but I'm unable to verify this (since my machine is dead...).

So, various options exist at this point, some of which may be:

  1.  Blame things on bad hardware and just say, "Too bad, fix/upgrade your
      hardware or come up with your own software workarounds."  (This is
      essentially what I have done.)

  2.  Document the problem and the available workarounds.

  3.  Try to make the kernel KMS code slightly more tolerant of broken
      hardware.  (The existing kernel code _almost_ does the right thing
      for my monitor, but doesn't cover the case where the very first byte
      of the EDID header is corrupted.  Naturally, on my monitor, the very
      first byte (and only the very first byte) is corrupted...)

If the "video=" kernel parameter does indeed allow me to specify my desired resolution and refresh rate, then I'm sufficiently happy.  I can deal with modifying my kernel command line each time I install a new version of Fedora.  But if the "video=" option doesn't quite cut it, then I'd like to create a patch for option 3 and push it upstream...

I'll let a Fedora maintainer decide how to handle the dispostion of this Bugzilla entry.

There isn't actually unified code for this, AIUI, it's driver-specific. Each driver can (and in some ways does) handle bad EDIDs differently. I think we may have different fallback resolutions for broken EDIDs in the different drivers, and they're also possibly different from the fallback we used with UMS. This could probably be rationalized. Ajax, any comment?

You can override KMS' fallback resolution without having to resort to nomodeset (beware that of the big three drivers, only radeon will still work with UMS; if you disable KMS with nouveau or intel, you also disable the driver, and you will get vesa instead). I'm not sure if you can do it at the kernel level, but you can make it change in X, by specifying modes according to the syntax described here:

http://wiki.debian.org/XStrikeForce/HowToRandR12

I think, anyway.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

My log is full of 'probed a monitor but no|invalid EDID'. This also causes stuttering in the resposiveness of my system, like mini 'hang-ups'.

I have a dual-head setup of Viewsonic VP2030b screens, with a radeon HD4650.
I can setup my resolution ok though, no problem there.

Nov 25 07:35:06 stinkcentre kernel: [59629.140543] radeon 0000:01:00.0: DVI-I-1: EDID block 0 invalid.
Nov 25 07:35:06 stinkcentre kernel: [59629.140545] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID
Nov 25 07:35:17 stinkcentre kernel: [59639.689898] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 254
Nov 25 07:35:17 stinkcentre kernel: [59639.689901] [drm:drm_edid_block_valid] *ERROR* Raw EDID:
Nov 25 07:35:17 stinkcentre kernel: [59639.689917] 
Nov 25 07:35:17 stinkcentre kernel: [59639.927698] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 254
Nov 25 07:35:17 stinkcentre kernel: [59639.927700] [drm:drm_edid_block_valid] *ERROR* Raw EDID:
Nov 25 07:35:17 stinkcentre kernel: [59639.927715] 
Nov 25 07:35:17 stinkcentre kernel: [59640.165452] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 254
Nov 25 07:35:17 stinkcentre kernel: [59640.165455] [drm:drm_edid_block_valid] *ERROR* Raw EDID:
Nov 25 07:35:17 stinkcentre kernel: [59640.165470] 
Nov 25 07:35:17 stinkcentre kernel: [59640.403268] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 254
Nov 25 07:35:17 stinkcentre kernel: [59640.403271] [drm:drm_edid_block_valid] *ERROR* Raw EDID:
Nov 25 07:35:17 stinkcentre kernel: [59640.403286] 


xorg-x11-drv-ati.x86_64  6.13.1-0.3.20100705git37b348059.fc14
kernel.x86_64            2.6.35.6-48.fc14

01:00.0 VGA compatible controller: ATI Technologies Inc RV730 PRO [Radeon HD 4650] (prog-if 00 [VGA controller])
	Subsystem: PC Partner Limited Device 1391
	Flags: bus master, fast devsel, latency 0, IRQ 45
	Memory at c0000000 (64-bit, prefetchable) [size=256M]
	Memory at d0000000 (64-bit, non-prefetchable) [size=64K]
	I/O ports at 2000 [size=256]
	[virtual] Expansion ROM at d0020000 [disabled] [size=128K]
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Legacy Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Kernel driver in use: radeon
	Kernel modules: radeon

I should note that 1 DVI connection uses a regular DVI cable, and the other uses the HDMI connector (and cable). Maybe the HDMI EDID interaction is not working out.

That was not it, the DVI was acting up.

When I fired up gnome-display-settings the system went all haywire and very unresponsive. Could start up X normally after that, even after reboot.

I now disconnected the DVI and replaced it with a VGA cable and that seems to work ok. Very much not the preferred way :-)

see also #649949

*** Bug 655672 has been marked as a duplicate of this bug. ***

Some duplicates of this bug are on Fedora 13 and 14.

I am no longer experiencing this bug on Fedora 14 despite not having changed any hardware. It's possible that a software update has corrected it. 

Although Rawhide is having a similar problem where it struggles a bit (that is, the screen flickers a few times) before settling on the correct resolution. But it's less severe because it does work, just after an annoying flicker.

I too have a P991, with Radeon rv200. I boot to runlevel 3 most of the time, and stay there a lot. Now using the 2.6.38rc2.git7 kernel whichever vts I'm logged in on are almost constantly littered with *ERROR* EDID checksum is invalid, *ERROR* EDID block 0 invalid, *ERROR* Raw EDID and similar messages.

I am experiencing multiple EDID errors in my dmesg log. I am running Fedora 14 x86-64 with a Radeon RV630 HD2600 series adaptor. This links via a Belkin KVM to my HP L2045W LCD display, which is capable of displaying 1680x1050 60Hz. The resolution cannot be adjusted above 1024x768 60Hz.

This behaviour did not occur in Fedora 12 using exactly the same hardware.

F15 2.6.38-1.fc15.i686.PAE

lspci -vvnn
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV280 [Radeon 9200] [1002:5961] (rev 01) (prog-if 00 [VGA controller])
	Subsystem: FIRST INTERNATIONAL Computer Inc Device [1509:9a18]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (2000ns min), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
	Region 1: I/O ports at ec00 [size=256]
	Region 2: Memory at fcff0000 (32-bit, non-prefetchable) [size=64K]
	Expansion ROM at fc000000 [disabled] [size=128K]
	Capabilities: [58] AGP version 2.0
		Status: RQ=80 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
		Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x4
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: radeon
	Kernel modules: radeon, radeonfb

01:00.1 Display controller [0380]: ATI Technologies Inc RV280 [Radeon 9200] (Secondary) [1002:5941] (rev 01)
	Subsystem: FIRST INTERNATIONAL Computer Inc Device [1509:9a19]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 64 (2000ns min), Cache Line Size: 32 bytes
	Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]
	Region 1: Memory at fcfe0000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-


There is a problematic CRT on VGA-0 with no EDID. The card has secondary output to DVI, that is unconnected.

This is repeatadly popping up in my messages/dmesg after enabling KMS:

[ 7917.249497] [drm:drm_edid_block_valid] *ERROR* Raw EDID:
[ 7917.249507] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7917.249515] <3>00 00 00 00 00 00 00 00 00 00 00 00 1f ff ff ff  ................
[ 7917.249522] <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[ 7917.249529] <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[ 7917.249536] <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[ 7917.249543] <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[ 7917.249551] <3>ff fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7917.249558] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7917.249563] 
[ 7917.249575] radeon 0000:01:00.0: VGA-1: EDID block 0 invalid.
[ 7917.249585] [drm:radeon_vga_detect] *ERROR* VGA-1: probed a monitor but no|invalid EDID

Looks like screen on VGA0 flickers every time this error/poll/probe happens. I tried to put 
Section "Monitor"
    Identifier      "VGA-1"
    Option "Ignore" "true"
EndSection

into xorg.conf with no effect.

Is this still an issue with f16 or f17 ?

My two Dell P991 are in storage rather far away from home so testing is impractical.

If anyone else still sees the issue, I'm happy to let the bug be, otherwise we may as well close it.

The only issue I have is the constant spew of completely useless Raw EDID messages in the logs.

I no longer have the system I was experiencing the issue on, so can't say if it's still an issue.

I retired the monitor last week due to constant problems with resolution and messages about raw edid filling the logs. No more testing possible.

I commented previously that the bug had reduced in severity back in December 2010, and since then it has gone away. I'm still using the same monitor and I haven't seen any problems with screen flickering or incorrect resolutions like I used to.

Hello,
I am afraid I am also hit by this bug.
Like Robert, I managed to cope with it since it "just" filled my logs.

But the screen flickering is back every 10 second since the last kernel upgrade.
My setup:
kernel 3.3.1-5.fc16.i686.PAE on f16
dual screen driven by the nouveau driver on a nVidia Corporation G73 [GeForce 7600 GS] (rev a1)
The primary monitor is OK and plugged on DVI
The second one (a cornea CT1904 from 1997) has a corrupted EDID. Its DVI do not work anymore and I plugged its VGA output to the second DVI input on the graphic card.

the first two bytes make the edid signature wrong, but there is no way to give a corrected file to the driver (and the prom is read only => i2c reports write failures)

Could we have this option, or maybe stop scanning the monitor every ten seconds?
A solution to the log spam would also be very appreciated.
I am able to test any solution people can come up with... or give any data needed on my particular configuration.

It would be a pity to have to buy a new monitor: linux was the only OS able to extract all to power of this old clunky monitor.

Hi,
This monitor retired, I'm no longer impacted by the bug... Maybe nobody is?
As far as I'm concerned, it's CLOSED_NOT_ANY_MORE_IMPACTED

(In reply to Felix Miata from comment #46)
> I too have a P991, with Radeon rv200. 

Actually I have three of these.