I've upgraded my video card to a "Built-By-ATI" Radeon 9000 Pro. Using ATI's 2.5.1 drivers, I consistently receive segmentation faults in both Unreal Tournament and FlightGear.

In Unreal Tournament, I could load the game without a problem... however, on the first turn to the left on the introductory movie, the ATI driver would segfault. If I skipped the movie, I could play the game for a seemingly random amount of time before it segfaulted.

I managed to work around the UT problem by changing the renderer from
SDL to OpenGL.

However, I can't seem to get around the issue with FlightGear. Whenever I fly at night, the driver immediately segfaults, causing FG to die. During the day, the driver seems to handle it fine... in fact, I'm quite pleased with its performance.

I managed to run gdb on it, backtrace it... and receive the following output.

... *Lots of Loading going on*...
Loading tile /usr/games/lib/FlightGear/Scenery/w130n30/w123n37/942034
token = OBJECT_BASE name = 942034.btg
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 11386)]
0x47da6a0f in s12896 () from /usr/X11R6/lib/modules/dri/fglrx_dri.so
(gdb) bt
#0 0x47da6a0f in s12896 () from /usr/X11R6/lib/modules/dri/fglrx_dri.so
#1 0x3e8bd554 in ?? ()

I ran 'strace' on it too... set the output to a log file. The tail end of it is here:
open("/usr/games/lib/FlightGear/Scenery/w130n30/w123n37/942034.btg", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/games/lib/FlightGear/Scenery/w130n30/w123n37/942034.btg.gz", O_RDONLY) = 10
fstat64(10, {st_mode=S_IFREG|0640, st_size=8298, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x52195000
read(10, "\37\213\10\0\0\0\0\0\0\3]Y\t\\\216\313\367?\317C\310\232"..., 16384) = 8298
read(10, "", 4096) = 0
_llseek(10, 0, [8298], SEEK_CUR) = 0
read(10, "", 16384) = 0
close(10) = 0
munmap(0x52195000, 4096) = 0
close(9) = 0
munmap(0x52194000, 4096) = 0
ioctl(4, 0x4008642a, 0xbffff188) = 0
ioctl(4, 0x4008642a, 0xbffff038) = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

If anybody wants to see the entire log, just email me... it's large, so I didn't want to post it.

I have absolutely no clue what this means, or what I can do about it... or if I simply have to wait until ATI releases a fix (there seems to be no official ATI support forum... just their bug report system). A week or so of searching on google/linux didn't help at all... seems like nobody else is running into this problem.

I've tried upgrading to XFree 4.2.99, but upon starting x, or automatically configuring it, it seems like my character set becomes corrupted... suddenly the screen is filled with odd characters that look like random dots more than anything else. The system still responds, however... I can type in commands, watch the characters change on the screen, and my commands execute correctly. I don't know how to fix that can of worms...
so I returned to 4.2.1

I've also tried installing the GATOS drivers, with no go...

By the way, I'm running Gentoo, upgraded to 1.4rc2, with the vanilla-linux-2.4.20 kernel (stock 2.4.20 kernel sources).

As the ATI driver is closed source (like the nvidia one) your best option is to email ATI's linux support with the details.

Is your "ATI" card a real "Built by ATI" ?
Or is it a card onwhich there's an ATI chipset ? (like Gainward or Hercules for example).

It's a genuine "Built By ATI" card... bought it at Best Buy, off the shelf, came in a nice red & black box with the emblem of what looks like a World War 2 naval mine on the front centered on a nasty-lookin' buzz saw. Bottom of the box has ATI's name on it, along with their address...

Sure looks official to me.

I've already submitted the info to ATI, at least the gdb backtrace... is it worth it to submit the info strace gave me?

Sure ! Submit it, you never know.

But, pal, when I get a look at the ATI website and searching for a drivers made for "Built-by-ATI" there's no driver for your 9000Pro :
http://apps.ati.com/techsuppeuroform...rm_driver.html

But when looking here (in the "Powered by ATI" section then) http://www.ati.com/support/driver.ht...les=_PostSales
I can find your card referenced.

It points then to this :
ATI Linux Driver Version 2.5.1 for XFree 4.1.0 :
http://pdownload.mii.instacontent.ne...2.5.1.i586.rpm

OR ATI Linux Driver Version 2.5.1 for XFree 4.2.0 :
http://pdownload.mii.instacontent.ne...2.5.1.i586.rpm

... which is obviously the same drivers as for my Hercules Radeon 9700PRO 128MB DDR.

Did you try to install one of those RPM as well ?

--Sure ! Submit it, you never know.

Hey, if it helps ATI solve the problem, I'm all for it. I just want it solved... so I don't have to go back to Windows just to do my flight simming.

--...and searching for a drivers made for "Built-by-ATI" there's no driver for your 9000Pro :

Try going to their main page, http://www.ati.com . Under the leftmost column titled "Customer Care", look under the subheading "Built By ATI", and follow the "find a driver" link (to http://mirror.ati.com/support/driver.html). Select Linux/XFree86 for the O/S, and RADEON 9000 PRO for the product. Agree to the EULA. Click OK. Sends you to a page for the Unified Linux Driver, Version 2.5.1. Should work for both Built- and Powered-By-ATI cards.

--http://www.ati.com/support/driver.h...ales=_PostSales

I believe this is the link for the Built-By-ATI driver search...

--... which is obviously the same drivers as for my Hercules Radeon 9700PRO 128MB DDR.

Nailed it on the head

-- Did you try to install one of those RPM as well ?

I have. On a previous install, I installed RPM, and installed the ATI rpm as one would normally do. I've also used rpm2targz to convert it to something I can use without having RPM installed... then went through the install process by hand.

Currently, however, I'm using Gentoo... which provides an ebuild for the ATI 2.5.1 drivers. The build process progresses the same... I've tried both the ebuild and the rpm2targz method, and both provide the same result.

Methinks I'm gonna have to wait for ATI to fix it.

I guess so as well ... unfortunately.