linux-kernel - Re: [PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 22 Jun 2011 17:17:50 +0200
From:	Thomas Reim <thomas.reim@...omuc.de>
To:	Alex Deucher <alexdeucher@...il.com>
Cc:	reimth@...glemail.com, Dave Airlie <airlied@...hat.com>,
	Mario Kleiner <mario.kleiner@...bingen.mpg.de>,
	Jean Delvare <khali@...ux-fr.org>,
	Tyson Whitehead <twhitehead@...il.com>,
	Jason Wessel <jason.wessel@...driver.com>,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	Thomas Reim <rdratlos@...oo.co.uk>
Subject: Re: [PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error
 flooding problem

Dear Alex, 

> This is going to enable your quirk on every board with an HDMI port.
> If we need to add a quirk for your board, let's make it board
> specific.  It might be better to just disable edid polling for certain
> connectors on certain boards if they cause problems when no monitor is
> detected.
> 
> Alex

Initially, I made the quirk only for the Asus board, because I only have
this one to test. But the quirk applies of course to all boards that use
the RS690 type chipset.

I went through a couple of the many and various bugs that reported the
EDID error/dump flooding problem. Beside of RS690, also at least RS630,
RV770 and R350 are affected by this problem. In addition, I also found a
bug report on Intel 945 GM that seems to have the same root cause.

The majority of the bugs (ca. 80%) report a problem with the HDMI-A
connector. 15% have a problem with the DVI-I connector and 5% have a
problem with the LVDS connector. 

The proposed patch currently concentrates on the HDMI-A connector, only.

Based on Jean's proposal I updated the patch, so that
radeon_ddc_edid_probe() now replaces radeon_ddc_probe() for all HDMI-A
connectors. 

According to the VESA standards we could also do this for all connector
types in general. DDC is i2c plus EDID. Without the patch
radeon_ddc_probe() probes DDC by checking, if data at all can be
retrieved from i2c port 0x50 (where the EDID is provided). New
radeon_ddc_edid_probe() just checks in addition, if the EDID header and
version/revision information is available and according to the VESA
standards. 

Then and only then (for the HDMI-A connectors) we let drm_get_edid() and
drm_edid_block_valid() check the EDID checksum and probe the validity of
the EDID.

According to VESA's implementation guide this is the right approach:
Checking the exact match of the EDID header and that the revision number
is in valid range is mandatory. 

Based on Jean's comments, I believe that it makes sense to have EDID
polling enabled as there might be temporary communication problems
between graphics card and monitor. These should be logged. This also
applies for the buggy HDMI-A connectors, as soon as a monitor is
connected to them.

Hope this helps you.

Best regards

Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/