Bug 78474 - chromium and tuxracer die with illegal exception error on T30
chromium and tuxracer die with illegal exception error on T30
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
Blocks: 82776
  Show dependency treegraph
Reported: 2002-11-23 21:11 EST by Chris Runge
Modified: 2007-04-18 12:48 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-26 04:13:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Tuxracer strace (83.89 KB, text/plain)
2002-11-23 21:14 EST, Chris Runge
no flags Details
Chromium strace (12.84 KB, text/plain)
2002-11-23 21:18 EST, Chris Runge
no flags Details
XFree86 configuration file (3.81 KB, text/plain)
2002-11-23 21:20 EST, Chris Runge
no flags Details
XFree86 log (31.90 KB, text/plain)
2002-11-23 21:21 EST, Chris Runge
no flags Details

  None (edit)
Description Chris Runge 2002-11-23 21:11:51 EST
Description of Problem:

chromium dies with an illegal exception error on an IBM ThinkPad T30. This is
with DRI enabled under either 16-bit or 24-bit color. The program itself will
startup, and the music will play for a few seconds, but there are no graphics
displayed in the windows. Shortly thereafter the program will die with an
illegal exception error.

tuxracer dies in a similar fashion. The program will start, and I am able to
select the option to do a practice run. However, after selecting that the
program dies with an illegal exception error as well.

glxgears seems to work fine. I tried some of the GL screensavers; some of those
work and others (Atlantis) don't.

Tuxracer and Chromium both work on my desktop system with a Radeon 7500; my
guess is that the problem is not so much with these programs but with the
XFree86 component, hence the component selection.

Version-Release number of selected component (if applicable):

# rpm -q XFree86 chromium tuxracer

How Reproducible:

Comment 1 Chris Runge 2002-11-23 21:14:32 EST
Created attachment 86204 [details]
Tuxracer strace
Comment 2 Chris Runge 2002-11-23 21:18:58 EST
Created attachment 86205 [details]
Chromium strace
Comment 3 Chris Runge 2002-11-23 21:20:24 EST
Created attachment 86206 [details]
XFree86 configuration file
Comment 4 Chris Runge 2002-11-23 21:21:30 EST
Created attachment 86207 [details]
XFree86 log
Comment 5 Mike A. Harris 2002-11-25 08:53:50 EST
If tuxracer/chromium themselves SEGV or SIGILL, then it is a bug/problem
in each of the individual applications themselves.  An application crashing,
is an application bug, not an XFree86 bug.

Reassigning to chromium
Comment 6 Ngo Than 2002-12-08 13:04:50 EST
It's not correct, because they use the X libraries, which could cause
chromium/tuxrace crashed.

I cannot reproduce it with GForce/Matrox Graphic Cards.

Are you sure that you have installed a correct version of tuxrace/chromium from
8.0 on your machine?

The sound support in chromium/tuxrace was removed in 8.0!

Comment 7 Ngo Than 2002-12-08 13:07:14 EST
It looks like it crashed in loading /usr/X11R6/lib/modules/dri/radeon_dri.so
Comment 8 Mike A. Harris 2002-12-21 09:15:36 EST
Works for me on my Radeon hardware.  But I don't have a T30 nor any
Radeon Mobility hardware either, so that isn't really indicative of much.

Comment 9 Need Real Name 2003-09-10 02:55:41 EDT
A have a similar problem when running some glut programs.

Download the atlantis demo

Running simply returns:
Illegal instruction (core dumped)

Running wiht gdb tracing gives:
Program received signal SIGFPE, Arithmetic exception.
0x4050efbb in gl_test_os_katmai_exception_support ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so

So my guess is there is a bug in radeon_dri.

Here is my radeon PCI id from lspci
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon
Comment 10 Need Real Name 2003-09-10 03:08:22 EDT
Oops I did not finish the GDB tracing. the illegal instruction shows up somewhat

