EXA on -ati makes some operations slow

Thank you for your bug. Do you have a pointer to the upstream discussion or a patch for that? That mentionned on https://bugs.freedesktop.org/show_bug.cgi?id=10070 which is nor marked fixed yet though

no, sorry. I think it was mentioned on the Xdevconf, that xserver1.3 would be needed for EXA in Xorg7.2.

but I will try to find some more concrete infos.

I post here just to confirm this... I'm using radeon driver and it isn't completely usable when using EXA...

I had a chat with upstream, and they think that since EXA is meant for using with a compositing manager this issue is not "high" importance. I tried a snapshot of server-1.3-branch and the issue is still there. Running 'xcompmgr -a' made the problems go away.

I just tried the xcompmgr fix with xsever 1.2 and I would not say it solves much. Though the window movement becomes smooth again as one can expect, the drawing inside windows is still slow - opening firefox for instance takes about 15s while producing 100% CPU load.

Hey, can you test downgrading libx11-6 to an older version? (pre-1.1)

tried the packages suggested in #88815, but got no improvement.

just looked at the duplicates; they are all using the ati driver - just like me. does this bug affect intel people too? if not we should perhaps blame the driver...

I've read somewhere that it does... I mean, also Intel (and other free drivers) users have this issue...
Anyway I can't confirm this completely...

It happens on my systems also.

RADEON 9800 PRO using the RADEON driver
ATHLON XP 2800+
ASUS A7n8x-x NFORCE2
768MB DDR

Any ideas on a fix

have too...

Acer Aspire 5024wlmi
Ati X700
2GB Ram

/me waiting for soluton.

sorry, forget....
dirver: ati and fglrx

Here, too.... Radion X600 on a Sony Vaio VGN-A790.... Problem with slow scrolling and high CPU usage (even when not doing anything at all in X but running gnome-system-monitor) appears with:

Distro Release Date (If any) Kernel Version Graphic Driver X Window Manager
PCLinuxOS 4/2007 2.6.18.x Native ATI KDE
PCLInuxOS 4/2007 2.6.18.x Native ATI WindowMaker
Edgy Eft (6.10) 2.6.18.x(?) Native ATI Gnome
Edgy Eft (6.10) 2.6.18.x(?) Native ATI WindowMaker
SuSE OSS 10.2 2.6.18.x Native ATI KDE
SuSE OSS 10.2 2.6.18.x Native ATI WindowMaker
Feisty Fawn 7.04 2.6.20.x Native ATI Gnome
Feisty Fawn 7.0.4 2.6.20.x fglrx (ATI Proprietary) Gnome
Feisty Fawn 7.0.4 2.6.20.x Native and proprietary ATI WindowMaker
Mandriva 2007 2.6.18.x Native ATI WindowMaker

Problem does not occur with SuSE 10.0 (Kernel 2.6.15.x) with the Native ATI drivers. This older version of SuSE works even with all the current updates (but not upgrade to 10.2). I believe it uses Xorg 6.8.2, rather than 7.0, 7.1 or 7.2 like the other distros listed.

Removed Ubuntu Feisty and replaced with SuSE due to the fact that, over time, the problem seems to gradually get worse. One key indicator that this problem exists is that the CPU of the machine remains pegged at or near full speed (1995 MHz) rather than dropping to its normal "cruise" mode of 798 MHz as it would under a properly working version of Linux.

VirtualEntity
U just change the driver to XAA instead of EXA in 'xorg.conf'

If you could be more specific as to how to accomplish this driver change, it would help.... Perhaps if you could upload your xorg.conf, or the section with the XAA driver specification....

VirtualEntity
I am having some huge PSU or HDD problems. Still haven't concluded which is the cause. So I couldn't test the EXA && XAA problem again. Anyway here's part of the 'xorg.conf' file:"
#################################
Section "Device"
 Identifier "Generic Video Card"
 Driver "radeon"
#tomi
 Option "AGPMode" "4"
 Option "ColorTiling" "on"
 Option "AccelMethod" "XAA"
