EXA causes XServer 1.5 to crash?

[Thetargos]

Or rather enter into an infinte loop, which causes the X process to eat pretty much all available CPU.

Ever since Xorg 7.4 was released for Fedora 9 and XServer bumped to version 1.5.2 I had been using EXA as the 2D acceleration method. While this is sensibly much faster than XAA, it also started causing problems with XServer 1.5.2, the main characteristic of the issue I was experiencing was system unresponsiveness while looking at pictures or zooming into images, no matter what program was I using, and the viewing window was small enough. The XServer would hang as soon as the image is panned (be it GIMP, Inkscape, a picture in EoG or gThumb at normal size). As soon as I disabled Option "AccelMethod" "EXA" from xorg.conf, this hang doesn't seem to happen any longer.

Will try to report this back to the bug report already present in the xorg-x11-drv-ati tracker.

[oibaf]

Note that Fedora is using - at least for Fedora 10 - some backported EXA patches from current git:

http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/

The problem may be in these patches. You should file a bug on fedora bug tracker.

[Thetargos]

I've filed a bug on Fedora's tracker... However I'm using Fedora 9, I don't know if these same patches are present in XServer 1.5.2/xorg-driver-ati in Fedora 9 as well, but the driver version for Fedora 9 at least is still 6.8, while the latest upstream release is 6.9, I didn't mention here (maybe I should have) that this behavior is also present even when using a driver built from GIT. And it is also present in the latest RadeonHD (from GIT) driver as well (again, when using EXA acceleration), which now incorporates virtually the same degree of support for R500 as the xorg-driver-ati does. There is also a bug reported upstream to the Xorg-driver-ati tracker, but it has not received much attention... I'll may have to end up reporting this to the mailing list instead.