Bug 25920 - r128 + 3d-acceleration + not enough memory = lock-up
Summary: r128 + 3d-acceleration + not enough memory = lock-up
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 7.1
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
: 25254 26518 26759 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-02-03 22:51 UTC by Alexei Podtelezhnikov
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-03-09 08:36:55 UTC
Embargoed:


Attachments (Terms of Use)
XF86Config-4 (3.71 KB, text/plain)
2001-03-09 08:29 UTC, Alexei Podtelezhnikov
no flags Details
XFree86.0.log (24.64 KB, text/plain)
2001-03-09 08:32 UTC, Alexei Podtelezhnikov
no flags Details
output of glxinfo (1.94 KB, text/plain)
2001-03-09 08:33 UTC, Alexei Podtelezhnikov
no flags Details

Description Alexei Podtelezhnikov 2001-02-03 22:51:23 UTC
First, 
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. 

Second,
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.

Actually,
I got this lock up earlier running as root, so it's not about "Mode 0601" 
thing. 

Plus, 
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-
up.

Comment 1 Alexei Podtelezhnikov 2001-02-07 08:58:26 UTC
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.

Comment 2 Mike A. Harris 2001-02-16 05:29:22 UTC
*** Bug 26518 has been marked as a duplicate of this bug. ***

Comment 3 Mike A. Harris 2001-02-16 05:29:51 UTC
*** Bug 26759 has been marked as a duplicate of this bug. ***

Comment 4 Mike A. Harris 2001-02-16 05:34:20 UTC
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.


Comment 5 Mike A. Harris 2001-02-19 13:33:07 UTC
*** Bug 25254 has been marked as a duplicate of this bug. ***

Comment 6 jens.koerber 2001-03-01 18:26:22 UTC
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-09/0433.html

should fix this ...




Comment 7 Alexei Podtelezhnikov 2001-03-06 08:11:17 UTC
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
Xfree86.config

There is another bug 28987 which might not be even related.

Comment 8 Mike A. Harris 2001-03-06 17:03:47 UTC
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.


Comment 9 Alexei Podtelezhnikov 2001-03-09 08:29:59 UTC
Created attachment 12166 [details]
XF86Config-4

Comment 10 Alexei Podtelezhnikov 2001-03-09 08:32:11 UTC
Created attachment 12167 [details]
XFree86.0.log

Comment 11 Alexei Podtelezhnikov 2001-03-09 08:33:37 UTC
Created attachment 12168 [details]
output of glxinfo

Comment 12 Alexei Podtelezhnikov 2001-03-09 08:36:46 UTC
An additional relevant dmesg output is attached to bug 28987 which is filed as 
a kernel bug.

Comment 13 Mike A. Harris 2001-03-17 18:41:24 UTC
Fixed with latest packages XFree 4.0.3 + Mesa 3.4-13 + latest kernel
in rawhide.

Comment 14 Alexei Podtelezhnikov 2001-03-21 20:34:02 UTC
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
soon).

Comment 15 Alexei Podtelezhnikov 2001-03-28 08:16:59 UTC
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.

Comment 16 Alexei Podtelezhnikov 2001-03-30 04:15:37 UTC
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 
however.


Note You need to log in before you can comment on or make changes to this bug.