I think I've seen someone report this issue for Intel hardware also.  Does
the problem still happen for you with current Fedora devel packages installed?
If so, can you please attach your X server log file and config file, as
individual uncompressed file attachments?

I'm very happy to see that this bug is getting some loving and attention and
hope that it can be fixed soon, I did a full yum update to rawhide yesterday and
this is what I get (again just like with 1.0.0):
[hans@shalem ~]$ ./glxgears 
libGL warning: 3D driver claims to not support visual 0x23
libGL warning: 3D driver claims to not support visual 0x24
libGL warning: 3D driver claims to not support visual 0x25
libGL warning: 3D driver claims to not support visual 0x26
libGL warning: 3D driver claims to not support visual 0x27
libGL warning: 3D driver claims to not support visual 0x28
libGL warning: 3D driver claims to not support visual 0x29
libGL warning: 3D driver claims to not support visual 0x2a
libGL warning: 3D driver claims to not support visual 0x2b
libGL warning: 3D driver claims to not support visual 0x2c
libGL warning: 3D driver claims to not support visual 0x2d
libGL warning: 3D driver claims to not support visual 0x2e
libGL warning: 3D driver claims to not support visual 0x2f
libGL warning: 3D driver claims to not support visual 0x30
libGL warning: 3D driver claims to not support visual 0x31
libGL warning: 3D driver claims to not support visual 0x32
./glxgears: Error: couldn't get an RGB, Double-buffered visual.
[hans@shalem ~]$ rpm -q xorg-x11-server-Xorg
xorg-x11-server-Xorg-1.0.1-1.x86_64
[hans@shalem ~]$ rpm -q mesa-libGL libdrm
mesa-libGL-6.4.1-5.x86_64
mesa-libGL-6.4.1-5.i386
libdrm-2.0-2.x86_64
libdrm-2.0-2.i386

I'll attach the requested logs. I would also like to offer my full assistence in
fixing this. <plug> I'm an experienced C-programmer myself. I do some packaging
for FE so I also now my way around SPECS and I've written a couple of kernel
drivers and in general have a reasonable degree of (general) hardware knowlede,
unnfortunatly my video HW knowledge is limited </plug> So feel free to ask
technical questions, to build custom rpm's etc.

Is there any chance you can help me get the 0.99.3-9 src rpm and / or a diff
between this and 1.0.1 ?

Created attachment 123946 [details]
xorg.conf

Created attachment 123947 [details]
xorg.log

With xorg-x11-drv-ati-6.5.7.3-3 I can turn on dri for my "ATI Radeon 9500 AD"
card and it does not crash and it even looks like it works.  At least I have
"(II) RADEON(0): Direct rendering enabled" and a display is indeed faster.

But I am seeing all these "No matching visual for __GLcontextMode with visual 
class = 1 (32774), nplanes = 32" messages, similar to those in the original
report, and every attempt to run anything using glx, say any program from
xscreensaver-gl-extras-4.23-1, ends up immediately with something like:

X error in klein:
X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  143 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Serial number of failed request:  163
  Current serial number in output stream:  164

There is a blink when a program window opens and it immediately is closing.

When running the same with a display on a remote I see a message:

libGL error: XF86DRIAuthConnection failed
libGL error: reverting to (slow) indirect rendering

and the program works - slowly.

On x86_64 machine mesa-libGL-6.4.1-5, mesa-libGLU-6.4.1-5, libdrm-2.0-2,
xorg-x11-server-Xorg-1.0.1-1, xorg-x11-drv-ati-6.5.7.3-3.

Is this the same problem or something new?

I shoud add to the above.  DRI works only if I have

        Option      "AGPMode" "8"

line in /etc/X11/xorg.conf.  Missing option, or some lower value than 8,
means an immediate X server lockup with a dead keyboard.  OTOH setting
"AGPFastWrite" option is also what should _not_ be done for a working server.

To add to comment #6.  After every failed attempt to run something from
xscreensaver-gl-extras I see in /var/log/Xorg.0.log a new line:

find_mesa_visual returned NULL for visualID = 0x0028

