On 11/07/2012 06:41 PM, Lucas De Marchi wrote: > On Wed, Nov 7, 2012 at 1:23 PM, Carsten Haitzler <ras...@rasterman.com> wrote: >> On Wed, 7 Nov 2012 11:07:31 -0200 Lucas De Marchi >> <lucas.demar...@profusion.mobi> said: >> >>> On Wed, Nov 7, 2012 at 8:21 AM, Sebastian Dransfeld <s...@tango.flipp.net> >>> wrote: >>>> On 11/07/2012 09:59 AM, Carsten Haitzler (The Rasterman) wrote: >>>>> On Tue, 6 Nov 2012 15:52:02 +0100 Sebastian Dransfeld >>>>> <s...@tango.flipp.net> >>>>> said: >>>>> >>>>>> 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. >>>>> >>>>> no - this sint the sse3 test broken at all. it's the port of evas to the >>>>> efl tree - the build is broken. basically it forces all of evas to compile >>>>> ith sse3 optimizations (the c code producing sse3 intrusctions) *I*F >>>>> compiler supports it. ONLY the sse3 optimized rendering code files should >>>>> compile with this flag >>>>> - ONLY those, and nothing else. same with the altivec asm files etc. they >>>>> should be compiled into separate .so/.a's and then linked into the evas >>>>> lib >>>>> after where not only the optimized routines compile with sse3 opts. >>> >>> it seems like a separate issue to fix (that has always been there). >>> Vincent, do you want to fix it? otherwise I can take a look. >> >> no - it hasnt alwasy been there. definitely not. see my eply to seb. :) check >> the evas tree src and Makefile.am's if u want. in the evas tree only the >> sse3 >> asm file is built with -msse3, nothing else. this issue is new i the efl >> tree. >> >>> >>>>> >>>>> >>>> >>>> Rubbish. This has always been like this, and it fails in the cpu test, >>>> not the main code. >>> >>> yeah... from the backtrace this is pretty clear. >>> >>> Did you try removing the #ifdef condition and running with the #else >>> code? They should be equivalent but with different methods. While the >>> first one uses a try/catch approach the second queries the CPU through >>> cpuid instruction. >> >> IF u run it under gdb you WILL get a trapped sigill in gdb. thats NORMAL if >> its >> the test code. just continue from that and keep running... the REAL problem >> will pop up later. and the problem is what i described. > > true... Anyway, the cpp_flags to evas are (possibly) fixed in r78973. > > Stephan, could you please test it, remembering to continue if running > inside gdb and a SIGILL arrives for code inside the test code.
Works. S. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
