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 ;)
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
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
dri-devel@lists.freedesktop.org
-
Michael Tokarev