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
| ||
|
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/
Powered by blists - more mailing lists