Bug 37079 - XFree86 and AGP Voodoo3 on Athlon system crashes running 3D accel apps, switching to console from X causes video death
Summary: XFree86 and AGP Voodoo3 on Athlon system crashes running 3D accel apps, switc...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-04-22 17:49 UTC by Scott Dowdle
Modified: 2007-04-18 16:32 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-05-03 23:48:42 UTC
Embargoed:


Attachments (Terms of Use)
Full /var/log/XFree86.x.log (22.27 KB, text/plain)
2001-04-22 17:50 UTC, Scott Dowdle
no flags Details
Here's an strace attached to XFree86 just before the crash (33.59 KB, text/plain)
2001-05-03 23:25 UTC, J.C. Webber III
no flags Details
And here's an ltrace, also attached to the process just before initiating the crash (28.04 KB, text/plain)
2001-05-03 23:26 UTC, J.C. Webber III
no flags Details

Description Scott Dowdle 2001-04-22 17:49:34 UTC
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.

Comment 1 Scott Dowdle 2001-04-22 17:50:25 UTC
Created attachment 16026 [details]
Full /var/log/XFree86.x.log

Comment 2 NILMONI DEB 2001-04-30 00:23:22 UTC
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)


Comment 3 Scott Dowdle 2001-04-30 01:02:23 UTC
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.



Comment 4 J.C. Webber III 2001-05-03 22:27:49 UTC
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

Comment 5 J.C. Webber III 2001-05-03 23:23:25 UTC
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

Comment 6 J.C. Webber III 2001-05-03 23:25:15 UTC
Created attachment 17266 [details]
Here's an strace attached to XFree86 just before the crash

Comment 7 J.C. Webber III 2001-05-03 23:26:31 UTC
Created attachment 17267 [details]
And here's an ltrace, also attached to the process just before initiating the crash

Comment 8 J.C. Webber III 2001-05-03 23:48:37 UTC
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


Comment 9 Mike A. Harris 2001-05-11 03:36:16 UTC
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

Comment 10 NILMONI DEB 2001-05-12 15:14:17 UTC
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)


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