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