Bug 79167 - SIGFPE in /usr/X11R6/lib/modules/dri/radeon_dri.so
Summary: SIGFPE in /usr/X11R6/lib/modules/dri/radeon_dri.so
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
Blocks: 82776
TreeView+ depends on / blocked
Reported: 2002-12-06 18:04 UTC by Dan Berger
Modified: 2007-04-18 16:48 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-02-03 15:58:44 UTC

Attachments (Terms of Use)
my current XF86Config (for reference) (4.29 KB, text/plain)
2002-12-06 18:04 UTC, Dan Berger
no flags Details
x server startup log (26.88 KB, text/plain)
2002-12-06 18:05 UTC, Dan Berger
no flags Details

Description Dan Berger 2002-12-06 18:04:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830

Description of problem:
There's a bug in the radeon XFree driver that causes crashes in many (but not
all) OpenGL apps.

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 8192 (LWP 1048)]
0x404a9fbb in gl_test_os_katmai_exception_support ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
(gdb) l
1       <unknown>: No such file or directory.
        in <unknown>

glxgears, for example, works - but none of the GL hacks included in the
xscreensaver package seem to.

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

How reproducible:

Steps to Reproduce:
1.run /usr/X11R6/lib/xscreensaver/molecule

Actual Results:  program terminates with message "Illegal Instruction"

Expected Results:  pretty pictures ;)

Additional info:

I tried updating to the bleeding edge DRI modules from dri.sourceforge.net - but
they've been compiled against a newer X server release - so the ABI version
numbers don't match and the X server won't start.

Comment 1 Dan Berger 2002-12-06 18:04:51 UTC
Created attachment 87705 [details]
my current XF86Config (for reference)

Comment 2 Dan Berger 2002-12-06 18:05:39 UTC
Created attachment 87706 [details]
x server startup log

Comment 3 Mike A. Harris 2002-12-08 13:32:59 UTC
The Katmai exception is expected if your processor doesn't support
Intel SSE.  Please attach a complete backtrace.

Comment 4 Dan Berger 2002-12-08 16:10:01 UTC
#0  0x404a9fbb in gl_test_os_katmai_exception_support ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
#1  0x404a9cf1 in check_os_katmai_support ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
#2  0x404a9e01 in gl_init_all_x86_transform_asm ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
#3  0x403da103 in one_time_init ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
#4  0x403dc327 in _mesa_initialize_context ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
#5  0x403dc661 in gl_create_context ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
#6  0x403b0a2b in driMesaCreateContext ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
#7  0x4007a987 in _glthread_SetTSD () from /usr/lib/libGL.so.1
#8  0x4007aaae in glXCreateContext () from /usr/lib/libGL.so.1
#9  0x0805043e in init_GL ()
#10 0x0804cdb2 in init_molecule ()
#11 0x0805184e in xlockmore_screenhack ()
#12 0x0804a358 in screenhack ()
#13 0x0804fc1c in main ()
#14 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

Comment 5 Dan Berger 2002-12-08 16:12:14 UTC
$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz
stepping        : 7
cpu MHz         : 1197.226
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips        : 2375.92

Comment 6 Mike A. Harris 2002-12-11 18:12:14 UTC
hmm.  weird.

Comment 7 Dan Berger 2002-12-14 01:13:45 UTC
this thread on the xpert mailing list discusses this issue:

but no solution is offered, other than "this is an expected result of the
function" - which suggests that a whole bunch of opengl apps are broken - or
(more likely) that the trouble is in Mesa for not catching and dealing with this

Comment 8 Dan Berger 2002-12-14 01:22:08 UTC
Actually - on re-reading, I have to retract my previous statement.  A few
responders cryptically suggested "just "c" to continue" - which I (finally)
realized means that the Mesa code probably catches this and does the Right Thing

So I pulled molecule into gdb, ran it, saw the SIGFPE, and (c)ontinued.

The next problem is at:

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

But something's going really wrong - the stack is pretty smashed.

(gdb) where
#0  0x404ac2ce in gl_3dnow_transform_normalize_normals_raw ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
#1  0xbfffedb8 in ?? ()
Cannot access memory at address 0xbf

So I tried a different app - chromium - which uses SDL:  then I get a more
complete backtrace:

(gdb) where
#0  0x404ab732 in gl_3dnow_transform_normals_raw ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
#1  0x08121280 in ?? ()
#2  0x404304a9 in gl_run_pipeline ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
#3  0x404a0ff2 in gl_execute_cassette ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
#4  0x403ebb6e in execute_list () from /usr/X11R6/lib/modules/dri/radeon_dri.so
#5  0x403ec07a in _mesa_CallList ()
   from /usr/X11R6/lib/modules/dri/radeon_dri.so
#6  0x08062c52 in MenuGL::drawTitle() ()
#7  0x0806190f in MenuGL::drawGL() ()
#8  0x0805f01c in MainSDL::run() ()
#9  0x0806abbf in main ()
#10 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

The bug title should probably be changed in light of this - but I'm not sure to

Comment 9 Dan Berger 2002-12-14 01:26:05 UTC
Ok - get a load of this:


CPU: Before vendor init, caps: bfebf9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 0K, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After vendor init, caps: bfebf9ff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: bfebf9ff 00000000 00000000 00000000
CPU:             Common caps: bfebf9ff 00000000 00000000 00000000
CPU: Intel Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz stepping 07

Seems it's a Mesa problem with a specific CPU stepping.

doing this:

$ MESA_NO_3DNOW=1 /usr/X11R6/lib/xscreensaver/molecule


Comment 10 Dan Berger 2002-12-14 01:28:05 UTC
Last comment (I promise).  Following that last URL - this has been fixed in Mesa
- the fix has been committed to the DRI trunk.

Comment 11 Mike A. Harris 2002-12-27 05:55:45 UTC
Thanks for the info Dan, I'll investigate backporting it.

Comment 12 Mike A. Harris 2003-02-03 15:58:44 UTC
This fix is also in XFree86 CVS now.  I've just confirmed it in the source

Closing as fixed in RAWHIDE

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