Bug 6111

Summary: ATI Radeon 9200 freezes using dri
Product: DRI Reporter: Arvid Norlander <anmaster>
Component: GeneralAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: blocker    
Priority: highest CC: andrew, dberkholz, debian, diegocg
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
URL: https://bugs.gentoo.org/124657
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
The xorg.conf used.
none
Xorg.0.log
none
xorg.conf
none
Xorg.0.log
none
dmesg none

Description Arvid Norlander 2006-03-04 02:48:51 UTC
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.
Comment 1 Arvid Norlander 2006-03-04 02:49:18 UTC
Created attachment 4809 [details]
The xorg.conf used.
Comment 2 Arvid Norlander 2006-03-04 02:50:26 UTC
Created attachment 4810 [details]
Xorg.0.log
Comment 3 Roland Scheidegger 2006-03-04 03:14:46 UTC
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.
Comment 4 Arvid Norlander 2006-03-04 03:25:29 UTC
(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.
Comment 5 Arvid Norlander 2006-03-04 10:33:06 UTC
Any info you want? Any idea to try?
Comment 6 Andrew Clayton 2006-03-31 05:42:53 UTC
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.
Comment 7 Arvid Norlander 2006-03-31 06:08:53 UTC
(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".
Comment 8 Andrew Clayton 2006-03-31 19:53:15 UTC
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.
Comment 9 Arvid Norlander 2006-05-05 18:03:12 UTC
(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?
Comment 10 mark 2006-06-02 14:47:44 UTC
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 
 
  
Comment 11 Michel Dänzer 2006-06-03 02:05:19 UTC
(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.
Comment 12 Erik Andren 2006-07-28 10:08:11 UTC
Did Michael's suggestion resolve your issue?
Comment 13 Andrew Clayton 2006-07-28 11:01:40 UTC
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
Comment 14 Fran 2006-08-21 11:09:15 UTC
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. :(
Comment 15 Michel Dänzer 2006-08-26 04:09:07 UTC
neok: Have you tried the suggestions from comment #11? Your kernel and X.Org
versions are oldish.
Comment 16 Joe Smirlo 2006-08-30 08:23:39 UTC
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-
Comment 17 Joe Smirlo 2006-08-30 08:26:41 UTC
Created attachment 6748 [details]
xorg.conf
Comment 18 Joe Smirlo 2006-08-30 08:27:21 UTC
Created attachment 6749 [details]
Xorg.0.log
Comment 19 Michel Dänzer 2006-08-30 08:36:21 UTC
(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? ...
Comment 20 Joe Smirlo 2006-08-30 09:23:43 UTC
(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.
Comment 21 Michel Dänzer 2006-08-30 10:02:05 UTC
(In reply to comment #20)

Can you also attach the output of dmesg?
Comment 22 Joe Smirlo 2006-08-30 10:27:19 UTC
Created attachment 6751 [details]
dmesg
Comment 23 Michel Dänzer 2006-08-30 10:51:00 UTC
(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"?
Comment 24 Joe Smirlo 2006-08-30 11:05:10 UTC
(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 :-|.
Comment 25 Stephen 2006-09-21 21:46:09 UTC
(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
Comment 26 Diego Calleja 2006-09-22 07:26:11 UTC
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.
Comment 27 Diego Calleja 2006-09-22 07:27:28 UTC
(oh, and forcing "BusType" "PCI" doesn't fix it)
Comment 28 Stephen 2006-09-22 08:03:45 UTC
(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.
Comment 29 Andrew Clayton 2006-10-06 08:17:03 UTC
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
Comment 30 Stephen 2006-10-26 07:19:26 UTC
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
Comment 31 Andrew Clayton 2007-02-01 02:11:44 UTC
As per http://bugzilla.kernel.org/show_bug.cgi?id=7273 my current setup with AGP is stable.
Comment 32 Jerome Glisse 2009-05-20 05:41:31 UTC
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.