Bug 5104 - Xorg 6.8.2 freeze computer when dri is enabled for a Radeon 7000
Xorg 6.8.2 freeze computer when dri is enabled for a Radeon 7000
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/other
XOrg git
Other FreeBSD
: highest blocker
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-20 17:38 UTC by Dan Angelescu
Modified: 2006-08-21 09:28 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Angelescu 2005-11-20 17:38:12 UTC
A FreeBSD-5.4 STABLE or RELEASE with Xorg 6.8 and dri enabled for an Radeon 
7000 VE QY freeze computer. 
 
A FreeBSD-5.4 STABLE or RELEASE with Xorg 6.7 and dri enabled for an Radeon 
7000 VE QY works fine. 
 
A FreeBSD-5.4 STABLE or RELEASE or a FreeBSD-6.0 STABLE or RELEASE with Xorg 
6.8 and dri enabled for an Radeon 7000 VE QY freeze computer. 
 
After those remarks i think that it is not a kernel problem. 
It is a Xorg 6.8 bug. 
 
All the best ! 
Hope it helps !
Comment 1 Michal Jaegermann 2005-12-27 09:59:54 UTC
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?
Comment 2 Michał Pytasz 2005-12-27 19:47:10 UTC
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) 
Comment 3 Stephen 2006-01-02 19:09:00 UTC
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.

Comment 4 Kåre Hviid 2006-01-09 19:15:57 UTC
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.
Comment 5 Stephen 2006-01-10 02:58:38 UTC
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.
Comment 6 Joel Franco 2006-02-17 09:49:19 UTC
(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 :(
Comment 7 Joachim Frieben 2006-02-17 19:53:12 UTC
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.
Comment 8 Michel Dänzer 2006-02-17 20:43:53 UTC
(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.
Comment 9 Joachim Frieben 2006-02-21 00:33:34 UTC
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!
Comment 10 jon perez 2006-04-16 20:29:43 UTC
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
Comment 11 Erik Andren 2006-07-28 08:37:03 UTC
Bug reporters, is this still an issue using a current version of xorg?
Comment 12 Michal Jaegermann 2006-07-28 10:45:15 UTC
> ... 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
Comment 13 Joachim Frieben 2006-07-29 03:19:34 UTC
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).
Comment 14 Joachim Frieben 2006-07-29 03:20:42 UTC
Sorry, I meant to write: ... where I had reported that a certain vendor specific
patch was the culprit.
Comment 15 Jerome Glisse 2006-07-29 07:22:37 UTC
This should be fixed. Reopen if you still experience this issue
with more recent version of xorg/dri/drm.
Comment 16 Stephen 2006-07-29 11:20:33 UTC
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.
Comment 17 Stephen 2006-07-29 16:40:33 UTC
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
Comment 18 Furrer 2006-08-16 11:41:16 UTC
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 ?
Comment 19 Michel Dänzer 2006-08-21 09:28:37 UTC
> 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.