El9 will require x86-64-v2 support

This won’t apply to us Rocky folks for a while but it’s a useful bit of information for forward planning.

el9 will require your AMD or Intel 64 bit cpu to support a minimum of x86-64-v2.

Here is a script to find out what you’ve got.

#!/usr/bin/awk -f
 
BEGIN { 
    while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1
    if (/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/) level = 1
    if (level == 1 && /cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) level = 2  
    if (level == 2 && /avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/) level = 3
    if (level == 3 && /avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) level = 4
    if (level > 0) { print "CPU supports x86-64-v" level; exit level + 1 }
    exit 1
}
2 Likes

On the CentOS mailing list, someone posted the following command whose output includes the info of interest:

/lib64/ld-linux-x86-64.so.2 --help

Hmm “recommends” and “optional” make it sound not “required” but in any event, the Wikipedia article on X86-64 says v2 goes back to 2009’s Nehalem microarchitecture.

My AMD motherboards don’t last long enough for this optional architecture to be a restriction.

/lib64/ld-linux-x86-64.so.2 --help says on Westmere EP Xeon (released Q1 2010):

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3
  x86-64-v2 (supported, searched)

Legacy HWCAP subdirectories under library search path directories:
  x86_64 (AT_PLATFORM; supported, searched)
  tls (supported, searched)
  avx512_1
  x86_64 (supported, searched)

I get the same values on a Core i5 750 (“Lynnfield”) from Q3 2009.

Heh, this not-a-server is now 12 years old. But it’s still working well enough :slight_smile:

OK I don’t do much scripting. Do I simply past the above script into the CLI and hit enter?? If not how do I run that script?? Sorry for the dumb question.

That is clearly content of a file. The first line contains #!/usr/bin/awk -f
The script is written for AWK.

Say you save that text into file named ‘support_level’ and give it executable permissions:
chmod +x support_level
Then you should be able to run it with: ./support_level
When you do that the shell looks at the #! line and will run /usr/bin/awk -f support_level for you.

Without executable permission it is still possible to run the script with:
awk -f support_level

You will get bit different output, if you run:
/lib64/ld-linux-x86-64.so.2 --help

note: this works only with RHEL 8 and newer, it does not work with RHEL 7, use the above awk script in that case.

Indeed:

[CentOS 7]$ /lib64/ld-linux-x86-64.so.2 --help
--help: error while loading shared libraries: --help: cannot open shared object file

… and that was not the difference that I had in mind. :flushed:

It depends on version of ‘glibc’ and is not specific to RHEL. For example, recent Ubuntu has this “new, fancy glibc” while “quite recent Ubuntu” doesn’t.

Hehehehe Thanks. I’m more interested in this to see if ocelot will be able to run RL 9.x, or any other OS that might demand x86-64-v2 support. In this case the “other OS” would be the next reiteration of openSUSE. I would suspect ocelot with its AMD Ryzen 9 5900x CPU and its ASUS Prime X-570 Pro motherboard should be up to the task. That said I would suspect leopard which is currently some 6-8 years old, and currently running CentOS 7.9 will NOT.

And if that script reports:

CPU supports x86-64-v1

Then I’m dead in the water…

No, not yet. By 2029.

Well, I guess, that’ll make for a lot of miles out of a fairly old (2007) touch-screen lappy converted into a lil’ol kiosk/ home server :slight_smile:
Lets hope it’s got another 7 years left in it.