On Wed, 7 Nov 2012 13:58:56 -0200 Paulo Alcantara <[email protected]> said:
> On Wed, Nov 7, 2012 at 1:51 PM, Lucas De Marchi > <[email protected]> wrote: > > 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. > > > > > > Lucas De Marchi > > > > ------------------------------------------------------------------------------ > > 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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > I have a few questions: > > 1) Shouldn't we determine whether or not use a specific CPU feature at > initialization time instead of checking it always at runtime ? initialization time is runtime. if you mean ar compile tom - no. abslutely not. never ever ever do this. > 2) Since CPUID instruction was available on older x86 CPUS (like 486 > as demarchi just said), should we still keep NOT using CPUID at all ? because of portability to things that are not x86. and een so a cpuid instr would fail on a 386. current evas will work just fine on a 386 and detect that no extended instructons are there, so the current mechanism is much more portable than cpuid. -- ------------- 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
