Hide Forgot
Whenever I run a program that uses hardware video accel (or whatever you want to call it, ie Quake 3 Demo, tuxracer, etc), the program attempts to load but then X dies, and the kdm screen shows up again. Also, attempts to ALT-CNTRL-Fx to a text console result in the video switching to 640x480 X display and no more video. Luckily the system doesn't lock up so I can ALT-CNTRL-DEL to shutdown and reboot. ==== Hardware in use (as reported in /proc/pci): ==== $ cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 3). Master Capable. Latency=8. Prefetchable 32 bit memory at 0xd0000000 [0xd3ffffff]. Bus 0, device 1, function 0: PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (rev 0). Master Capable. No bursts. Min Gnt=12. Bus 0, device 7, function 0: ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 64). Bus 0, device 7, function 1: IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 6). Master Capable. Latency=32. I/O at 0xd000 [0xd00f]. Bus 0, device 7, function 4: Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 64). Bus 0, device 7, function 5: Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 80). IRQ 11. I/O at 0xdc00 [0xdcff]. I/O at 0xe000 [0xe003]. I/O at 0xe400 [0xe403]. Bus 0, device 10, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 16). IRQ 11. Master Capable. Latency=32. Min Gnt=32.Max Lat=64. I/O at 0xe800 [0xe8ff]. Non-prefetchable 32 bit memory at 0xda000000 [0xda0000ff]. Bus 1, device 0, function 0: VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 1). IRQ 10. Non-prefetchable 32 bit memory at 0xd4000000 [0xd5ffffff]. Prefetchable 32 bit memory at 0xd8000000 [0xd9ffffff]. I/O at 0xc000 [0xc0ff]. ==== Brief info from /var/log/XFree86.x.log: ==== (0): [drm] loaded kernel module "tdfx" (0): [drm] created "tdfx" driver at busid "PCI:1:0:0" (II) TDFX(0): [drm] Registers = 0xd4000000 (II) TDFX(0): visual configs initialized (II) TDFX(0): Using XFree86 Acceleration Architecture (XAA) (==) TDFX(0): Backing store disabled (==) TDFX(0): Silken mouse enabled (**) TDFX(0): DPMS enabled (II) TDFX(0): direct rendering enabled (WW) TDFX(0): Failed to set up write-combining range (0xd8000000,0x2000000) (II) TDFX(0): Textures Memory 10.99 MB I can't seem to find any crash info in any of the logs. ==== I had it working on RHL 7.0 with the PREVIEW GLIDE packages. On this Athelon system with the VIA chipset I had to add the following to /etc/modules.conf in order to get it working on RHL 7.0. I tried this same fix on 7.1 but it didn't work: ==== alias char-major-10-175 agpgart Here is what my /etc/modules.conf looks like on the 7.1 system: $ cat /etc/modules.conf alias eth0 8139too alias parport_lowlevel parport_pc alias sound-slot-0 via82cxxx_audio post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1 || : pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S >/dev/null 2>&1 || : $ If more information is needed, let me know and I'll be happy to provide.
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@ece.cmu.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@kingoblio.com 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@ece.cmu.edu)