<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hello!<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Found an interesting problem with Asterisk 13 on a cloud <br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">box running CentOS 6.6. It compiled, but would die with <br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">an illegal instruction on loading. Looking at the result, <br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I saw that it was dying on the assembler instruction:<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">vcvtsi2sdq -0x98.....<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Apparently, this cloud box is AMD opteron 64-bit, but does<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">not have that particular opcode supported. I see that every<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">file compiles with -march=native, and that this can be turned<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">on/off via the 'BUILD_NATIVE' compiler option in menuselect.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I looked this up in the gcc man page, and for the i386/AMD 64-bit options, I see (under -mtune):<br><br>           native<br>               This selects the CPU to tune for at compilation time by determining the <br>               processor type of the compiling machine.  Using -mtune=native will<br>               produce code optimized for the local machine under the constraints of the <br>               selected instruction set.  Using -march=native will enable all<br>               instruction subsets supported by the local machine (hence the result <br>               might not run on different machines).<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">And, in this case, the code generated didn't even run on my own machine.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Now, I know that one simple solution to this problem is to turn off the native<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">compile option in menuselect. (I tried it, and it works).  I tried again, and  turned it<br>on,but changed the makefile rules file to use -mtune=native instead, and this also <br>worked to solve this crash.<br><br>Output of "cat /proc/cpuinfo"<br><br>vendor_id    : AuthenticAMD<br>cpu family    : 21<br>model        : 1<br>model name    : AMD Opteron(TM) Processor 6272                 <br>stepping    : 2<br>cpu MHz        : 2100.096<br>cache size    : 2048 KB<br>physical id    : 0<br>siblings    : 1<br>core id        : 4<br>cpu cores    : 1<br>apicid        : 0<br>initial apicid    : 4<br>fpu        : yes<br>fpu_exception    : yes<br>cpuid level    : 13<br>wp        : yes<br>flags        : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm up rep_good unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch xop fma4 perfctr_core perfctr_nb<br>bogomips    : 4200.19<br>TLB size    : 1536 4K pages<br>clflush size    : 64<br>cache_alignment    : 64<br>address sizes    : 48 bits physical, 48 bits virtual<br>power management:<br><br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">On my own AMD powered workstation, I see, in one of my centos 6.6 vm's:<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>vendor_id    : AuthenticAMD<br>cpu family    : 6<br>model        : 6<br>model name    : QEMU Virtual CPU version 2.0.0<br>stepping    : 3<br>...<br>flags        : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm up unfair_spinlock pni cx16 x2apic popcnt hypervisor lahf_lm svm abm sse4a<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Now, I guess I'm suggesting that -mtune=native be used instead of -march=native, as<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">it will, by default, yield a working set of code on the current machine, no matter what<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">the possible options are, as the BUILD_NATIVE option is turned on by default (at least<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">in my environment), and it's not easily recognized when BUILD_NATIVE is appropriate <br>and when it is not.  Running on VM's appear to give stripped-down CPU's; and such<br>appears to a fad that will not go away soon... But, I'm no expert. Am I being silly?<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">murf<br><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><br>Steve Murphy<br>ParseTree Corporation<br><br><br><br></div></div>
</div>