I see approximately the same with ATI Radeon 9500 AD (AGP) card on Linux,
x86_64 hardware, and 6.99.99.904 (7.0.0 RC 4) server.

A machine is not precisely frozen as a remote login is still possible but a local
console presents a blank screen, a dead keyboard and X server is _really_ busy
taking around 99% of CPU.  If one would believe only in logs then everything
is just great -

...........
(II) RADEON(0): [drm] installed DRM signal handler
(II) RADEON(0): [DRI] installation complete
(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers
(II) RADEON(0): [drm] dma control initialized, using IRQ 217
(II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808
(II) RADEON(0): Direct rendering enabled
...........

only not much works.  Turning off dri provides a working X server
using 'radeon' driver but a rather slow one.

Also when dri is turned on I see in logs a bunch of messages like that:

No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 32

With dri turned off they are replaces with:

No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes =
4294967295

The last number is 0xffffffff, which probably was meant to be -1, only
on a 64-bit machine is not.  Only a bad format on a printout or something more?

Hi, 
 
For me it also does not seem BSD and xorg 6.8.2 specific. It would be more like 
a R300 driver problem. I have linux gentoo: 
$ uname -a 
Linux pytasz 2.6.14-gentoo-r5 #1 PREEMPT Fri Dec 23 15:23:53 CET 2005 x86_64 
AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux 
with gcc: 
$ gcc -v 
Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/specs 
Configured with: /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/configure 
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.4 
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/include 
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4 
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4/man 
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4/info 
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/include/g++-v3 
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec 
--enable-nls --without-included-gettext --with-system-zlib --disable-checking 
--disable-werror --disable-libunwind-exceptions --enable-multilib 
--disable-libgcj --enable-languages=c,c++,f77 --enable-shared 
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu 
Thread model: posix 
gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8) 
Xorg x11r7.0.0 and drm module built from dri cvs in the day of xorg 7.0.0 
release. 
 
When direct rendering is disabled (I do it through not loading glx) xorg with 
kde are working fine, but when dri gets enabled it seems to slow down very 
badly. kdm does not complete drawing login window, mouse is moving, but 
clicking on password does not bring any (immediate) result. However after 
typing some characters they appear after a few minutes. Only way to get out of 
it is through ACPI power button, but shutdown takes 5-10 min. instead of less 
than a minute. There is nothing unusual in dmesg, there is one thing in 
Xorg.0.log: 
 
(II) RADEON(0): X context handle = 0x1 
(II) RADEON(0): [drm] installed DRM signal handler 
(II) RADEON(0): [DRI] installation complete 
(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers 
(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers 
(II) RADEON(0): [drm] dma control initialized, using IRQ 16 
(II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808 
(II) RADEON(0): Direct rendering enabled 
(==) RandR enabled 
(II) Initializing built-in extension MIT-SHM 
(II) Initializing built-in extension XInputExtension 
(II) Initializing built-in extension XTEST 
(II) Initializing built-in extension XKEYBOARD 
(II) Initializing built-in extension LBX 
(II) Initializing built-in extension XC-APPGROUP 
(II) Initializing built-in extension SECURITY 
(II) Initializing built-in extension XINERAMA 
(II) Initializing built-in extension XFIXES 
(II) Initializing built-in extension XFree86-Bigfont 
(II) Initializing built-in extension RENDER 
(II) Initializing built-in extension RANDR 
(II) Initializing built-in extension COMPOSITE 
(II) Initializing built-in extension DAMAGE 
(II) Initializing built-in extension XEVIE 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 
16 
 
Whan X is "hanging" I can ssh to the machine, but it is very slow then 
(probably high cpu consumption) 

I have the same problem. X.org 6.8.2 on Debian Linux unstable freezes with a
Radeon 7000. I tried it in 32-bit and 64-bit mode on my amd64 dual opteron with
the same results.

For what it's worth - and this might be totally unrelated to the problem
described here - I had a similar problem with my 9200 (non-SE) RV280 card
on amd64 2.6.15 on an ASUS K8V-F MB (VIA chipset) with Debian xserver-xorg
6.9.0.dfsg.1-2.  It appears that if the glx module is enabled, the default
AGPMode will cause problems.  Forcing the AGPMode helped, by setting this
in the Section "Device":

    Option   "AGPMode"  "8"

I have also had a report where this helped on a 9600 card.

I've tried manually setting AGPMode, turning off all BIOS AGP features, etc. to
no avail. MSI Master2-FAR (VIA K8T800 chipset). I suspect it has something to do
with the R100's not liking the dynamic clocks patch, but frankly I have no idea.

(In reply to comment #1)
> A machine is not precisely frozen as a remote login is still possible but a local
> console presents a blank screen, a dead keyboard and X server is _really_ busy
> taking around 99% of CPU.  If one would believe only in logs then everything
> is just great -

i have exactly the same symptons. Radeon Onboard PCI 7000M/Debian testing/linux
2.6.14.5/Xorg6.9. Disabling "glx" runs, but a lot slow :(

I had submitted a related bug report for a Fedora system:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180150

Here, the culprit is a Radeon RV100 bus master fix patch
by Red Hat. It seems to me that it got merged upstream in
"Xorg" CVS such that since 6.8.99.x other distros are
affected, too. My graphics card is a Radeon 7200 PCI based
upon the R100 QD chip.

(In reply to comment #7)
> 
> Here, the culprit is a Radeon RV100 bus master fix patch
> by Red Hat. It seems to me that it got merged upstream in
> "Xorg" CVS such that since 6.8.99.x other distros are
> affected, too.

See bug 3911. This has been fixed in xf86-video-ati CVS. A derived minimal fix
that can be backported to X.Org releases down to 6.8 is being developed in bug 5916.

Hi Michel. Thanks a lot for your hint. I applied your patch to both "Xorg"
version 6.8.2 and 6.9.0 on my FC4 box. In both cases, it allows to boot up the
machine into graphical mode with enabled "DRI". Before, it would hang when "gdm"
was about to be started. Excellent!! This patch is a **must** both for upcoming
"Xorg" releases 6.8.3 and 6.9.1!

I'm getting a complete freeze (remote logins not working, and routing stops as
well) on the Radeon 7000 as well with DRI enabled.  The freeze occurs within a
minute upon running an OpenGL program such as gears.

Not using a framebuffer console or changing/lowering resolution bit-depths do
not make a difference.

Xorg 6.8.2
Radeon VE/7000 QY
SiS735 motherboard
Linux 2.6.13
Slackware 10.2

Bug reporters, is this still an issue using a current version of xorg?

> ... is this still an issue using a current version of xorg?

I did not see the problem for quite a while with this exception
that if I will not follow an advice from comment #4 about "AGPMode"
then I have no keyboard, a dark screen and an X server eating up 99%
of CPU.  More details at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194105

In my case, the issue was due to a Red Hat patch (backported from upstream) to
stabilize hardware rendering on Radeon 7xxx hardware. See this link:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180150

and in particular comments #5 and #14 where I had reported that removing a
certain vendor specific patch was the culprit. There was a later update upstream
by M. Dänzer documented at:

  https://bugs.freedesktop.org/show_bug.cgi?id=4324

which fixed the issue for me (dropping the patch as a whole also worked).

Sorry, I meant to write: ... where I had reported that a certain vendor specific
patch was the culprit.

This should be fixed. Reopen if you still experience this issue
with more recent version of xorg/dri/drm.

I'm still locking up with DRI turned on. Hardware is the same as before.

xserver-xorg  7.0.22
xserver-xorg-video-ati (1:6.5.8.0-1)
official Debian SMP 2.6.17 amd64 linux kernel

I don't know how to remove any busmaster patches if there is one in the debian
package.

Aha. I finally learned about this 'netconsole' thing.
---
HARDWARE ERROR
HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
CPU 0 4 northbridge TSC 677907138e
  Northbridge Watchdog error
       bit57 = processor context corrupt
       bit61 = error uncorrected
  bus error 'generic participation, request timed out
      generic error mem transaction
      generic access, level generic'
STATUS b200000000070f0f MCGSTATUS 4
This is not a software problem!
Run through mcelog --ascii to decode and contact your hardware vendor
Kernel panic - not syncing: Machine check
---

Not sure what that means, but that's the problem I'm having with DRI.
-s

I have the same problem: random freezes, persisting after disabling the module
dri in my xorg.conf, although they seem to be much less frequent.

My problem was better described in bug #6429, but the bugs have apparently been
merged.

I have a Sony Vaio Laptop with a Radeon Mobility M6 LY card running under the
beta2 version of Debian etch, ie kernel 2.6.15-1-486.

xserver-xorg  7.0.22
xserver-xorg-video-ati (1:6.5.8.0-1)

My questions are:
1) Do I need to disable the module glx as well?
2) Do I need to update a driver? (What I understood from the thread is that mine
is pretty current, but I do not understand everything that has been told.)
3) Will there be a version of the driver which allows to enable dri and glx? Or
should this already work ?

> I have the same problem: random freezes, persisting after disabling the
> module dri in my xorg.conf, although they seem to be much less frequent.
>
> My problem was better described in bug #6429, but the bugs have apparently
> been merged.

Note that both are about DRI enabled, so if you're seeing the same symptoms with
it disabled, you're probably having a different problem.


> 1) Do I need to disable the module glx as well?

No, not loading the "dri" module should disable the DRI. Double-check it in the
log file though.

> 2) Do I need to update a driver? (What I understood from the thread is that
> mine is pretty current, but I do not understand everything that has been
> told.)
> 3) Will there be a version of the driver which allows to enable dri and glx?
> Or should this already work ?

The widely reported issue with DRI enabled should be fixed with current
xf86-video-ati git.