The quick solution is to make the driver disable DRI by default internally
on PCI Radeon (like it is supposed to) unless ForcePCIMode is set. That will
prevent the lockup in the default configuration we provide.

The proper solution I want to implement, is both the above, as well as actually
making ForcePCIMode work.

A message from a user with the same problem on Radeon 7500 on x86.  Dunno
if his card is PCI or not, but I'm suspecting that.

https://listman.redhat.com/pipermail/xfree86-list/2002q1/000228.html

And others:

http://www.eyetap.org/~fungja/radeon/XFree86.0.log.dualradeon
http://www.geocrawler.com/archives/3/2634/2002/10/0/10013579

Now I tried with a real Built by ATI Radeon 7200 (1002:4144) PCI.

Same thing:

(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:2:4:0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xffffff00000ad000
(II) RADEON(0): [drm] mapped SAREA 0xffffff00000ad000 to 0x2a9556b000
(II) RADEON(0): [drm] framebuffer handle = 0xd8000000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(II) RADEON(0): [pci] 8192 kB allocated with handle 0x020b1000
(II) RADEON(0): [pci] ring handle = 0xffffff00020b1000
(II) RADEON(0): [pci] Ring mapped at 0x2a97ed9000
(II) RADEON(0): [pci] Ring contents 0x00000000
(II) RADEON(0): [pci] ring read ptr handle = 0xffffff00021b2000
(II) RADEON(0): [pci] Ring read ptr mapped at 0x2a9556d000
(II) RADEON(0): [pci] Ring read ptr contents 0x00000000
(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xffffff00021b3000
(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x2a97fda000
(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000
(II) RADEON(0): [drm] register handle = 0xe1000000
(II) RADEON(0): [dri] Visual configs initialized
(II) RADEON(0): CP in BM mode
(II) RADEON(0): Using 8 MB AGP aperture
(II) RADEON(0): Using 1 MB for the ring buffer
(II) RADEON(0): Using 2 MB for vertex/indirect buffers
(II) RADEON(0): Using 1 MB for AGP textures
(II) RADEON(0): Memory manager initialized to (0,0) (1600,5242)
(II) RADEON(0): Reserved area from (0,1200) to (1600,1202)
(II) RADEON(0): Largest offscreen area available: 1600 x 4040
(II) RADEON(0): Will use back buffer at offset 0xeaa000
(II) RADEON(0): Will use depth buffer at offset 0x15fd000
(II) RADEON(0): Will use 2752 kb for textures at offset 0x1d50000
(EE) RADEON(0): Idle timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...
(EE) RADEON(0): Idle timed out, resetting engine...

Note the Radeon 7200 above also works with Load DRI disabled.  It locks
up the X server with it "dri" loaded, and also with ForcePCIMode.  The latter
of which spews the "(EE) RADEON(0): Idle timed out, resetting engine..."
messages.

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

Just as a note for others who may be experiencing this problem, the only
officially supported hardware on AMD64 architecture currently is:

ATI Radeon 7500 AGP  (2D/3D)
Matrix G450 AGP      (2D/3D)
Matrox G550 AGP      (2D/3D)
Matrox G450 PCI      (2D only)

All other Radeon AGP hardware should work equally well, and will receive
the same level of support as Radeon problems tend to be model nonspecific.

All other video hardware is supported via community knowledge and as time
and resources permit.

3D on Radeon PCI hardware is not officially supported by Red Hat on any
architecture, and the Radeon DRI/PCI code is enabled only experimentally
for feedback such as these 2 bug reports, so that some day it can be
improved and be officially supported.

That said, I have personal motivations beyond our official hardware support
to see Radeon PCI hardware working in both 2D and 3D on x86/AMD64/alpha, and
hope to be able to spend some time hacking on it for the next release of the
OS.  I'll update this report with any status changes that happen.

I need to test this with current OS release and see if Radeon
PCI works now on AMD64 and x86.  It should, but I want to confirm
that, and if not file upstream bugs to track it.

Assigning to myself to test this, and follow through.

Adding to FC3Target tracker.

It should. we have shipped systems with PCI Radeons and they work. 
You may have to specifically tell it to use PCI mode though in 
xorg.conf. I will run a test with one of our Radeon 7000 PCIs and 
AMD86, if you'd like. 

Mark:

Sure, if you have a chance to test this out, that'd be
helpful!

In older releases you may have needed to specify ForcePCIMode,
but I've fixed the AGP/PCI detection in newer releases, so it
should work now.  If you find you still need to force PCI, please
let me know, as it should be something fixable.

Thanks.

Okay, I tried installing on an opteron system with Radeon 7000 PCI 
with 32MB of RAM. 
 
FC2 x86_64 installs fine and does setup PCI mode properly. Boots with 
DRI support working. 
 
FC3T2 x86_64 installs fine and does setup PCI mode properly. Boots 
with DRI support working. Interestingly enough I seem to get a 40% 
boost in glxgears performance from FC2 to FC3t2. Of course glxgears 
isn't a very good benchmark. 
 
I tried 32 bit version of FC2 but it didn't like my configuration 
that had nothing to do with the video though. 

Ok, thanks a lot for testing this Mark.  I'll close this bug as
fixed in Fedora Core 2 for now, and if anyone else can reproduce
it on any other hardware combination on AMD64/Radeon, if they
reopen it we will reinvestigate.

It sounds safe to assume it's resolved now.

Setting status to "CURRENTRELEASE" of FC2.

Thanks again.