linux-kernel - Re: Radeon jittery post 2.6.35

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:	Tue, 15 Mar 2011 17:08:25 -0400
From:	Jerome Glisse <j.glisse@...il.com>
To:	Anders Eriksson <aeriksson@...tmail.fm>
Cc:	Alex Deucher <alexdeucher@...il.com>, airlied@...hat.com,
	xorg-driver-ati@...ts.x.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org
Subject: Re: Radeon jittery post 2.6.35

On Tue, Mar 15, 2011 at 4:58 PM, Anders Eriksson <aeriksson@...tmail.fm> wrote:
>  On 03/14/11 23:22, Alex Deucher wrote:
>> On Mon, Mar 14, 2011 at 6:20 PM, Alex Deucher <alexdeucher@...il.com> wrote:
>> > On Sun, Mar 13, 2011 at 10:08 AM, Anders Eriksson <aeriksson@...tmail.fm> wrote:
>> >>  Hi,
>> >>
>> >> I've found what I guess is a radeon (or drm/kms) regression post 2.6.35.
>> >> I've got my TV conneced to my RS690G over HDMI, and the display has
>> >> always been jittery after POST and at the GRUB screen. Pre-KMS, the X
>> >> server (or driver got it sorted), and when KMS started, the display
>> >> stabilized right after the kernel driver was initiated. However, post
>> >> 2.6.35, I see the jitter is back.
>> >>
>> >> I've spent the last month trying to bisect it, but pretty much failed.
>> >> It appears that versions closer to 2.6.38-rcX are more prone to display
>> >> jitter, while 2.6.36 or so can have many successful runs. It also
>> >> appears to be related to device power-on order, or so I've come to
>> >> believe; A stable display can turn jittery, just by power cycling the TV.
>> >>
>
> Some further testing on a clean rc8 suggests that the jitter seen
> there can  reliably be removed by power cycling the TV while in X,
> or starting X with the TV off.
>
> I'm tempted to think that something makes too much out of bad
> info collected from the TV, and falls backs to saner defaults if
> the TV has nothing to say.
>
> I've seen in the logs that the EDID is disliked:
> [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but
> no|invalid EDID
> Not sure if that is related though (cannot seem to be able to provoke
> that error message right now)
>
> -A

EDID failure could very well explain it, EDID retrieval seems to fails
on some GPU under some circonstance (when there is CPU load that
interfer with i2c timing i guess). Does the log have the edid failure
message when the tv is jittering ? Or is it the otherway around ?

Cheers,
Jerome
--
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/