Red Hat Bugzilla – Bug 78474
chromium and tuxracer die with illegal exception error on T30
Last modified: 2007-04-18 12:48:40 EDT
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
Created attachment 86204 [details]
Created attachment 86205 [details]
Created attachment 86206 [details]
XFree86 configuration file
Created attachment 86207 [details]
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
It's not correct, because they use the X libraries, which could cause
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!
It looks like it crashed in loading /usr/X11R6/lib/modules/dri/radeon_dri.so
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.
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 ()
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
Oops I did not finish the GDB tracing. the illegal instruction shows up somewhat
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
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.
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
and the bug is gone.
For a clean fix in a redhat environment, I suggest to add the following files in
setenv MESA_NO_3DNOW 1
setenv MESA_FORCE_KATMAI 1
And you're all set!
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
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).
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 220.127.116.11
The same workaround solved my problem, however forcing KATMAI was not
necessary, only disabling 3DNow! was enough.
I forgot to state, that it was not an IBM T30, but an Abit IS7E mobo
with P4 Celeron 2.4GHz.
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.