Using dri and the radeon driver for ATI Radeon 9200 PRO on AMD64 freezes the system about 30 minutes after startx. There are no relevant errors in /var/log/Xorg.0.log or /var/log/messages I run Gentoo Linux. The X version is the Modular X one from portage (7.0-r1): # X -version X Window System Version 7.0.0 Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 7.0 Build Operating System:Linux 2.6.15-gentoo-r5 x86_64 Current Operating System: Linux localhost 2.6.15-gentoo-r5 #4 Wed Feb 22 23:10:06 CET 2006 x86_64 Build Date: 03 March 2006 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present The same happens using xorg-x11-6.8.2-r6 Using Modualr X the problem occurs after about 30 minutes. Using xorg-x11-6.8.2-r6 is takes only 10 minutes.
Created attachment 4809 [details] The xorg.conf used.
Created attachment 4810 [details] Xorg.0.log
I wouldn't expect it to make a difference, but why are you using forced PCI mode? Your nforce3 chipset should work just fine with the amd64-agp module. I assume it locks up with 24bit depth too? There are fixes which should help against lockups in xorg cvs, though afaik they wouldn't fix lockups only occuring after some time.
(In reply to comment #3) > I wouldn't expect it to make a difference, but why are you using forced PCI > mode? Your nforce3 chipset should work just fine with the amd64-agp module. > I assume it locks up with 24bit depth too? > There are fixes which should help against lockups in xorg cvs, though afaik they > wouldn't fix lockups only occuring after some time. I tried to work around the bug in several ways. It made no difference. I only forgot to remove it.
Any info you want? Any idea to try?
I have been seeing a similar thing today trying to get an AGP Radeon 9200 working with DRI on an AMD64 box. This is under FC4 with Xorg 6.8.2 and with Kernels 2.6.16.1 and 2.6.16-git18 With DRI disabled in Xorg everything is fine. When enabling DRI the system will lock up (or X at least, I need to check that the machine is still accessible from the network) with in a minute or so. I have tried forcing AGPMode down to 2. I am running with 24bpp. One curious thing is this from dmesg: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0. agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode. agpgart: X requested AGPx8 but bridge not capable. agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode [drm] Loading R200 Microcode and from lspci: 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01) 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) (rev 01) The bus id's don't seem to match up. (I understand that the second entry is there purely for Windows) Tommorrow I'm going to try disabling TCL.
(In reply to comment #6) ... > One curious thing is this from dmesg: > > agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0. > agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode. > agpgart: X requested AGPx8 but bridge not capable. > agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode > agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode > [drm] Loading R200 Microcode In dmesg I only got the last of those lines. But the line is repeated several times. > and from lspci: > > 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] > (rev 01) > 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] > (Secondary) (rev 01) > > The bus id's don't seem to match up. (I understand that the second entry is > there purely for Windows) ... Same here for lspci except it says "Radeon 9200 PRO" not "Radeon 9200 SE".
OK, disabling TCL didn't help. It is just X which is locking up, though it doesn't consume any CPU in this state. However when attempting to kill X, the machine does then lock up.
(In reply to comment #8) > OK, disabling TCL didn't help. > > It is just X which is locking up, though it doesn't consume any CPU in this > state. However when attempting to kill X, the machine does then lock up. > Any idea what the problem is? Do you need more information or want me to test something?
I have the same problem with my Radeon Mobile M200. I'm on Mandrive 2006, gcc-3.3, xorg-6.9.0 (dec 12 '05), kernel 2.6.12. The screen stays black after starting X with DRI. Keyboard keys seem to work (some disk activity), but I haven't been able to reboot with alt+sysrq+(r|s|e| i|u|b). running glxgears withouth DRI yields a segfault, and some mention of /usr/X11R6/lib64/libGL.so.1
(In reply to comment #10) > I have the same problem with my Radeon Mobile M200. Same symptoms != same problem. DRI support isn't fully implemented yet for your chipset. As for the others, I'd suggest trying not specifying any AGP or DRI related driver options, xf86-video-ati 6.5.8 or 6.6.0 and the DRM from DRI CVS, in this order.
Did Michael's suggestion resolve your issue?
I'm now running Fc5, problem remains. I did try a later ati driver (can't remember which one). It's my work machine so I can't have it broke too much. I was going to look at it again with Xorg 7.1, which I believe comes with the ati 6.6.x driver. Seems like FC5 will be getting an update to Xorg 7.1. So I may be able to try again sooner rather than later. Things do work fine on my FC4 machine at home, Athlon, Radeon 9200, running dual head. I can start up a second X server with DRI and play Quake III. Maybe it's some 64bit issue... Cheers, Andrew
I have the same error, my Xorg.log is full of this message: (EE) RADEON(0): RADEONWaitForIdleCP: CP idle -1022 (EE) RADEON(0): Idle timed out, resetting engine... (**) RADEON(0): EngineRestore (32/32) I use ATi Radeon 9200 AGP, Athlon XP 1,6 GHz, Ubuntu Dapper and this: - Kernel: 2.6.15-26-386 - DRI Drivers from xgl.compiz.info (20060726-0aiglx~compiz1) - X.org 7.0.0-0ubuntu45 My monitor goes black, and it comes randomly. I'll have to use propietary drivers. :(
neok: Have you tried the suggestions from comment #11? Your kernel and X.Org versions are oldish.
X freezes immediately after start. Without DRI enabled it works ok. Card: Radeon 9250 Driver: radeon ----- X Window System Version 7.1.1 Release Date: 12 May 2006 X Protocol Version 11, Revision 0, Release 7.1.1 Build Operating System: Linux 2.6.9-34.ELsmp i686 Red Hat, Inc. Current Operating System: Linux cs78144095.pp.htv.fi 2.6.17-1.2517.fc6 #1 SMP Thu Aug 3 05:00:47 EDT 2006 i686 Build Date: 30 August 2006 Build ID: xorg-x11-server 1.1.1-32.fc6 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present ----- Linux 2.6.17-1.2517.fc6 #1 SMP Thu Aug 3 05:00:47 EDT 2006 i686 athlon i386 GNU/Linux ----- processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 31 model name : AMD Athlon(tm) 64 Processor 3200+ ----- 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01) Subsystem: ASUSTeK Computer Inc. Unknown device 004d Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (2000ns min), Cache Line Size: 32 bytes Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M] Region 1: Memory at fbf00000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Created attachment 6748 [details] xorg.conf
Created attachment 6749 [details] Xorg.0.log
(In reply to comment #16) > X freezes immediately after start. Without DRI enabled it works ok. What if you enable the DRI but disable AIGLX? Can you log in remotely after this happens? If so, is the X server process still running? If not, can you start a new X server? ...
(In reply to comment #19) > What if you enable the DRI but disable AIGLX? Didn't help. > Can you log in remotely after this happens? Yes. Seems to work ok. > If so, is the X server process still running? Yes it is. Xorg process consumes 100% of CPU.
(In reply to comment #20) Can you also attach the output of dmesg?
Created attachment 6751 [details] dmesg
(In reply to comment #22) Thanks. Looks more like an issue of the kernel with your AGP bridge. Does it work with Option "BusType" "PCI"?
(In reply to comment #23) > Thanks. Looks more like an issue of the kernel with your AGP bridge. Does it > work with Option "BusType" "PCI"? Yes, now it works without problem. Thanks _a lot_ ! I should have figured this out myself. Sorry for wasting your time :-|.
(In reply to comment #23) > (In reply to comment #22) > > Thanks. Looks more like an issue of the kernel with your AGP bridge. Does it > work with Option "BusType" "PCI"? I'm having this same error with my new Sapphire Radeon 9250 256MB and setting BusType to "PCI" allows Direct Rendering to work. I can only assume direct rendering is broken with AGP on my hardware. I am using the very latest Debian unstable (2006-09-21) with latest Debian 2.6.17 SMP amd64 kernel. I am using the latest git kernel modules (drm.ko and radeon.ko). Hardware: 2 x Opteron 244 (SMP, amd64 kernel & userland) MSI K8T Master2-FAR (VIA K8T8000 chipset) Sapphire Radeon 9250 4 x DDR-333 512MB Here's 'dmesg' from when I get the 100% CPU usage: [drm] Initialized drm 1.0.1 20051102 ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 177 mtrr: type mismatch for 4000000,2000000 old: write-back new: write-combining [drm] Initialized radeon 1.25.0 20060524 on minor 0: agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0. agpgart: Device is in legacy mode, falling back to 2.x agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode [drm] writeback test succeeded in 1 usecs During the 100% CPU, I get this over and over in strace on X: --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xe) = -1 EBUSY (Device or resource busy) ioctl(6, 0xc0406429, 0x7fffacceffc0) = -1 EBUSY (Device or resource busy) Thanks for any help! -s
I've similar freezes with a serverworks CNB20HE chipset (unsupported in linux) but they may be very well unrelated. My "fix" is not to allow sworks_agp.ko to load by removing it (although the modules doesn't supports my chipset due to lack of documentation). This causes DRI to fail and disable, it makes X.org be much slower in things like ie: scrolling a web page or waiting gdm to draw the initial login screen, but at least it's stable.
(oh, and forcing "BusType" "PCI" doesn't fix it)
(In reply to comment #27) > (oh, and forcing "BusType" "PCI" doesn't fix it) I think this is a different bug, then. I don't get a true freeze -- Xorg goes up to 100% CPU and since it's a dual proc box, I can log in with ssh, kill off some X stuff, restart gdm, and be back to where I started, most of the time. X will eventually lock the box with enough reloads or if I let it peg the CPU continuously. I have noticed that my Debian amd64 kernel does not come with amd64-agp.ko... I plan on filing a bug against it.
Just tried the BusType PCI workaround and that seems to also work for me. I've opened a kernel bugzilla for this... http://bugzilla.kernel.org/show_bug.cgi?id=7273
The debian 2.6.18 kernel gave me a nice message yesterday (near the top of dmesg) stating that the AGP aperture was too small. So, I went into the BIOS and made the aperture 64MB. X now works with DRI over AGP. Yay. -s
As per http://bugzilla.kernel.org/show_bug.cgi?id=7273 my current setup with AGP is stable.
Closing this bug, reopen if you have same issue with recent mesa,xf86-video-ati,kernel.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.