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-next>] [day] [month] [year] [list]
Date:	Mon, 20 Dec 2010 23:58:21 +0300
From:	Michael Tokarev <mjt@....msk.ru>
To:	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: VERY slow scrolling on radeon graphics card: debugging a timing issue?

Hello.

A weird problem here, and I'm looking for help in
an attempt to solve it.

Ever since KMS went into kernel and I tried turning
it on, the scrolling speed on the resulting "text"
console (with kms it works in one of graphics modes
hence "text" in quotes) become really _awful_.

For example, running `dmesg' (which has ~2000 lines)
on the console takes about 2.5 _minutes_ (!) to
complete, -- which means the speed is about 10 lines
per second.  On an old notebook I have, with some also
nvidia card, the same operation completes in about
0.8 sec.

The lines goes up in a slow motion, I can watch every
new line appearing and scrolling.

It was this way for a long time, and I almost gave up --
in X everything works ok, and in order to speed up
booting again I just added "quiet" option to the kernel
command line, to avoid scrolling of kernel messages.

But yesterday I noticed something else entirely, which
make me hope the problem actually _can_ be solved.

The thing is: that same scrolling becomes much faster
when I "do something" else while it scrolls up.  First
I noticed this when I wanted to switch to another vt
while it were scrolling -- I held down Ctrl key on my
keyboard, and out of the sudden the scroll speed up
dramatically.

It turned out I can speed the thing to about 10 times
by generating some load: hit and hold a key on the
keyboard (generates interrupts?), run kernel compile
in the background (generates disk interrupts?), move
mouse...

While doing "something", the same scrolling completes
in about 8 seconds instead of 2m30s.  Dramatic improvement.

Now, when I hold a key or move mouse, the scrolling
is "jumpy" - sometimes it slows down back to original
"slow" form for a bit, and sometimes it jumps a few
lines in one go.

I tried to disable cpufreq (selecting "performance"
governor) - this changes exactly nothing.

Next someone suggested the "perf" tool.  And this one
is even more interesting: while `perf top' is running
(on another console or X), the scrolling is.. fast
again, as if I were moving my mouse!  Once I stop
`perf top', it becomes slow again.  So the bug
disappears while you watch it.

And there I'm stuck again.  I asked in #radeon, but
there, Alex Deucher told me that he has no clue and
that the behavour is weird (it is weird indeed).

Any hints on where to go from there are apprecated.

The hardware is an AMD780g-based motherboard with
and Athlon CPU, I've seen the same behavour from
many other similar boards.  Kernels - all up to
the current 2.6.36.2, sine the old days when kms
for radeon first appeared in staging.

I know kms/fbcon scrolling is slow on radeon because
it uses completely unoptimized bitblt routines (even
when the hw is pretty much capable of doing all that
stuff internally).  But what I see here is something
different - the 8 sec to scroll 2000 lines is the
result from the un-optimal bitblt, not the 2m30s.

Thanks!

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