|Summary:||(hammer) Radeon PCI does not work with DRI enabled (the default)|
|Product:||[Retired] Red Hat Raw Hide||Reporter:||Mike A. Harris <mharris>|
|Component:||XFree86||Assignee:||Mike A. Harris <mharris>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-09-29 23:23:51 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Mike A. Harris 2003-03-15 01:39:35 UTC
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-15 01:41:32 UTC
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-15 01:50:17 UTC
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-15 02:05:55 UTC
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-15 02:09:00 UTC
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 20:09:50 UTC
*** Bug 99252 has been marked as a duplicate of this bug. ***
Comment 6 Mike A. Harris 2003-07-16 20:46:01 UTC
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 22:10:50 UTC
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 22:21:35 UTC
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 22:53:58 UTC
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 18:43:55 UTC
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 23:23:51 UTC
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.