(gdb) r
Starting program: /tmp/atlantis/atlantis
[New Thread 16384 (LWP 22970)]

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 16384 (LWP 22970)]
0x4050efbb in gl_test_os_katmai_exception_support () from
(gdb) c

Program received signal SIGILL, Illegal instruction.
0x40511732 in gl_3dnow_transform_normals_raw () from

So dri_radeon tries to execute a 3DNOW instruction which is obviously not
accepted by the P4 processor.

Here are the CPU flags for my processor (no 3dnow):
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm

So my idea is that the dri_radeon module is compiled to use 3DNOW instructions
even when on a P4. My question now is whether this is bug by redhat or by Xfree.
Comment 11 Need Real Name 2003-09-10 03:33:09 EDT
OK. My guess seems to be correct. Mesa in Xfree incorrectly detects a 3Dnow
instruction set, and kaboom.

As a temporary and fast fix, if you have a Katmai P4, you can use the following
environment variables:


and the bug is gone.

For a clean fix in a redhat environment, I suggest to add the following files in

# /etc/profile/X.sh

export MESA_NO_3DNOW=1
# /etc/profile/X.csh

setenv MESA_NO_3DNOW 1

And you're all set!
Comment 12 Mike A. Harris 2003-09-11 03:02:14 EDT
This is a known bug in the Pentium 4 processor.  Some of Intel's CPUs
claim that they support 3Dnow, but they do not, and so Mesa is doing the
right thing.

I believe there is a workaround for this issue in Mesa CVS that checks to
make sure 3DNow is only enabled on AMD CPUs which have the 3Dnow flag set.

I'll eventually apply the buggy processor kludge fix for this once I have
time to track it down, however if someone else is up to the task of tracking
the particular fix down in Mesa CVS and can attach it here, I can apply
it to a build sooner.

I don't know if the 3Dnow issue reported by Bernhard above is the same as
the issue reported by the original reporter or not though.  I would need
a gdb backtrace to compare the two failures.  I haven't looked at the 2
strace's that are attached yet as they're not web browser clickable, yet
they're marked as text/plain mimetype (ick).
Comment 13 Ziegler Gábor 2004-01-24 04:37:46 EST
I have met with the same bug on Debian unstable, with a Matrox
Millenium G550 DualHead AGP video card:
GL_RENDERER =Mesa DRI G400 20010622 AGP 4x x86/MMX/3DNOw!/SSE
GL_VERSION = 1.2 Mesa 3.4.2
GL_VENDOR = VA Linux Systems Inc.
and XFree86

The same workaround solved my problem, however forcing KATMAI was not
necessary, only disabling 3DNow! was enough.
Comment 14 Ziegler Gábor 2004-01-24 04:39:18 EST
I forgot to state, that it was not an IBM T30, but an Abit IS7E mobo
with P4 Celeron 2.4GHz.
Comment 15 Mike A. Harris 2004-01-26 04:13:44 EST
Red Hat XFree86 4.3.0 packages which are currently available as
updates for Red Hat Linux 9, RHEL 3, and Fedora Core include a patch
that fixes a problem in Mesa which causes a similar problem to occur
under 2.6.x kernels.  I do not recall if the issue reported in this
bug report is related or not, but it's within the same area of Mesa.

We no longer support Red Hat Linux 8.0 or 7.x, so there won't be
further updates of XFree86 for those OS releases, however I believe
this particular problem is no longer present in our current XFree86
4.3.0 packages, so users upgrading to a newer OS release which
is still supported by Red Hat (Red Hat Linux 9, Red Hat Enterprise
Linux 3, Fedora Core 1), should no longer experience this problem.

Closing bug as "CURRENTRELEASE", however, if this problem persists
in Fedora Core 1 or RHEL 3 with all updates applied, feel free to
reopen the report along with updated status info, and I will
reinvestigate it with current XFree86/Mesa sources.

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