On Wed, 7 Nov 2012 13:51:04 -0200 Lucas De Marchi <[email protected]> said:
> On Wed, Nov 7, 2012 at 1:23 PM, Carsten Haitzler <[email protected]> wrote: > > On Wed, 7 Nov 2012 11:07:31 -0200 Lucas De Marchi > > <[email protected]> said: > > > >> On Wed, Nov 7, 2012 at 8:21 AM, Sebastian Dransfeld <[email protected]> > >> wrote: > >> > On 11/07/2012 09:59 AM, Carsten Haitzler (The Rasterman) wrote: > >> >> On Tue, 6 Nov 2012 15:52:02 +0100 Sebastian Dransfeld > >> >> <[email protected]> said: > >> >> > >> >>> On 11/06/2012 08:09 AM, Cedric BAIL wrote: > >> >>>> On Tue, Nov 6, 2012 at 10:07 AM, Jim Kukunas > >> >>>> <[email protected]> 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 > >> >>>>>> <[email protected]> wrote: > >> >>>>>>> On Mon, Nov 5, 2012 at 7:12 PM, Sebastian Dransfeld > >> >>>>>>> <[email protected]> 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. > > Not sure you werre responding to me, but... the question I raised is: > is there any value in the first approach instead of being simpler with > cpuid? wikipedia says it's available since 486 days, but maybe there > are other reasons. that was already covered - it's the only portable way to do it. ie on other architectues too. the same mechanism does altivec and neon too. it's a prefectly fine way of doing it - it just means if u gdb something uing evas on a system that fails these checks, you'll get sigill's u have to just continue from at startup. it's perfectly fine to continue from them given the code. as i said - the problem is not the tests. it's the build tree setup having changed from the old evas tree where this was nver a problem. the code didnt change - the build flags etc. did. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
