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 () 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: Always 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.
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 () 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
$ 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
hmm. weird.
this thread on the xpert mailing list discusses this issue: http://www.spinics.net/lists/xf-xpert/msg05977.html 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 correctly.
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 (tm). 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 what.
Ok - get a load of this: http://www.geocrawler.com/lists/3/SourceForge/1290/0/10115708/ 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 works.
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 code. Closing as fixed in RAWHIDE