Bug 78474

Created attachment 86204 [details]
Tuxracer strace

Created attachment 86205 [details]
Chromium strace

Created attachment 86206 [details]
XFree86 configuration file

Created attachment 86207 [details]
XFree86 log

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
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!

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
http://www.opengl.org/developers/code/glut_examples/demos/atlantis.zip

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
7500]

Oops I did not finish the GDB tracing. the illegal instruction shows up somewhat
later.

(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
/usr/X11R6/lib/modules/dri/radeon_dri.so
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x40511732 in gl_3dnow_transform_normals_raw () from
/usr/X11R6/lib/modules/dri/radeon_dri.so
(gdb)

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
environment variables:

MESA_NO_3DNOW=1
MESA_FORCE_KATMAI=1

and the bug is gone.

For a clean fix in a redhat environment, I suggest to add the following files in
/etc/profile.d:

---snip----
# /etc/profile/X.sh

export MESA_NO_3DNOW=1
export MESA_FORCE_KATMAI=1
---snip----
# /etc/profile/X.csh

setenv MESA_NO_3DNOW 1
setenv MESA_FORCE_KATMAI 1
---snip----

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
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).

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 4.2.1.1

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.