Bug 86157 - (hammer) Radeon PCI does not work with DRI enabled (the default)
(hammer) Radeon PCI does not work with DRI enabled (the default)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86 (Show other bugs)
1.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: Triaged
: 99252 (view as bug list)
Depends On:
Blocks: FC3Target
  Show dependency treegraph
 
Reported: 2003-03-14 20:39 EST by Mike A. Harris
Modified: 2007-04-18 12:52 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-29 19:23:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mike A. Harris 2003-03-14 20:39:35 EST
With a PCI Radeon 7000 made by Appian (Powered by ATI card), a default
configuration made by redhat-config-xfree86 configures the Radeon for
DRI operation.  Upon starting up the card with startx, X hangs, however
the machine does not hang.  It is pingable, and you can log in over ssh
just fine.

The X server log file ends with:


(**) Mouse0: Buttons: 5
(II) Keyboard "Keyboard0" handled by legacy driver
(II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE)
(II) Mouse0: ps2EnableDataReporting: succeeded
(EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020
(EE) RADEON(0): GetBuffer timed out, resetting engine...
(EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020
(EE) RADEON(0): RADEONCPGetBuffer: CP start -1020
(EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020
(EE) RADEON(0): GetBuffer timed out, resetting engine...


The above is repeated over and over endlessly until the log file fills
the hard disk.  It was 1Gb when I finally killed the X server.

Also to note is that this is a *default* configuration.  DRI should *NOT*
be getting enabled on PCI Radeon at all unless "ForcePCIMode" is turned
on in the config file.  In other words, the same config file setup that
enables DRI on an AGP Radeon card, should NOT enable it on a PCI one unless
ForcePCIMode is present.  This implies the ForcePCIMode flag is broken
in the server.  I had to comment out Load "dri" to prevent DRI from
starting up.
Comment 1 Mike A. Harris 2003-03-14 20:41:32 EST
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.
Comment 2 Mike A. Harris 2003-03-14 20:50:17 EST
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
Comment 3 Mike A. Harris 2003-03-14 21:05:55 EST
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...
Comment 4 Mike A. Harris 2003-03-14 21:09:00 EST
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.
Comment 5 Mike A. Harris 2003-07-16 16:09:50 EDT
*** Bug 99252 has been marked as a duplicate of this bug. ***
Comment 6 Mike A. Harris 2003-07-16 16:46:01 EDT
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.
Comment 7 Mike A. Harris 2004-09-24 18:10:50 EDT
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.
Comment 8 Mark Lane 2004-09-24 18:21:35 EDT
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. 
Comment 9 Mike A. Harris 2004-09-25 18:53:58 EDT
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.
Comment 10 Mark Lane 2004-09-29 14:43:55 EDT
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. 
Comment 11 Mike A. Harris 2004-09-29 19:23:51 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.