stock 1.8.19 (which runs fine) doesn't also use cmpxchg16b ?
https://en.wikipedia.org/wiki/X86-64#Older_implementations
May be time for a new motherboard (or a Pi4?) ...

Dump of assembler code for function ha_random64:
   0x000055555566bac0 <+0>: push   %rbx
   0x000055555566bac1 <+1>: sub    $0x10,%rsp
   0x000055555566bac5 <+5>: mov    0x17d494(%rip),%rsi        # 0x5555557e8f60
   0x000055555566bacc <+12>: mov    0x17d495(%rip),%rdx        # 0x5555557e8f68
   0x000055555566bad3 <+19>: mov    %fs:0x28,%rax
   0x000055555566badc <+28>: mov    %rax,0x8(%rsp)
   0x000055555566bae1 <+33>: xor    %eax,%eax
   0x000055555566bae3 <+35>: mov    %rsi,%rcx
   0x000055555566bae6 <+38>: mov    %rsi,%rbx
   0x000055555566bae9 <+41>: xor    %rdx,%rcx
   0x000055555566baec <+44>: rol    $0x18,%rbx
   0x000055555566baf0 <+48>: mov    %rcx,%rax
   0x000055555566baf3 <+51>: xor    %rcx,%rbx
   0x000055555566baf6 <+54>: ror    $0x1b,%rcx
   0x000055555566bafa <+58>: shl    $0x10,%rax
   0x000055555566bafe <+62>: xor    %rax,%rbx
   0x000055555566bb01 <+65>: mov    %rsi,%rax
=> 0x000055555566bb04 <+68>: lock cmpxchg16b 0x17d453(%rip)        #
0x5555557e8f60
   0x000055555566bb0d <+77>: sete   %cl
   0x000055555566bb10 <+80>: test   %cl,%cl
   0x000055555566bb12 <+82>: je     0x55555566bb40 <ha_random64+128>
   0x000055555566bb14 <+84>: lea    (%rsi,%rsi,4),%rax
   0x000055555566bb18 <+88>: rol    $0x7,%rax
   0x000055555566bb1c <+92>: mov    0x8(%rsp),%rdi
   0x000055555566bb21 <+97>: xor    %fs:0x28,%rdi
   0x000055555566bb2a <+106>: lea    (%rax,%rax,8),%rax
   0x000055555566bb2e <+110>: jne    0x55555566bb45 <ha_random64+133>
   0x000055555566bb30 <+112>: add    $0x10,%rsp

On Thu, Apr 22, 2021 at 8:31 AM Willy Tarreau <w...@1wt.eu> wrote:
>
> Hi Jim,
>
> On Wed, Apr 21, 2021 at 04:46:17AM -0600, Jim Freeman wrote:
> > Stock 1.8.19-1+deb10u3 on Debian10 runs fine, but when I install
> > 2.2.8-1~bpo10+1 from buster-backports, I get "Illegal instruction" ?
> > Is my CPU just too historic ?
>
> Possible but it makes me think that it could also be a matter of lib
> or toolchain that was built for a slightly different arch with certain
> extensions (e.g. sse etc).
>
> Since it seems to happen easily, you should try it again under gdb,
> then disassemble the code around the location:
>
>  # gdb --args ./haproxy -f ~/haproxy.cfg
>  > run
>
> Once it crashes, issue:
>
>  > bt
>
> it will report the backtrace and current function where it died,
> then:
>
>  > disassemble $rip
>
> and press Enter until you see a line with "=>" indicating the current
> location. Please post a copy of the surrounding lines here, we may
> possibly figure that we're using an instruction we ought not to use.
>
> > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> > pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm
> > 3dnowext 3dnow rep_good nopl cpuid pni lahf_lm 3dnowprefetch vmmcall
> > bugs : fxsave_leak sysret_ss_attrs null_seg swapgs_fence spectre_v1 
> > spectre_v2
>
> I'm not seeing cmpxchg16b here ("cx16"), which could be a serious
> concern, as we've never been aware of any x86_64 CPU without it and
> have been enabling it by default on x86_64 (and it cannot be enabled
> nor disabled at run time as it allows to replace certain structures
> with other ones).
>
> Willy

Reply via email to