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

[Michael Tokarev <mjt@tls.msk.ru>]

05.01.2011 01:50, Michael Tokarev wrote:
> 02.01.2011 12:00, Pavel Machek wrote:
>> Hi!
>>
>>> 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...
>>
>> Try "irqpoll"?
> 
> 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
> (not suspend-to-disk).  I'm still trying ;)

Two more data points.

irqpoll "helps" - it makes the scrolling "jumpy", it is
slow for a few first lines, next it speeds up but not to
full speed still, and the speed varies during one test
(while it scrolls, say, dmesg).

When performing syspend-to-disk cycle the speed restores
back to normal, regardless of irqpoll.

So it's definitely something to do with suspend-to-ram.

And there's more: the system does not perform suspend-to-ram
properly using "simple" way -- "echo mem > /sys/power/state".
This way, everything gets turned off (disks, monitor, usb
devices etc), but the power indicator stays on, and the system
does not react to anything - only hard reset works.  When using
pm-suspend it performs suspend correctly, and enters state when
the power indicator blinks, and power button returns the system
back to working state.  This is when run from "text" console,
but apparently this is another issue and is something new
(in 2.6.36), since I _know_ I used simple `echo mem' many times
before.

Thanks!

/mjt

>> Will cpu load speed it up, too? (Like yes > /dev/null)?
> 
> Yes, CPU load fixes the issue immediately.  But switching
> from ondemand to performance CPU governor does not fix it.
> 
>>> 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.
>>
>> Watch /proc/interrupts to see if radeon uses them and if they appear
>> to work?
> 
> 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