Hi everyone,
Thanks a lot for the suggestions and discussion. Below are some more info
as requested. Hopefully they can lead to a definitive diagnosis of the
problem.
It looks like the "CPU=native" parameter above results in some machine
> code generated during compilation which cannot be executed on your
> actual CPU. Can you please show
> (a) one command line how gcc is invoked (i.e. which flags are passed
> for compilation)
> (b) cat /proc/cpuinfo
gcc -Iinclude -Iebtree -Wall -O2 -march=native -g -fno-strict-aliasing
-DCONFIG_HAP_LINUX_SPLICE -DTPROXY -DCONFIG_HAP_LINUX_TPROXY
-DCONFIG_HAP_CRYPT -DENABLE_POLL -DENABLE_EPOLL -DUSE_CPU_AFFINITY
-DASSUME_SPLICE_WORKS -DUSE_ACCEPT4 -DNETFILTER -DUSE_GETSOCKNAME
-DUSE_OPENSSL -DUSE_SYSCALL_FUTEX -DUSE_PCRE -I/usr/include
-DCONFIG_HAPROXY_VERSION=\"1.5.1\" -DCONFIG_HAPROXY_DATE=\"2014/06/24\" \
-DBUILD_TARGET='"linux2628"' \
-DBUILD_ARCH='""' \
-DBUILD_CPU='"native"' \
-DBUILD_CC='"gcc"' \
-DBUILD_CFLAGS='"-O2 -march=native -g -fno-strict-aliasing"' \
-DBUILD_OPTIONS='"USE_OPENSSL=1 USE_STATIC_PCRE=1"' \
-c -o
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Xeon(R) CPU E5-2650L 0 @ 1.80GHz
stepping : 7
microcode : 0x70a
cpu MHz : 1800.077
cache size : 20480 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu de tsc msr pae cx8 apic cmov pat clflush mmx fxsr sse sse2 ss
ht nx constant_tsc nonstop_tsc pni pclmulqdq ssse3 sse4_1 sse4_2 popcnt
tsc_deadline_timer aes hypervisor ida arat epb pln pts dtherm
bogomips : 3601.16
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
There are (virtual) 8 cores, so the rest are pretty much the same.
I've wanted to add my 2¢. Recently, I've compiled some software (not
> HAProxy however), using CPU=native as a make option, in a virtual machine
> on a Citrix XenServer 6.2. Although the software was able to compile
> successfully, it would fail on execution with a SIGILL.
> Recompiling the same piece of software with CPU=core2 (or CPU=generic)
> yielded a fully functional binary, so it could be possible that the CPU
> instruction set is not properly detected by the compiler (especially in
> virtualized environments).
I'm in a similar situation. The server is a Linode VPS, and I compiled and
run the binary on the same server. However, when I used CPU=native for all
the previous 1.5-dev versions on the same server, the resulted binaries
were all fine. The problem only appeared after the upgrade to 1.5.1.
Is there anything changed between dev26 and 1.5.1 that causes this issue in
VMs? Shall we assume that CPU=native is no longer recommended for VMs?
Instead, we should use CPU=generic going forward?
Mmmh, ok. Could you give a last try with:
> make clean && \
> make CFLAGS="-O0 -march=native -g -fno-strict-aliasing" CPU=native \
> TARGET=linux2628 USE_OPENSSL=1 USE_STATIC_PCRE=1
The compiled binary runs fine.
The request that is crashing haproxy, is it HTTPS on the frontend or
> plain and simple HTTP?
HTTPS on the frontend.
Best regards,
Merton
On Thu, Jul 10, 2014 at 2:51 AM, Willy Tarreau <[email protected]> wrote:
> Hi Edwin,
>
> On Wed, Jul 09, 2014 at 02:42:43PM -0400, Edwin wrote:
> > I've wanted to add my 2ข. Recently, I've compiled some software (not
> > HAProxy however), using CPU=native as a make option, in a virtual
> > machine on a Citrix XenServer 6.2. Although the software was able to
> > compile successfully, it would fail on execution with a SIGILL.
> > Recompiling the same piece of software with CPU=core2 (or CPU=generic)
> > yielded a fully functional binary, so it could be possible that the CPU
> > instruction set is not properly detected by the compiler (especially in
> > virtualized environments).
>
> That's very interesting indeed. I remember reading a bug report somewhere
> about some CPU capabilities flags not always being correctly reported in
> certain VMs. If SSE falls in that category and is not present nor emulated,
> that could cause exactly such things.
>
> I suspect we'll have to remove CPU=native from the README in order to save
> people from using it in such bogus environments if it causes issues.
>
> Thanks,
> Willy
>
>
