Description of problem: After upgrading one of machines to Fedora 14 the following started to appear in dmesg roughly _every_ 10 to 11 seconds: [drm:radeon_dvi_detect] *ERROR* HDMI Type A-1: probed a monitor but no|invalid EDID and each of those messages acompanied by multiple "[drm:drm_edid_block_valid] *ERROR* Raw EDID:" dumps - all zeros. At the same rate I am getting in /var/log/messages a constant stream of: radeon 0000:01:05.0: HDMI Type A-1: EDID block 0 invalid. [drm:radeon_dvi_detect] *ERROR* HDMI Type A-1: probed a monitor but no|invalid EDID The first problem is that there is NO monitor from which these "*ERROR*" readings could possibly occur. In /var/log/Xorg.0.log one can find corresponding to reality: RADEON(0): Output VGA-0 connected RADEON(0): Output S-video disconnected RADEON(0): Output HDMI-0 disconnected RADEON(0): Output DVI-0 disconnected Moreover X gets EDID data and reports: RADEON(0): EDID for output VGA-0 RADEON(0): Manufacturer: SAM Model: 2b Serial#: 1095840057 RADEON(0): Year: 2001 Week: 41 RADEON(0): EDID Version: 1.3 .... RADEON(0): Monitor name: SyncMaster RADEON(0): Serial No: H3NRA03696 RADEON(0): EDID (in hex): RADEON(0): 00ffffffffffff004c2d2b0039315141 RADEON(0): 290b010368241b752b5e89a353469824 RADEON(0): 11484cffff80315945596159818fc140 RADEON(0): 010101010101bc34009851002a401090 RADEON(0): 130060081100001e000000fd0032a01e RADEON(0): 5513000a202020202020000000fc0053 RADEON(0): 796e634d61737465720a2020000000ff RADEON(0): 0048334e524130333639360a20200044 RADEON(0): EDID vendor "SAM", prod id 43 RADEON(0): Using hsync ranges from config file RADEON(0): Using vrefresh ranges from config file (The above not entirely corresponds to an ouput of /usr/bin/edid-decode which is attached). As it happens an output of 'lspci -vvn -s 01:05.0', which is "01:05.0 VGA compatible controller: ATI Technologies Inc RS690 [Radeon X1200 Series] (prog-if 00 [VGA controller])", starts with: 01:05.0 0300: 1002:791e (prog-if 00 [VGA controller]) Subsystem: 1043:826d and 'radeon_atom_apply_quirks()' from drivers/gpu/drm/radeon/radeon_atombios.c has a code like this: /* Asus M2A-VM HDMI board lists the DVI port as HDMI */ if ((dev->pdev->device == 0x791e) && (dev->pdev->subsystem_vendor == 0x1043) && (dev->pdev->subsystem_device == 0x826d)) { if ((*connector_type == DRM_MODE_CONNECTOR_HDMIA) && (supported_device == ATOM_DEVICE_DFP3_SUPPORT)) *connector_type = DRM_MODE_CONNECTOR_DVID; } As this happens to be Asus M2A-VM board then it appears that "HDMI Type A" should not be even showing up or I am reading that wrong? Well, unless this ATOM_DEVICE_DFP3_SUPPORT is not valid but in such case maybe this quirk is too restrictive? In any case the hardware worked without such fireworks with older Fedora releases. Version-Release number of selected component (if applicable): all kernels used with Fedora 14 for now up to 2.6.35.10-74.fc14.x86_64 How reproducible: all the time Expected results: Even if this failure has to be reported this does not happen more than once Additional info: Matej Cepl appears to lump all EDID issues with a lingering Intel video bug 582712 where there are reported troubles reading EDID from a particular monitor. It does not look to me like the same thing at all. Originally I reported that as commments to bug 649949 but looking deeper it appears that this is not precisely that problem either.
Created attachment 472386 [details] Xorg.0.log file from an affected machine
Created attachment 472387 [details] results of edid-decode on EDID data as reported by X There appear to be some discrepancies between this and some data interpreted by X. I did not try to check why. When I tried to read EDID directly, instead of getting that from logs, I got errors.
I too am having this issue with my Asus M2A-VM board, but in addition X won't even launch, so I'm dead in the water! I need a workaround ASAP. Let me know what I can do to help. Dennis
Created attachment 474823 [details] Xorg.0.log of affected machine Xorg.0.log of affected machine
I just tried using the analog port with the same results. X does start, with the Fedora logo, then quits with this error. Also, I have the Acer P235Hbmid Black 23" 5ms HDMI Widescreen LCD Monitor. Dennis
(In reply to comment #3) > I too am having this issue with my Asus M2A-VM board, but in addition X won't > even launch, Try to drop into /etc/X11/xorg.conf.d/ a file, say broken.conf, with something like that in it: Section "Device" Identifier "Videocard0" Driver "radeon" Option "IgnoreEDID" "on" EndSection No idea if this will really help any but you can check. It gave me a running X right after an F14 upgrade, when X was refusing to start otherwise, although apparently after updates this was no longer required. As a matter of fact I attempted to play also with an option "CustomEDID" to see if this will not stem a flow but that did not help. Not that surprising as a garbage is spewed by a kernel module and these options apply on an X level.
Thanks Michael. Unfortunately adding this file (or putting the Option in my xorg.conf) didn't change anything. I've also noticed that X is no longer updating my Xorg.0.log, so I can't tell if the version I posted helps. I did see that it contains a segfault at 0x4 though. And it used to recognize my monitor/read the EDID. How do you restart X from a command line without rebooting? Dennis
(In reply to comment #7) > Unfortunately adding this file (or putting the Option in my xorg.conf) didn't > change anything. It appears from your log that you are also hit by bug #666900 which segfaults X. That appears to be a different issue. Possibly not exactly 666900 as https://bugzilla.redhat.com/buglist.cgi?quicksearch=xorg_backtrace%2B0x3c shows 19 bugs.
I think you're right, I have both bugs. I'm not using the nomodeset kernel option, yet my server crashes. I'll continue watching this bug in case the EDID issue is resolved, but take my server-crash issue to 666900. Thanks, Dennis
(In reply to comment #0) > After upgrading one of machines to Fedora 14 the following started to appear > in dmesg roughly _every_ 10 to 11 seconds: It appears that this relentless beating on logs can be at least stopped with echo -n N > /sys/module/drm_kms_helper/parameters/poll A default value is "Y". I do not know at this moment if some undesirable side-effects will not show up but so far so good.
See also http://ubuntuforums.org/showthread.php?t=1607778, https://lkml.org/lkml/2011/4/14/661 and a response at https://lkml.org/lkml/2011/4/15/36 Using drm_kms_helper.poll=0 does not seem to make much difference in my case. I thought that it may prevent some failed attempts to read EDID before /sys/module/drm_kms_helper/parameters/poll can be set like in comment 10 but this does not seem to be so. I did not try to rebuild initramfs.
For a reference: https://lkml.org/lkml/2011/6/21/244 and a discussion in a thread which follows. The following comment introduces that patch on LKML: Some integrated ATI Radeon chipset implementations (e. g. Asus M2A-VM HDMI) indicate the availability of a DDC even when there's no monitor connected. In this case, drm_get_edid and drm_edid_block_valid periodically dump data and kernel errors into system log files and onto terminals, which lead to an unacceptable system behaviour.
After switching the affected machine to Fedora 16 with 3.1.5-6.fc16.x86_64 kernel this log spamming as described above apparently stopped and setting /sys/module/drm_kms_helper/parameters/poll to "N" and/or using as boot parameter drm_kms_helper.poll=0 does not seem to be required anymore. Other over and over repeating messages are showing up instead. Like this: .... ... radeon_dri2_schedule_flip:670 fevent[0x27b51a0] ... radeon_dri2_flip_event_handler:1067 fevent[0x27b51a0] width 1280 pitch 5120 (/4 1280) ... but this far not on that scale like previously. Other things instead are conspiring to make logs hard to use - like gnome-shell spilling tons of "DEBUG(+)" messages - but this is not that bug anymore. BTW - recorded in Xorg.0.log EDID data are the same as in the original report with this exception that now I see: RADEON(0): Using EDID range info for horizontal sync RADEON(0): Using EDID range info for vertical refresh while before these were "from config file".
I am not sure if I did not speak too soon. I just booted 3.1.6-1.fc16.x86_64 and I again see in dmesg for every detected connector "No monitor connected or invalid EDID", which is not really the case, and repeated attempts to read "Raw EDID" blocks filled with 0. I guess that I will keep "anti-poll" measures in place. These series of "radeon_dri2_schedule_flip:670" and "radeon_dri2_flip_event_handler:1067" are still there.
Same on Fedora 16 with kernel 3.1.9-1.fc16.x86_64. The fix from Comment #10 does not help.
I also have a Fedora system running on a M2A-VM HDMI, I am running version 13 (2.6.34.9-69.fc13.x86_64) and after a 'yum update' got the same spammer results in the /var/log/messages. But the solution provided in: https://bugzilla.redhat.com/show_bug.cgi?id=709181#c3 Solved my problem, no more errors and X runs fine now (when I plug in a monitor, on VGA). When I plug in or a a monitor I get a bunch of those errors, but the do end..
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. 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 '15' 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 15 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