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.