Red Hat Bugzilla – Full Text Bug Listing
|Summary:||tuxracer crashes at startup|
|Product:||[Retired] Red Hat Public Beta||Reporter:||Taco Witte <info>|
|Component:||XFree86||Assignee:||Mike A. Harris <mharris>|
|Status:||CLOSED WONTFIX||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-03-14 20:14:19 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 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 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.
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. 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 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.