Description of problem: The following parts of the basic KMS test, as described at http://fedoraproject.org/wiki/QA:Testcase_intelvideo_kms , failed: # (KMS) The boot process (and, later, X) should use the correct native resolution for your monitor # (Plymouth) No flickering or mode changes should occur from initrd right through to GDM Version-Release number of selected component (if applicable): How reproducible: Boot the x86_64 LiveCD ( http://adamwill.fedorapeople.org/gfx_test_week_20100412/gfx_test_week_20100412_x86-64.iso ) on my hardware ( http://www.smolts.org/client/show/pub_d0d315d9-b6ef-4573-b52c-0ee7e8661140 ). Actual results: The boot process uses native (1080p) resolution on my TV (Sony Bravia KDL32W550, connected via DVI->HDMI adapter), but not on VGA-connected monitor (Samsumg 770P, connected to VGA, probably because of invalid EDID). Note that I connected the monitors in such way only for a test, normally I don't have the TV connected to my computer, and use my Samsung monitor via DVI. There is flickering (if one can call a 10-second change to black "flickering") on both the monitor and the TV.
Created attachment 406844 [details] /var/log/messages
Created attachment 406845 [details] Xorg.0.log Unfortunately, none of these two files contain the VGA monitor's EDID. How to dump it?
Moreover, there is no obvious way to switch the VGA monitor to its native resolution (1280x1024) because of the invalid EDID.
Created attachment 406851 [details] dmesg The EDID for the monitor is actually in dmesg. Please add a relevant quirk for it - e.g., the 1280x1024@60 mode should be available.
I have worked around this bug by creating this xorg.conf: Section "Monitor" Identifier "Monitor-VGA1" VendorName "Samsung" ModelName "SyncMaster 770P" HorizSync 30-70 VertRefresh 59-61 Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync EndSection Section "Device" Identifier "Card0" Driver "intel" VendorName "Intel Corporation" BoardName "82G965 Integrated Graphics Controller" BusID "PCI:0:2:0" Option "Monitor-VGA1" "Monitor-VGA1" EndSection but I think that working around VGA monitors with broken EDID should be easier.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I'm not sure it's actually possible to have specific quirks for monitors which return invalid EDIDs like this. But Adam will know for sure.
By "working around VGA monitors with broken EDID should be easier", I mean "please create a GUI tool for creation of xorg.conf snippets with frequency ranges and modelines and start it automatically upon detection of a monitor with unknown characteristics".
*** Bug 523912 has been marked as a duplicate of this bug. ***
*** Bug 611149 has been marked as a duplicate of this bug. ***
Is there any way, short of recompiling kernel modules, to prevent a constant spamming of dmesg with dumps of invalid EDID (all zeros in my case) and /var/log/messages with remainders that "probed a monitor but no|invalid EDID"? Yes, I know that this information is correct but repeated every ten seconds for the last few months it hopefuly sunk in. I also cannot do much with it so saying it over and over is kinda pointless and hides in this flood possible other issues.
Actually, it's even worse than that: dmesg (and thus syslog) get spammed with error messages about monitor EDIDs *even when there is no monitor attached*. For example, I have a small Linux firewall, running Fedora 14. I have a very old VGA monitor that I connect to it whenever I need to access the console, but other than that, it has no monitor. And every 10 seconds, dmesg/syslog gets spammed with error messages about an invalid/missing EDID. My logs are filling up with these damn messages, to the point where I'm going to have to try using rsyslog regex tricks to squash them, or else grow my /var/log logical volume. These messages are beyond just annoying; I consider them to be a DoS attack. An initial error report about the EDID is fine, but all subsequent error reports should be suppressed unless the driver detects some sort of configuration change (e.g., a new monitor was plugged in).
James: please file a new bug for that, it's not what's being reported here. thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #12) > Actually, it's even worse than that: dmesg (and thus syslog) get spammed with > error messages about monitor EDIDs *even when there is no monitor attached*. Check bug 668196. I do not know if your symptomps match what is described there but there is a chance that this is something close.
(In reply to comment #13) > James: please file a new bug for that, it's not what's being reported here. There were other bugs reported, say like bug 649949 or bug 611149, but they got closed as duplicates of this one.
At least with recent kernels, there is a way to avoid the dmesg issue: echo 0 > /sys/module/drm/parameters/debug disables the output...
(In reply to comment #16) > echo 0 > /sys/module/drm/parameters/debug > disables the output... AFAICS a value of /sys/module/drm/parameters/debug is 0 by default, at least for bug 649949, so how this would help?
My mistake! It seems that the error appears in my log only a few (around 30) times each time I connect my VGA cable. As I had discovered this behaviour only after I set to 0 the debug flag, I thought this was the explanation. I was wrong... The good news is that somehow the bad EDID issue is only reported a limited amount of time and that I don't feel any slowness anymore...
(In reply to comment #18) > It seems that the error appears in my log only a few (around 30) > times each time I connect my VGA cable. That seems to be really minor in a comparison with bug 668196 which looks like somewhat related but quite likely a different problem. There a relentless pounding with attempts to read EDID data from a non-existent monitor continued every 10 seconds until /sys/module/drm_kms_helper/parameters/poll was set to "N". This did not completely turn off these attempts but at least made them managable. Such workaround is valid for Fedora 14. What does happen with Fedora 13 I do not know. The hardware in question was used with Fedora 12, with no such issues, and OS later replaced with Fedora 14 and that created a huge drag.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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