On Tue, Sep 6, 2022 at 11:02 AM Lubos Kocman <lubos.kocman@suse.com> wrote:
Hello openSUSE!
I found this help super helpful.
On TW / MicroOS machine you can simply use (mentioned above)
/lib64/ld-linux-x86-64.so.2 --help
on Leap/SLES you'll can it from /proc/cpuinfo manually, this little wrapper from stackowerflow helps with that.
#!/bin/sh -eu
flags=$(cat /proc/cpuinfo | grep flags | head -n 1 | cut -d: -f2)
supports_v2='awk "/cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/ {found=1} END {exit !found}"' supports_v3='awk "/avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/
"xsave" is wrong here
{found=1} END {exit !found}"' supports_v4='awk "/avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/ {found=1} END {exit !found}"'
echo "$flags" | eval $supports_v2 || exit 2 && echo "CPU supports x86- 64-v2" echo "$flags" | eval $supports_v3 || exit 3 && echo "CPU supports x86- 64-v3" echo "$flags" | eval $supports_v4 || exit 4 && echo "CPU supports x86- 64-v4"
As I already explained in this thread on the user list, you cannot reliably detect v3 and above based on information in /proc/cpuinfo. Neither the OSXSAVE flag nor supported XSAVE bits are exposed. Testing for XSAVE is an optimistic approximation where you hope that if XSAVE is supported then everything else will be correctly set up. libc actually queries processor for current OSXSAVE and supported XSAVE bits. Maybe it is possible to provide standalone binary replicating these tests.
My "old tuxedo" with dead battery for years is v3 as well. I think people should really check their HW before pushing back.
In many cases you might be surprised just like I was. We've had similar pushback on armv7, several people insisted on support, promised help and now it's pretty much just Dirk and Guillaume's best effort.That's the reality.
We're just trying to have conversation. Either way the plan is to provide either v1 or v2 Community/Enterprise solution (depends on Factory) after 15.5. We're just waiting to see some actual data (performance benchmark).
Lubos
On Sat, 2022-09-03 at 13:02 -0400, Felix Miata wrote:
cagsm composed on 2022-09-03 17:36 (UTC+0200):
Axel Braun wrote:
schrieb Felix Miata:
Run inxi -Cxx to see what you have for "level:".
I fail to find 'level' in my output: docb@X1E:~> inxi -Cxx
dont see any level stuff here either on plain 15.4. anyone? :(
Releases of inxi are frequent, so Leap's inxi rarely is anywhere near current:
inxi version: 3.3.21, Date: 2022-08-22 inxi version: 3.3.20, Date: 2022-07-27 inxi version: 3.3.19, Date: 2022-06-16 inxi version: 3.3.18, Date: 2022-06-13 inxi version: 3.3.17, Date: 2022-06-10 inxi version: 3.3.16, Date: 2022-05-19 inxi version: 3.3.15, Date: 2022-04-08 inxi version: 3.3.14, Date: 2022-03-24 inxi version: 3.3.13, Date: 2022-02-22 inxi version: 3.3.12, Date: 2022-01-18 inxi version: 3.3.11, Date: 2021-12-16 inxi version: 3.3.10, Date: 2021-12-13 inxi version: 3.3.09, Date: 2021-11-22 inxi version: 3.3.08, Date: 2021-10-21 inxi version: 3.3.07, Date: 2021-10-11
15 releases in 10 months. Most represent both bug fixes and enhancements.
# zypse inxi | inxi | package | 3.3.07-bp154.1.19 | noarch | OSS | inxi | package | 3.3.20-lp154.46.1 | noarch | Utilities # cat /usr/local/bin/zypse #!/bin/sh zypper --no-refresh se -s $* | egrep -v 'debug|devel|srcp|openSUSE- 20' | egrep 'x86|noarch'| sort
Leap's inxi version was out of date more than 10 months ago. Its kernel version reporting began in 3.3.21. Latest functionality is available in the devel version pinxi: http://smxi.org/pinxi
# inxi -Cxx --vs inxi 3.3.21-00 (2022-08-22) CPU: Info: dual core model: Intel Core i3-4150T bits: 64 type: MT MCP arch: Haswell level: v3 rev: 3 cache: L1: 128 KiB L2: 512 KiB L3: 3 MiB #
Its -U switch run with sudo will update inxi to current, so old version isn't a serious issue except when a new feature leaks out before official release. Users who use -U now will find level reported.
--
Luboš Kocman (he/him) openSUSE Leap Release Manager
SUSE +1 2345678910 www.suse.com