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:	Thu, 23 Feb 2012 10:15:24 -0800
From:	Linus Torvalds <>
To:	Chris Wilson <>
	Michael Buesch <>,
	Alex Deucher <>,
	Dave Airlie <>
Subject: Re: responsiveness: newer kernels causing lagging and blocking

On Thu, Feb 23, 2012 at 9:21 AM, Chris Wilson <> wrote:
> The second is to break the loop for fatal errors, which is addressed by
> commit 9292f37e1f5c79400254dca46f83313488093825
> Author: Eugeni Dodonov <>
> Date:   Thu Jan 5 09:34:28 2012 -0200
>    drm: give up on edid retries when i2c bus is not responding

So I tried cherry-picking this one commit on top of current -git on
one of those nasty Mac Mini's.

I'm sad to report that I don't get anywhere *close* to the reported
performance numbers. Are there other commits involved that I should
have tried?

>    Timing results for i915-powered machines for 'time xrandr' command:
>    Machine 1: from 0.840s to 0.290s
>    Machine 2: from 0.315s to 0.280s
>    Machine 3: from +/- 4s to 0.184s
>    Timing results for HD5770 with 'time xrandr' command:
>    Machine 4: from 3.210s to 1.060s

On that Mac Mini, I get 0.611s before, and 0.553s after. So it does
seem to improve, but not nearly enough.

Part of the problem seems to be the bogus "TV1 unknown connection",
which just isn't true (and probably due to some insane Apple
connection setup). So I suspect something just doesn't get a proper
EDID, and times out or fails, and falls back to some bogus default. I

  TV1 unknown connection (normal left inverted right x axis y axis)
     1024x768       60.0
     800x600        60.3
     640x480        59.9

and I'm pretty sure there's no TV attached unless it is hiding under
the carpet somehow.

"perf record -a" shows that it's spending the time in udelay() as
expected (30% from intel_wait_for_pipe_off(), 30% from sclhi(), 30%
from bit_xfer() and 10% from acknak()). Which is what you'd expect
with that CPU-polling EDID thing.

So adding some scheduling might be a good idea regardless of that commit.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists