Jonathan McPhersonOh, forgot to mention: this is 4.4.3 on Linux.
Aug 3, '21permalink
"Invalid opcode" crash in libTurboActivate.soAnswered
We have a customer who has reported a crash that appears to be originating from libTurboActivate (happens when they attempt to do anything licensing related). Here's the crash as reported by the kernel:
Aug 02 16:10:10 kernel: traps: license-manager[38646] trap invalid opcode ip:7fd3d6c41b48 sp:7ffe9e0bf638 error:0 in libTurboActivate.so[7fd3d6c2b000+fc000]Suspecting that this was related to the CPU, I asked them to run lscpu. Here's the output:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 36 bits physical, 48 bits virtual
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 2
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 15
Model name: Intel(R) Xeon(R) CPU E5345 @ 2.33GHz
Stepping: 7
CPU MHz: 2028.691
BogoMIPS: 4655.11
L1d cache: 256 KiB
L1i cache: 256 KiB
L2 cache: 16 MiB
NUMA node0 CPU(s): 0-7
Vulnerability Itlb multihit: KVM: Mitigation: VMX unsupported
Vulnerability L1tf: Vulnerable
Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Full generic retpoline, STIBP disabled, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_goo
d nopl cpuid aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm pti dthermDo you have any theories about why this library would crash with an invalid opcode? Does the CPU info above help explain it, or are we barking up the wrong tree?
Aug 3, '21permalink
Answer
Wyatt O'DayYeah, that’s a very old processor. Almost 15 years old. We don’t support it on Linux.
There are a series of limitations to compiling for old processors on Linux (compiler limitations, linker limitations, kernel limitations, etc.)
They can run Windows in that and the Windows version of TurboActivate will work fine on that ancient processor. Or they can upgrade their CPU (And reap the speed and power consumption benefits).
Aug 4, '21, edited Aug 4, '21permalink
Bummer that I'll have to tell our customer they can't use our software since this is the only limitation, but understand the rationale. Thanks for the quick response.
Aug 4, '21permalink
Oh, and for our documentation purposes, we will need a way for customers to know whether or not they have a supported processor. Is this anywhere in the LimeLM docs, or is there a way to infer it from the lscpu output?
Aug 4, '21permalink
Answer
For Windows, if it's a supported version of Windows (supported by Microsoft – still receiving security updates) then our products will work on it. Regardless of processor.
For macOS, if it's a supported version of macOS (supported by Apple – still receiving security updates) then our products will work on it. Regardless of processor.
For Linux / BSD, we support processors anywhere from 8 to 10 years old. If it works on older processors it's a happy accident.
In this modern everything-is-connected-always world, using old hardware is a security risk. Running a 15 year old processor on a 15 year old motherboard with 15 year old firmware is a *HUGE* security risk. It's just a fact of capitalism and our wildly unregulated tech markets that old hardware just doesn't receive necessary firmware / microcode updates.
Aug 4, '21, edited Aug 4, '21permalink