Red Hat Bugzilla – Bug 79167
SIGFPE in /usr/X11R6/lib/modules/dri/radeon_dri.so
Last modified: 2007-04-18 12:48:54 EDT
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 ()
1 <unknown>: No such file or directory.
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):
Steps to Reproduce:
Actual Results: program terminates with message "Illegal Instruction"
Expected Results: pretty pictures ;)
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.
Created attachment 87705 [details]
my current XF86Config (for reference)
Created attachment 87706 [details]
x server startup log
The Katmai exception is expected if your processor doesn't support
Intel SSE. Please attach a complete backtrace.
#0 0x404a9fbb in gl_test_os_katmai_exception_support ()
#1 0x404a9cf1 in check_os_katmai_support ()
#2 0x404a9e01 in gl_init_all_x86_transform_asm ()
#3 0x403da103 in one_time_init ()
#4 0x403dc327 in _mesa_initialize_context ()
#5 0x403dc661 in gl_create_context ()
#6 0x403b0a2b in driMesaCreateContext ()
#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
$ 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
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
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 ()
But something's going really wrong - the stack is pretty smashed.
#0 0x404ac2ce in gl_3dnow_transform_normalize_normals_raw ()
#1 0xbfffedb8 in ?? ()
Cannot access memory at address 0xbf
So I tried a different app - chromium - which uses SDL: then I get a more
#0 0x404ab732 in gl_3dnow_transform_normals_raw ()
#1 0x08121280 in ?? ()
#2 0x404304a9 in gl_run_pipeline ()
#3 0x404a0ff2 in gl_execute_cassette ()
#4 0x403ebb6e in execute_list () from /usr/X11R6/lib/modules/dri/radeon_dri.so
#5 0x403ec07a in _mesa_CallList ()
#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
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.
$ MESA_NO_3DNOW=1 /usr/X11R6/lib/xscreensaver/molecule
Last comment (I promise). Following that last URL - this has been fixed in Mesa
- the fix has been committed to the DRI trunk.
Thanks for the info Dan, I'll investigate backporting it.
This fix is also in XFree86 CVS now. I've just confirmed it in the source
Closing as fixed in RAWHIDE