Comment 9 for bug 722806

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.