Red Hat Bugzilla – Bug 25920
r128 + 3d-acceleration + not enough memory = lock-up
Last modified: 2005-10-31 17:00:50 EST
Installing Fisher cleanly, my ATI AiW 128 PRO was recognised as Rage 128
(generic) which is probably fine since it worked on RH7. I did switch it
to a proper name, which I now guess doesn't really change anything. It
worked fine and I got Xfree86 running.
I noticed that there is no 3d hardware acceleration. I found appropriate
bug reports here. I added "Mode 0601" in XF86config-4. I tried it on an
xscreenserver blahblahblah3d. I got Xfree86 lock-up AS SOON AS I chose it
in GNOME Control Center, which probably wanted to show me a preview.
I got this lock up earlier running as root, so it's not about "Mode 0601"
I was able to run those screensavers and see previews without 3d-
acceleratiopn earlier as a user.
By "lock-up" here I mean
that I was not able to reboot cleanly at all. The only working thing was
mouse. Window manager died. I was just able to move the pointer not
clicking anything. I guess that kernel itself survived all this time
because I did hear some disk activity for a minute or two after the lock-
I found a lot similar reports on Xpert and DRI-devel mailing lists archives for
January-February. Suprisingly, I haven't seen a solution. My guess is that it
exists since important guys do not react on such bug reports.
*** Bug 26518 has been marked as a duplicate of this bug. ***
*** Bug 26759 has been marked as a duplicate of this bug. ***
This is a known issue with XFree86 4.0.2 and there is currently no
known fix. r128 DRI is broken, and the XFree team is still trying
to determine the problem. Currently DRI should be disabled in order
to use r128 cards.
*** Bug 25254 has been marked as a duplicate of this bug. ***
should fix this ...
The freshest combination of Xfree86-4.0.2-11.4.0 with recent kernel 2.4.2-
0.1.19 from rawhide still reveals this bug: 3D screensavers knock Xfree86 down.
It's now easily triggered by any user since "Mode 0666" was added by default to
There is another bug 28987 which might not be even related.
In addition to reading my annotation at #28987 on the latest RPM's, please
try the following: Quit X, log in from the console as root, and delete
the directory /dev/dri using "rm -rf /dev/dri". Now start the new X back
up again. If this doesn't fix it for you, I'm at a loss because all r128
cards work for me, and everyone else who has tested them with the latest
kernel + XFree packages.
Please supply an attachment of both your XF86config-4 and your X server log
as well. If you get a crash, please do a backtrace on the coredump. Also, if
your machine is overclocked, please clock it properly and try to reproduce.
If it still dies on you, please obtain a copy of the program 'memtest86' from
http://freshmeat.net or ftp://sunsite.unc.edu and do an extensive memory test
on your machine.
Created attachment 12166 [details]
Created attachment 12167 [details]
Created attachment 12168 [details]
output of glxinfo
An additional relevant dmesg output is attached to bug 28987 which is filed as
a kernel bug.
Fixed with latest packages XFree 4.0.3 + Mesa 3.4-13 + latest kernel
I keep having those lock-ups with all the recent rawhide updates (xf-4.0.3-1,
mesa-3.4-13, kernel-2.4.2-0.1.28). I'm not reopening this bug yet though. This
is just to clarify that this happens with
ALL-IN-WONDER card with r128 AND bttv (bttv829) chips.
This combination had problems before - "either TV or 3D, not both". I don't know
if those were addressed. I do want somebody to confirm or deny this bug using
All-in-Wonder 128 (PRO) card specifically.
I'll dig more to provide more info in a new and better bug report (comming
Okey. The final solution to my problem was to reduce depth of the color from 24
bpp to 16 bpp. No more lock-ups and 3d stuff is just great! This raised the
question - why the hell do anaconda and Xconfigurator offer 24 bpp as their
best depth? Solution to bug 33581 will probably answer this question.
It's all about memory. DRI requires 3-4 times more memory than usual 2d
display. 16 Mb card will lock up at 1280x1024x24bpp on 3d stuff because of lack
of memory. It happily does 3d-acceleration at 1280x1024x16bpp or 1024x768x24bpp