Okay, I am getting this bug now.
Hard to describe, but easy to see. I don't think this was happening before this last patch but.

http://gehenna.autocthonia.net/~zyl/vodumps/oddplanets/dump0000.png
http://gehenna.autocthonia.net/~zyl/vodumps/oddplanets/dump0001.png

Most planets have off center atmospheres now, but not all planets are hollow.

I have tried using both XAA and EXA and get the same results. No changes to xorg.conf netted any visible changes at all. Only driver options I have on are:

AGPMode 4
DepthBits 24
AccelMethod EXA

Any suggestions are appreciated.

FreeBSD 6.2-RELEASE-p6 (emulating Fedora Core 4)
AMD Athlon 2400+ (2Ghz)
ATI Radeon 9000
1 Gig RAM

Do you have meaningful OpenGL acceleration in there somewhere? XAA and EXA are just 2D acceleration for X...

i seen something kinda like that a long time ago, was an overheating video card might want to check yourse for meltage

Interesting. The radeon man page says "acceleration" for AccelMethod, but not if it applies to 2D or 3D. The manpage for exa clarifies it, thanks. In any event, here are the logs for VO:

http://gehenna.autocthonia.net/~zyl/vodumps/errors.log
http://gehenna.autocthonia.net/~zyl/vodumps/openglerr.log
http://gehenna.autocthonia.net/~zyl/vodumps/openglinfo.log

What does "glxinfo | grep direct" say?

It looks like it's not rendering the planet properly. Either the near clipping plane is too close to the planet in the background pass or the planet vertex array is being cut off (only rendering most of the planet).

Looking at the openglinfo.log:

GL_MAX_ELEMENTS_VERTICES: 3000
GL_MAX_ELEMENTS_INDICES: 3000

That's interesting. Usually those numbers are 65535 or 1048576.
I think that may be causing the planet to only render 3000 vertices or 3000 indices.

Edit:
Andy pointed out this:
http://osdir.com/ml/video.dri.user/2004-07/msg00072.html
Apparently this is a known problem with MESA drivers. I suggest to not use the MESA DRI drivers if possible.
To fix it, I'd have to rewrite the planet rendering code to use vertex buffers instead of glDrawElements, which I'm not inclined to do right now (maybe later, tho).

Oy! This one becomes a mess. I started looking at the sources for Mesa. Honestly, the trail of that 3000 is ends with a seemingly arbitrary default that is supposed to be changed by the driver. The driver, however, does not. Instead, it deliberately picks the smallest, "safest" number it can during build time.

I modified the specific driver sources to a fixed 65535 but the value is coming from the Linux DRI, not the native one, and I can't rebuild sources for Linux. (Well, maybe I can under qemu, will try later) I did attempt to replace selectively 0x00000bb8 with 0x0000ffff in the appropriate linux binaries but couldn't find the right occurrences.

I will email the Mesa maintainer and see if I cannot get him to loosen it up (quite) a bit. From the looks of it, it's an overly paranoid default that grossly undersells the entire Radeon line's capabilties back to 7500 (r100).

I guess I just didn't notice it before.

There is a bright side. I discovered that EXA was responsible for a really annoying rendering bug.