Launchpad has imported 18 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=668196.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2011-01-08T21:20:04+00:00 Michal wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/0

------------------------------------------------------------------------
On 2011-01-08T21:21:17+00:00 Michal wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/1

------------------------------------------------------------------------
On 2011-01-08T21:25:56+00:00 Michal wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/2

------------------------------------------------------------------------
On 2011-01-23T15:08:05+00:00 Dennis wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/3

------------------------------------------------------------------------
On 2011-01-23T15:15:15+00:00 Dennis wrote:

Created attachment 474823
Xorg.0.log of affected machine

Xorg.0.log of affected machine

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/4

------------------------------------------------------------------------
On 2011-01-23T15:56:06+00:00 Dennis wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/5

------------------------------------------------------------------------
On 2011-01-23T18:05:33+00:00 Michal wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/6

------------------------------------------------------------------------
On 2011-01-23T18:35:40+00:00 Dennis wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/7

------------------------------------------------------------------------
On 2011-01-23T19:26:14+00:00 Michal wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/8

------------------------------------------------------------------------
On 2011-01-23T19:57:30+00:00 Dennis wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/9

------------------------------------------------------------------------
On 2011-01-25T02:41:56+00:00 Michal wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/10

------------------------------------------------------------------------
On 2011-04-16T16:03:02+00:00 Michal wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/16

------------------------------------------------------------------------
On 2011-06-28T11:37:09+00:00 Michal wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/17

------------------------------------------------------------------------
On 2011-12-22T03:31:54+00:00 Michal wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/21

------------------------------------------------------------------------
On 2011-12-24T16:03:51+00:00 Michal wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/22

------------------------------------------------------------------------
On 2012-01-23T10:47:34+00:00 JM wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/23

------------------------------------------------------------------------
On 2012-03-03T16:38:48+00:00 Eesger wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/24

------------------------------------------------------------------------
On 2012-08-07T19:44:52+00:00 Fedora wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/722806/comments/25


** Changed in: linux (Fedora)
       Status: Unknown => Won't Fix

** Changed in: linux (Fedora)
   Importance: Unknown => Medium

** Bug watch added: Red Hat Bugzilla #709181
   https://bugzilla.redhat.com/show_bug.cgi?id=709181

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/722806

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

Status in Linux:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in linux package in Fedora:
  Won't Fix

Bug description:
  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).

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/722806/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to