Bug 37079
Summary: | XFree86 and AGP Voodoo3 on Athlon system crashes running 3D accel apps, switching to console from X causes video death | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Scott Dowdle <dowdle> |
Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | jcw |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2001-05-03 23:48:42 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Scott Dowdle
2001-04-22 17:49:34 UTC
Created attachment 16026 [details]
Full /var/log/XFree86.x.log
Hi, I have exactly same problem with XF-4.0.3 and 3dfx voodoo3 2000 PCI card. Till the fix arrives, I modified the /etc/X11/XF86Config-4 to disable "extmod" oading in the Section "Module" -> #SubSection "extmod" #Option "omit xfree86-dga" #EndSubSection This got rid of the x-server crash, presumably at the cost of acceleration. - Nil (ndeb.edu) Well, I got it working. Don't ask me WHY this works but it does. I simply put the system into runlevel 3 and run startx from the console. Seems to work then. I don't think there is a conflict in services running in 5 verses 3 because they are identical (to the best of my knowledge) except for kdm. A tip for artsd users: use "artsdsp -m program-name" if you want sound to work with apps such as q3demo. Some apps work without it though. Oh, BTW chmod 5755 (SUID root) for /usr/bin/artswrapper makes realtime mode work. Reduce latency (in the KDE arts settings) to about 81ms and multitasked sound is basically realtime. tuxracer and q3demo now work... just don't run kdm I'm not sure if it is related to kdm or if it would have a similiar problem if gdm were running instead?!? Oddly enough, this same problem happened on a K6-2 machine with a Voodoo 3 2000 PCI and the same fix worked... so I don't think it is related to the hardware although who knows. I too have this problem. I attached both an strace and then an ltrace to the running XFree86 server and then caused a crash by switching video modes (CTRL-ALT-+). Both resulting traces show SIGSEGV (Segmentation fault)'s. I'm going to try that 'extmod' hack mentioned earlier, but I wanted to get this in while I had the bug (bugzilla #37079) in front of me. If anyone wants to see the output from the traces, email me at jcw and I'll send them to you (they're only ~30-40Kbytes each). I'll report back how that 'extmod' hack worked. thx... -- jcw I'm back. Said I would be 8^). Turns out that 'extmod' disable hack on XF86Config helps. I can now switch console resolutions (CTRL-ALT-+) without killing the Xserver, and the 3D game (quake3) comes up, but only in a window. It won't do full screen. Probably due to disabling 'extmod'. Ya think? The error I get from the game when it tries to go fullscreen is: Xlib: extension "XFree86-VidModeExtension" missing on display ":0.0" So whoever's investigating this bug should start looking there. I'll be watching. Wish I could help, but I'm just a Sysadmin, not a programmer. I still have those traces of the Xserver crashing if anyone's interested (30-40Kbytes). thx.... -- jcw Created attachment 17266 [details]
Here's an strace attached to XFree86 just before the crash
Created attachment 17267 [details]
And here's an ltrace, also attached to the process just before initiating the crash
More helpful information 8^): I forgot about the helpful tips I also got from the DRI homepage (http://dri.sourceforge.net/). In the troubleshooting section they talk about Bus Mastering. They indicate that it must be enabled. They even provide a small script that will force it to be enabled. To test to see if it's enabled you run: setpci -s 01:00.0 4.w (assuming your card is at that address). If it returns a '003' then it's disabled (that's my situation). Then if you run this script as root: #!/bin/bash dev=01:00.0 # change as appropriate echo Enabling bus mastering on device $dev setpci -s $dev 4.w=$(printf %x $((0x$(setpci -s $dev 4.w)|4))) dev=00:00.0 echo Enabling bus mastering on host bridge $dev setpci -s $dev 4.w=$(printf %x $((0x$(setpci -s $dev 4.w)|4))) exit 0 it's supposed to enable Bus Mastering. Well, it doesn't. When I run: setpci -s 01:00.0 4.w again, it's still set to '003'. So, if you can't set these bits by force as root, I suspect the Xserver can't do it either. Please check this out as a possiblity. thx... -- jcw Check your CMOS settings and make sure anything related to PCI busmastering looks right. The vt switch problem is fixed in my latest test RPM: ftp://people.redhat.com/mharris/testing I noticed this some time back. If I switch from the graphical login (run-level 5) to text-mode console login (run-level-3) then this extmod disabling is not necessary. In fact, one can then have DGA enabled and there is *no* x-server crash anymore. The notable difference between run-levels 3 and 5 is that in level-3 kdm (of kdebase) doesnot run. So I guess this is a problem of kdm. Hope this info helps. Also, regarding bus-mastering, the script doesnot work at all. But the good news is that bus-mastering is probably not even required as my status is 0002 and /var/log/XFree86.0.log indicates "direct rendering enabled". thanks - Nil (ndeb.edu) |