Description of Problem:
Immediately after being started, Tuxracer crashes, and takes the whole system
with it. The system wouldn't respond to anything. Hard reset needed.
Version-Release number of selected component (if applicable):
Limbo2, no upgrade.
Steps to Reproduce:
1. Start Tuxracer from menu (BTW: why only under "All applications | Games"?)
Just at its first screen ("Press any key to start") it crashes. The music
continues to play, while the complete system is crashed.
Not that I know of.
which graphic card do you have in your machine? it sounds a bug in XFree86.
I assigned it to XFree86.
I have a SiS 630 video card, and didn't experience any other special things with
it so far. (detection etc. went without a problem)
Can you use some log file or so? Other information?
Required: X server log, X config file, and /var/log/messages file
as file attachments using the link below.
Also need "uname -a"
Created attachment 69364 [details]
X server log - XFree86.0.log
Created attachment 69365 [details]
X config file - XF86Config
Created attachment 69366 [details]
Ok, and this is the result of 'uname -a':
$ uname -a
Linux cambyses 2.4.18-7.80 #1 Tue Jul 23 18:20:11 EDT 2002 i686 unknown unknown
Anything else? ;)
I recommend reporting this problem to the DRI project via the dri-devel
mailing list, and also to firstname.lastname@example.org mailing list. You may want
to also email the SiS driver maintainer.
I have no SiS video hardware, or SiS 3D documentation, etc., and will
be unable to debug this problem. I can disable 3D acceleration for
this chipset by default for the final release though if you feel it
is unstable having DRI enabled by default.
I have carbon copied Alah Hourihane in case he might have hardware on
hand perhaps, or be able to troubleshoot.
Well, I have the hardware ;). If you can give me the instructions, I may be able
to help. (It doesn't really matter if it makes the system less stable, or if I
would need to re-install Limbo.)
About reporting it to other mailing lists and people: maybe it would be better
if you would do that, since you may be able to give a better description of the
If useful, I'd like to help, as long as I know how :).
Debugging a 3D acceleration problem is potentially quite complex, and
not something very easily done in a bug report. Other than having
the hardware in front of me, with gdb-xfree86, and able to locally
reproduce the bug, I can't really suggest much.
If you would like to debug the X server yourself, you can recompile
the XFree86 rpm by installing the src.rpm, editing XFree86.spec,
changing the DebuggableBuild line to read:
%define DebuggableBuild 1
Then recompile with rpm -bb XFree86.spec
You can get gdb-xfree86 from: ftp://people.redhat.com/mharris/gdb-xfree86
Replace your existing gdb with this version, and you can debug the
modular X server with it.
I can email the mailing list, but that wont do much good, since I
can only cut and paste what you've said above, and you can already
do that. Debugging something requires two way communication between
the person having the problem, and the person trying to fix the
problem. Having a middleman do it just wastes a lot of time, and
doesn't get anyone anywhere.
email@example.com is the mailing list to report 3D
acceleration related problems on.
I'm sorry, I wish there was something more I could do, but without
the hardware in hand to see it first hand, it is impossible to
debug an unknown problem without having any traceback or any useful
Defering bug until upstream has a fixed driver for this issue
FYI: I'm currently compiling XFree86 (it takes a lot of time)
Wouldn't the best thing be to disable DRI for this card when it's certain that
that's the cause? (Better no acceleration than buggy acceleration)
OK, rebuilt XFree86, installed it together with the special version of GDB, and
the problem seems *gone*. Tuxracer doesn't work optimally (the music sometimes
sounds bad, probably of debugging that slows down the system). The first time I
started Tuxracer, it looked bad, but after that, it works *ok*.
Maybe this bug is already solved in the version I'm currently running (is it
Hope this helps.
(null) still has still problem.. (My previous message suggests that this problem
is solved in Rawhide, but I haven't tried upgrading any packages yet. Would that
I defered this awaiting upstream investigation and/or fixes, but it
doesn't seem there is someone maintaining DRI support on SiS currently.
I'm not aware if this problem is still present in XFree86 4.3.0 or not
however SiS 3D support is more or less considered an "if it works, great,
if not, hopefully the community will fix it" sort of thing.
I've got no SiS hardware, nor specs, and there's no market-driving reason
to high prioritize 3D support on SiS. If it's still broken in 4.3.0,
I'll probably just patch the driver and kernel to remove support entirely
for it unless an upstream maintainer (Thomas?) is still interested in
Sorry, but there's nothing we can do here.