On 11/06/2012 08:09 AM, Cedric BAIL wrote: > On Tue, Nov 6, 2012 at 10:07 AM, Jim Kukunas > <james.t.kuku...@linux.intel.com> wrote: >> On Tue, Nov 06, 2012 at 01:41:01AM +0100, Vincent Torri wrote: >>> On Tue, Nov 6, 2012 at 1:32 AM, Paulo Alcantara <pca...@profusion.mobi> >>> wrote: >>>> On Mon, Nov 5, 2012 at 7:12 PM, Sebastian Dransfeld <s...@tango.flipp.net> >>>> wrote: >>>>> Program received signal SIGILL, Illegal instruction. >>>>> 0x00491f8b in _mm_lddqu_si128 (__P=0xbfffb5b0) at >>>>> /usr/lib/gcc/i686-linux-gnu/4.6/include/pmmintrin.h:111 >>>>> 111 return (__m128i) __builtin_ia32_lddqu ((char const *)__P); >>>>> (gdb) bt >>>>> #0 0x00491f8b in _mm_lddqu_si128 (__P=0xbfffb5b0) at >>>>> /usr/lib/gcc/i686-linux-gnu/4.6/include/pmmintrin.h:111 >>>>> #1 _op_blend_pas_dp_sse3 (s=0xbfffb5b0, m=0x0, c=0, d=0xbfffb6b0, l=64) >>>>> at lib/evas/common/evas_op_blend/op_blend_pixel_sse3.c:59 >>>>> #2 0x004b0d34 in evas_common_op_sse3_test () at >>>>> lib/evas/common/evas_op_blend/op_blend_master_sse3.c:73 >>>>> #3 0x00465867 in evas_common_cpu_sse3_test () at >>>>> lib/evas/common/evas_cpu.c:72 >>>>> #4 0x00465983 in evas_common_cpu_feature_test (feature=0x465850 >>>>> <evas_common_cpu_sse3_test>) >>>>> at lib/evas/common/evas_cpu.c:138 >>>>> #5 0x00465ad3 in evas_common_cpu_init () at >>>>> lib/evas/common/evas_cpu.c:183 >>>>> >>>>> pentium-m >>>>> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca >>>>> cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts est tm2 >>>>> >>>> >>>> Weird. Looks like SSE3 support isn't being checked properly through CPUID. >>> >>> the check in configure is not sufficient : host detection + detection >>> of a file, which exists on this pentium M. So something more should be >>> done, I guess, don't know what, though >> >> The host detection + header check is _NOT_ a check as to whether the >> processor supports SSE3, but rather whether the build environment can >> compile code with SSE3 intrinsics. >> >> The real check occurs at runtime in evas_common_cpu_feature_test(), where >> we attempt to run a function consisting of the feature in question while >> trapping for SIGILL and SIGSEGV. If we catch either signal, we disable >> support >> for the associated feature. >> >> In this case, the SIGILL is expected, however it seems the signal >> handlers were not properly setup. > > Actually I have an explanation of the problem for E17. Tom started to > notice a problem on his laptop, where he got a WBOD without any useful > backtrace in E. In fact, E backtrace pointed to a always correct code > (aka select syscall). Here is my possible explanation of the issue, if > the problem you are reporting is related to E17. The new WBOD does > catch all signal in the parent process of E17, it doesn't know if the > SIGILL is properly catched or not, resulting in the WSOD being > displayed, when actually everything is fine. > > We need to fix that bug in E17 properly. In the mean time, I recommend > package manager to disable SSE3 for non source distribution.
My problem is that if I don't disable sse3 on my pentium-m, evas based programs (like terminology) will crash. So the trapping in evas when it tests cpu features is broken in this case. S. ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
