Asus M2A-VM: kernel demanding EDID for an unconnected monitor

[Axel Mueller]

There is a problem with mainboard Asus M2A-VM. There is no HDMI monitor connected (monitor uses DVI) but the kernel still tries to read the EDID. Thus, dmesg is spammed every 10 seconds with this message:
[ 21.383270] [drm:drm_edid_block_valid] *ERROR* Raw EDID:
[ 21.383305] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 21.383307] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 21.383310] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 21.383312] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 21.383314] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 21.383317] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 21.383319] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 21.383322] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 21.383324]
[ 21.383328] radeon 0000:01:05.0: HDMI-A-1: EDID block 0 invalid.
[ 21.383332] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID

X behaves very jerky because of the load caused by the kernel demanding the EDID every 10 seconds.
For more info see https://bugzilla.redhat.com/show_bug.cgi?id=668196 and http://ubuntuforums.org/showthread.php?t=1607778

I found three possible solutions to solve my problem:
1) disable KMS by using the kernel parameter "radeon.modeset=0"
Unfortunately, the X server will then segfault after a short time
2) get the kernel source and patch the radeon driver, see http://ubuntuforums.org/showthread.php?t=1607778
(the patch is not from me!)
this works, but you have to patch the kernel after every update again
3) execute the command
"echo -n N > /sys/module/drm_kms_helper/parameters/poll"
This will effectively stop the pollution of the dmesg (and all the quirky X behavior). This option does not exist in kernel 2.6.35 that's why I had update to kernel 2.6.38

It would be fine if the kernel tries to read the EDID only once and then stops trying if it fails (see patch from solution #2).

[Michal (michal-redhat-bugs)]

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

Addition...

[Michal (michal-redhat-bugs)]

Created attachment 472386
Xorg.0.log file from an affected machine

[Michal (michal-redhat-bugs)]

Created attachment 472387
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.

[Dennis (dennis-redhat-bugs)]

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

[Dennis (dennis-redhat-bugs)]

Created attachment 474823
Xorg.0.log of affected machine

Xorg.0.log of affected machine

[Dennis (dennis-redhat-bugs)]

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

[Michal (michal-redhat-bugs)]

(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.

[Dennis (dennis-redhat-bugs)]

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

[Michal (michal-redhat-bugs)]

(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.

[Dennis (dennis-redhat-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

[Michal (michal-redhat-bugs)]

(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.

[Michal (michal-redhat-bugs)]

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.

[Michal (michal-redhat-bugs)]

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.

[rdratlos (rdratlos)]

There is now a patch for this bug proposed to upstream kernel. See https://lkml.org/lkml/2011/7/7/207

I've backported the patch to Ubuntu Natty. You will find the fixed kernel packages under "https://launchpad.net/~rdratlos/+archive/ppa-asus-m2a-fix".

@Alex: Could you please test the fixed kernel on your system and provide me with the results? I'm especially interested in the dmesg output. Please take also care that under the testing kernel the poll option is set in /sys/module/drm_kms_helper/parameters/poll.

[cheath (cheath)]

Not Alex, but I applied this fix and appears to have stopped logging all of the EDID errors it was previously doing.

NOTE: - I had already used this workaround before applying this
3) execute the command
"echo -n N > /sys/module/drm_kms_helper/parameters/poll"
This will effectively stop the pollution of the dmesg (and all the quirky X behavior). This option does not exist in kernel 2.6.35 that's why I had update to kernel 2.6.38

Also, I am upgraded to Ubuntu 11.10 which put Kernel 3 RC7 after the fact. Errors are no longer displaying.

[madbiologist (me-again)]

The abovementioned patch is included upstream in kernel 3.1-rc1 and has also been cc'd to the stable kernel maintainers for consideration. A PPA of this kernel is available at http://kernel.ubuntu.com/~kernel-ppa/mainline/

[Michal (michal-redhat-bugs)]

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".

[Michal (michal-redhat-bugs)]

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.

[JM (jm-redhat-bugs)]

Same on Fedora 16 with kernel 3.1.9-1.fc16.x86_64. The fix from Comment #10 does not help.

[Eesger (eesger-redhat-bugs)]

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..

[Fedora (fedora-redhat-bugs)]

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

[penalvch (penalvch)]

Axel Mueller, the requested patch is available in Trusty as per http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commit;h=051963d4832ed61e5ae74f5330b0a94489e101b9 . Please reopen if this doesn't work for you, and execute the following in a terminal:
apport-collect 722806