Bug 70977 - tuxracer crashes at startup
Summary: tuxracer crashes at startup
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: XFree86
Version: limbo
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-08-07 15:08 UTC by Taco Witte
Modified: 2008-05-01 15:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-03-15 01:14:19 UTC
Embargoed:


Attachments (Terms of Use)
X server log - XFree86.0.log (28.83 KB, text/plain)
2002-08-07 20:39 UTC, Taco Witte
no flags Details
X config file - XF86Config (2.95 KB, text/plain)
2002-08-07 20:40 UTC, Taco Witte
no flags Details
/var/log/messages (51.44 KB, text/plain)
2002-08-07 20:42 UTC, Taco Witte
no flags Details

Description Taco Witte 2002-08-07 15:08:05 UTC
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 18:58:10 UTC
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 20:21:38 UTC
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 20:26:45 UTC
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 20:39:56 UTC
Created attachment 69364 [details]
X server log - XFree86.0.log

Comment 5 Taco Witte 2002-08-07 20:40:46 UTC
Created attachment 69365 [details]
X config file - XF86Config

Comment 6 Taco Witte 2002-08-07 20:42:24 UTC
Created attachment 69366 [details]
/var/log/messages

Comment 7 Taco Witte 2002-08-07 20:43:47 UTC
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 15:51:51 UTC
I recommend reporting this problem to the DRI project via the dri-devel
mailing list, and also to xpert 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 20:29:49 UTC
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 21:28:35 UTC
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.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 10:56:29 UTC
Defering bug until upstream has a fixed driver for this issue

Comment 12 Taco Witte 2002-08-16 11:00:49 UTC
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 12:15:48 UTC
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 13:49:09 UTC
(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-15 01:14:19 UTC
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.  


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