Bug 6111

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.