(In reply to comment #5)
> With xorg-x11-drv-ati-6.5.7.3-3 I can turn on dri for my "ATI Radeon 9500 AD"
> card and it does not crash and it even looks like it works.  At least I have
> "(II) RADEON(0): Direct rendering enabled" and a display is indeed faster.

The 2D driver will try to enable DRI, but the 3D driver isn't built, so
you don't actually get DRI.
 
> But I am seeing all these "No matching visual for __GLcontextMode with visual 
> class = 1 (32774), nplanes = 32" messages, similar to those in the original
> report, and every attempt to run anything using glx, say any program from
> xscreensaver-gl-extras-4.23-1, ends up immediately with something like:
[SNIP]
> Is this the same problem or something new?

Same problem.  Mesa is totally broken right now on all 64bit architectures
it turns out.  arlied investigated it yesterday, and IIRC the problem is
that either XSERVER64 or _XSERVER64 isn't getting defined or something like
that.  I imagine it'll be fixed before long though.  For now, disable DRI
on x86_64 and ia64.

*** Bug 176414 has been marked as a duplicate of this bug. ***

Disabling DRI does not help: the problem exists not only for hardware rendering
but for the software rendering as well.

I've added an experimental patch to mesa-6.4.2-2 which may resolve this
problem, once the X server is rebuilt against it.

It is a slightly modified version of the patch attached in the upstream
X.Org bug report found at:

https://bugs.freedesktop.org/show_bug.cgi?id=5835

Mesa isn't building properly in our buildsystem due to other issues however,
so it may be a day or so before the rpms are actually available.  I'll update
the bug report again once we have something built.

Ok, I got mesa-6.4.2-2 to build finally now, and am building a new
xorg-x11-server-1.0.1-5 package against the updated mesa.

Both packages should be available in rawhide in about 24 hours assuming
the server build succeeds.  Please test the new packages once they're
available, and provide an update to the report of your successes/failures.

Setting status to NEEDINFO_REPORTER, awaiting testing results.

I'm looking forward to having this bug fixed, thanks for the hard work.

xorg-x11-server-1.0.1-5 and mesa-6.4.2-2 are now available for download via ftp
at the following URL:  ftp://people.redhat.com/mharris/testing/unstable

I get different message now which may suggest that the original problem is gone:
freeglut (./datavisualiser): Unable to create direct context rendering for
window 'Marching Cubes'
This may hurt performance.
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  144 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  29
  Current serial number in output stream:  29

And the program stops (SiS hardware, no direct rendering driver is available). I
would run glxgears but I cannot find the right package.

Tested, seems to work ok. i've tested glxgears and ppracer, closing.

I think that closing that bug is a bit premature.  Indeed
xorg-x11-server-1.0.1-5 and mesa-6.4.2-2 mostly work which is a really big step
forward.  OTOH running various programs from xscreensaver-gl-extras I see
a constant stream of warnings of that sort:

*********************************WARN_ONCE*********************************
File r300_state.c function r300Enable line 456
TODO - double side stencil !
***************************************************************************
No ctx->FragmentProgram._Current!!
*********************************WARN_ONCE*********************************
File r300_render.c function r300_get_num_verts line 188
user error: Need more than 2 vertices to draw primitive QS !
***************************************************************************

"TODO" is "TODO" but the second one is repeated with various draw primiteves
and numbers of vertices ranging from 0 to 900 and something.  Some other
complaints also show up.

Warnings are just that but assorted programs from /usr/libexec/xscreensaver/
have a nasty habit of randomly locking up X server to such extent that
only reboot can clean that up even if a machine is still accesible over
a network.  This is not entirely predictable, I am afraid, although
/usr/libexec/xscreensaver/noof seems to be pretty good at it.  Running that
for a while looks like a reliable way to cause a lockup.  This may happen
with something else too but then I was unable to reliably repeat.

In /var/log/Xorg.0.log the following is recorded:

(EE) SIGIO not blocked at xf86eqEnqueue
(EE) SIGIO not blocked at xf86eqEnqueue
(EE) SIGIO not blocked at xf86eqEnqueue
(EE) SIGIO not blocked at xf86eqEnqueue
(EE) SIGIO not blocked at xf86eqEnqueue
(EE) SIGIO not blocked at xf86eqEnqueue

I am not sure if these errors are related to lockups.

Closing again, notice how the warnings are about r300, which DRI support is
experimental as mentioned in the mesa-xxx package changelog, also in this
changelog is that this support has been enabled to make it easier for users to
test and that all related bugs should go to freedesktop.org bugzilla.

M. Harris has already told you as much in an above comment, also all your
additions to this bug are pure noise. Please don't add seperate problems to an
already existing bugid, but start a new one, in this case on freedesktop.org .