linux-kernel - Re: [PATCH] drm: Reduce the number of retries whilst reading EDIDs

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]

Message-ID: <CA+55aFyAUgY5BBLA+eVF4bFTFkooxQneKE-0BWy1nrjUni=vxg@mail.gmail.com>
Date:	Thu, 23 Feb 2012 12:15:03 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Chris Wilson <chris@...is-wilson.co.uk>
Cc:	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	Eugeni Dodonov <eugeni.dodonov@...el.com>,
	Dave Airlie <airlied@...hat.com>,
	Alex Deucher <alexdeucher@...il.com>
Subject: Re: [PATCH] drm: Reduce the number of retries whilst reading EDIDs

On Thu, Feb 23, 2012 at 11:52 AM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
>
> i2c retries if sees an EGAIN, drm_do_probe_ddc_edid retries until it
> gets a result and *then* drm_do_get_edid retries until it gets a result
> it is happy with. All in all, that is a lot of processor intensive
> looping in cases where we do not expect and cannot get valid data - for
> example on Intel with disconnected hardware we will busy-spin until we
> hit the i2c timeout. This is then repeated for every connector when
> querying the current status of outputs.

Sadly, this doesn't seem to make any difference to my case. My xrandr
stays at 0.555s even with this patch.

So apparently the Apple Mac Mini issue is not about retries. But maybe
this fixes the problem Stephan Bärwolf reported?  The Apple Mac Mini
is known for doing things oddly, so ..

You didn't include Stephan on the cc for that patch, though.

Btw, clearly X does *not* cache the EDID results, at least not for
this case. So the explicit xrandr example is probably pretty close to
what wine does. Maybe the proper fix is to just make X.org force
caching when clients do this (because it's definitely X that does the
drm_mode_getconnector() thing - xrandr itself spends zero time on
this, it just does an X request and waits for the result).

The fact that EDID takes half a second to get is not a problem per se.
It's a problem only when X does it over and over again because some
client does something unexpected.

                      Linus
--
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/