Bug 70977

Summary: tuxracer crashes at startup
Product: [Retired] Red Hat Public Beta Reporter: Taco Witte <info>
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED WONTFIX QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: limboCC: alanh, than
Target Milestone: ---Keywords: MoveUpstream
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-03-14 20:14:19 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
X server log - XFree86.0.log
none
X config file - XF86Config
none
/var/log/messages none

Description Taco Witte 2002-08-07 11:08:05 EDT
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.

How Reproducible:
Always.

Steps to Reproduce:
1. Start Tuxracer from menu (BTW: why only under "All applications | Games"?)

Actual Results:
Just at its first screen ("Press any key to start") it crashes. The music
continues to play, while the complete system is crashed.

Expected Results:
:)

Additional Information:
Not that I know of.
Comment 1 Ngo Than 2002-08-07 14:58:10 EDT
which graphic card do you have in your machine? it sounds a bug in XFree86.
I assigned it to XFree86.
Comment 2 Taco Witte 2002-08-07 16:21:38 EDT
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?
Comment 3 Mike A. Harris 2002-08-07 16:26:45 EDT
Required:  X server log, X config file, and /var/log/messages file
as file attachments using the link below.

Also need "uname -a"
Comment 4 Taco Witte 2002-08-07 16:39:56 EDT
Created attachment 69364 [details]
X server log - XFree86.0.log
Comment 5 Taco Witte 2002-08-07 16:40:46 EDT
Created attachment 69365 [details]
X config file - XF86Config
Comment 6 Taco Witte 2002-08-07 16:42:24 EDT
Created attachment 69366 [details]
/var/log/messages
Comment 7 Taco Witte 2002-08-07 16:43:47 EDT
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
GNU/Linux

Anything else? ;)
Comment 8 Mike A. Harris 2002-08-15 11:51:51 EDT
I recommend reporting this problem to the DRI project via the dri-devel
mailing list, and also to xpert@xfree86.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.



Comment 9 Taco Witte 2002-08-15 16:29:49 EDT
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
problem.

If useful, I'd like to help, as long as I know how :).
Comment 10 Mike A. Harris 2002-08-15 17:28:35 EDT
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.

dri-devel@dri.sourceforge.net 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
debugging info.

Comment 11 Mike A. Harris 2002-08-16 06:56:29 EDT
Defering bug until upstream has a fixed driver for this issue
Comment 12 Taco Witte 2002-08-16 07:00:49 EDT
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)
Comment 13 Taco Witte 2002-08-16 08:15:48 EDT
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
from rawhide?).
Hope this helps.
Comment 14 Taco Witte 2002-08-21 09:49:09 EDT
(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
be useful?)
Comment 15 Mike A. Harris 2003-03-14 20:14:19 EST
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
maintaining it.

Sorry, but there's nothing we can do here.