# Option "AccelDFS" "True"
 Option "DMAForXv" "on"
 Option "ColorTiling" "on"
 Option "EnablePageFlip" "true"
 Option "RenderAccel" "true"
#/tomi
 BusID "PCI:2:0:0"
EndSection
#####################
under ACCELMETHOD change it to EXA or XAA. I am not exactly sure which one gives U normal performance. But I believe its XAA.

Hey, thanks, Ashrack.... I'll look into this....

Is there anything I can do to help you troubleshoot those PSU/HDD
problems? Perhaps two heads are better than one, so if you give me a
quick summary of what's going wrong, maybe I can offer some
suggestions. Even if I cannot, perhaps just organizing your thoughts in
an email might help you gain a better focus on the solution to your problem.

A./

ashrack wrote:
> VirtualEntity
> I am having some huge PSU or HDD problems. Still haven't concluded which is the cause. So I couldn't test the EXA && XAA problem again. Anyway here's part of the 'xorg.conf' file:"
> #################################
> Section "Device"
> Identifier "Generic Video Card"
> Driver "radeon"
> #tomi
> Option "AGPMode" "4"
> Option "ColorTiling" "on"
> Option "AccelMethod" "XAA"
> # Option "AccelDFS" "True"
> Option "DMAForXv" "on"
> Option "ColorTiling" "on"
> Option "EnablePageFlip" "true"
> Option "RenderAccel" "true"
> #/tomi
> BusID "PCI:2:0:0"
> EndSection
> #####################
> under ACCELMETHOD change it to EXA or XAA. I am not exactly sure which one gives U normal performance. But I believe its XAA.
>
>

VirtualEntity

/offtopic
Tnx 4 trying to help but I solved the problem. I sticked another PSU to just power the HDD and GPU and then ran the WDC diagnostic test which repaired the hdd. Afterwards I connected the harddrive to a different molex contoller and also the GPU and now the system is up and running again.
I just can't let go of this baby: Athlon XP BARTON 2800+, 768MB RAM, RADEON 9800PRO, 160GB WDC HDD. I know it is old but it does the job.

/ontopic
Have U fixed the problem with my proposed solution??

Regards,
Tom

ashrack wrote:
> VirtualEntity
>
> /offtopic
> Tnx 4 trying to help but I solved the problem. I sticked another PSU to just power the HDD and GPU and then ran the WDC diagnostic test which repaired the hdd. Afterwards I connected the harddrive to a different molex contoller and also the GPU and now the system is up and running again.
> I just can't let go of this baby: Athlon XP BARTON 2800+, 768MB RAM, RADEON 9800PRO, 160GB WDC HDD. I know it is old but it does the job.
>
Glad to hear that! I understand a love of an old system--as well as the
love of new ones... I've probably got some of the world's oldest
equipment in my basement running my HPC cluster, Hydra, whilst the
newest addition to the family is a 4 GB monster with 8 logical CPUs...
> /ontopic
> Have U fixed the problem with my proposed solution??
>
I still haven't given it a try... I was sidetracked with repairing a
friend's computer (Eew. Windows! Wipe that off!) and upgrading the
Mighty Puss (Octopussy, the 8-CPU monster) to 64-bit CentOS 5 with
VMware 1.0.3 (Yes, it works, and a damn sight better than the older
CentOS 4.x ever did!)

I will get to it and let you know, Ashrack!
> Regards,
> Tom
>
>

What's the situation in gutsy now?

Works in Gutsy, but it is broken in the opposite way. regular metacity works fine, but compiz and such crash X see bug 119032

EXA is still buggy in my case! moving a window will use 100% of cpu

Nicolò Chieffo wrote:
> EXA is still buggy in my case! moving a window will use 100% of cpu
>
>
Definitely the old problem, then. It is absolutely unacceptable that
moving a window on the display should require all of a system's CPU to
accomplish. No one is going to take an operating system seriously if it
only offers the choice of doing useful work _or_ moving windows....

