Re: VERY slow scrolling on radeon graphics card: debugging a timing issue?

Previous thread: Microcode update taking >5 mins in next-20101220 by Chris Ball on Monday, December 20, 2010 - 1:50 pm. (1 message)

Next thread: [PATCH] staging: tidspbridge: remove code referred by OPT_ZERO_COPY_LOADER by Ernesto Ramos on Monday, December 20, 2010 - 2:23 pm. (2 messages)
From: Michael Tokarev
Date: Monday, December 20, 2010 - 1:58 pm

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 ...
From: Andrew Morton
Date: Wednesday, December 22, 2010 - 3:00 am

(cc dri-devel)

--

From: Mark Hounschell
Date: Wednesday, December 22, 2010 - 3:55 am

I also see this very problem on several machines I have with radeon video.
For me the worst part is using vi in a konsole. Moving the cursor around
is so slow that I just can't use these machines directly and have to ssh
into them from another machine just to work on them.

I know its probably not proper to mention it, but when I run the ATI
proprietary
driver, that problem does go away. But for other reasons I can't use it.

Regards
Mark
--

From: Michel Dänzer
Date: Thursday, December 23, 2010 - 12:25 am

That's not the same problem as the one described by Michael, which is
about the console on virtual terminals different from X.

For your problem, try choosing a different font (a fontconfig one
instead of a legacy X one) in konsole.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer
--

From: Mark Hounschell
Date: Thursday, December 23, 2010 - 5:53 am

Hum, but I do in fact see the same thing he sees on a VT. A dmesg
command from a VT  takes around 20 seconds to display. The same in a
konsole takes a fraction of a second.
So your probably right that my vi problem in a konsole is a different
issue. I do see the same thing as the OP does though. I just figured
they were probably related.

Changing fonts doesn't change anything though. I normally use the "Misc
Console" font FWIW.

Regards
Mark

--

From: Pavel Machek
Date: Sunday, January 2, 2011 - 2:00 am

Try "irqpoll"?


Watch /proc/interrupts to see if radeon uses them and if they appear
to work?
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

From: Michael Tokarev
Date: Tuesday, January 4, 2011 - 3:50 pm

It turned out to be a bit less easy than I thought.

The thing is, it appears the issue is not triggered
on fresh boot - scrolling is reasonable fast there.
But slowness returns back after suspend-to-RAM cycle

Yes, CPU load fixes the issue immediately.  But switching

I don't see any change in radeon interrupt numbers during the
scrolling, so it's difficult to say.  The IRQ is shared between
several devices:

$ grep radeon /proc/interrupts
  18:  510439  370  IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, radeon

The counter changes but very slowly (and not during the scroll
test when I don't touch anything), I see on correlation between
it any my actions.

Thanks!

/mjt
--

Previous thread: Microcode update taking >5 mins in next-20101220 by Chris Ball on Monday, December 20, 2010 - 1:50 pm. (1 message)

Next thread: [PATCH] staging: tidspbridge: remove code referred by OPT_ZERO_COPY_LOADER by Ernesto Ramos on Monday, December 20, 2010 - 2:23 pm. (2 messages)