Perhaps we need to look at how others managed to work around this bug by
having a look-see at other distros. The Gentoo-based Sabayon Linux 3.3
is a good example of a distro that uses 2.6.20 kernel with Xorg 7.2 and
manages to avoid this particularly odious problem.

My (admittedly limited) experience with a number of distros on the same
hardware seems to indicate that the bug is most prevalent with kernel
versions from 2.6.15x through 2.6.18x with some issues striking SOME
versions of Kernel 2.6.19/2.6.20-15 (I think this is what Feisty has).

Long story short: How does Ubuntu's implementation of 2.6.20-15 differ
from Sabayon's 2.6.20r3? What is different in the kernel config files?
Maybe I'll look into this, if I get the chance, but I'm no programmer,
nor very experienced at reading kernel config files, so I could probably
have the difference that causes the problem staring me in the face and
not know it...

So, that being said, I defer to wiser heads than mine, but DO offer the
very strong opinion that it is something wrong with the kernel,
specifically that Ubuntu and Debian both do and that Sabayon manages to
avoid.

but remember that only EXA has this problem...

Nicolò Chieffo wrote:
> but remember that only EXA has this problem...
>
>
Are we sure that the problem is caused by EXA and not by some kind of
interaction between EXA and a kernel configured in an incompatible way?
It seems to me that disabling EXA does not make the problem go away (or
does it?)

A./

Using XAA instead of EXA uses norma cpu (in my case, mobility radon 9700)

Nicolò Chieffo wrote:
> Using XAA instead of EXA uses norma cpu (in my case, mobility radon
> 9700)
>
>
'Kay. That proves that removing EXA eliminates the problem. But it
does not (yet) convince me that the problem really _is_ with EXA and not
with some aspect of how the particular kernel is configured with respect
to the hardware it is running on.

A./

No other ideas? Other distributions suffer from this problem, so I don't think it is caused by an ubuntu patch

Upstream said fixed in xorg-core 1.4 (not available in gutsy)

So I guess in Gutsy I will just have to install XORG-CORE 1.4 by compiling it since it will not be in Gutsy

I hope that this patch will be backported to xorg 1.3

Sorry, have you tried if you still have this problem in gutsy, now that the beta is out?
I have. Am I the only one? upstream does not seem to be informed of this problem

I'm sorry, I switched over to Sabayon, which does not seem to have the
problem.... (Kernel 2.6.22)

On Monday 08 October 2007 13:21, Nicolò Chieffo wrote:

> Sorry, have you tried if you still have this problem in gutsy, now that the
> beta is out? I have. Am I the only one? upstream does not seem to be
> informed of this problem

Well, at least we know that sabayon does not have the problem! so this
might be an ubuntu specific problem...

Well, my good fortune may be specific to my laptop (and Sabayon has other
problems), so it is probably not yet wise to assume that it is ubuntu
specific.

I am inclined to think that it happens to affect certain specific video
chipset/motherboard combinations.

(Please forgive me if I am talking about the wrong problem! I was referring
to a video problem that seemed to involve the laptop screen going black
during the boot-up process at the time that the system is supposedly going
into graphical mode.)

I have a work-around for this screen blanking on boot-up issue, by the way, if
you're interested. It came from the Ubuntu forums in July.

On Monday 08 October 2007 14:25, Nicolò Chieffo wrote:
> Well, at least we know that sabayon does not have the problem! so this
> might be an ubuntu specific problem...

Marking as dupe of the -intel bug. If EXA is also slow on -ati or other drivers, please verify against Hardy and open new bugs against those drivers if the issue still exists.

Actually since this has a few dupes with info about -ati issues, I've removed the -intel dupes and will move this bug to xserver-xorg-video-ati for further investigation.

Meanwhile, please test against Hardy and see if the issue still exists. If -ati supports the "greedy" migration heuristic, that may be worth testing out as well.

Wow I've tested now in hardy and it this issue seems gone away!

PS: only with the "greedy" migration heuristic. Is it possible to enable this by default, such as for intel graphics 965?

can we mark this fixed?

I can confirm that the error no longer occurs