Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Caution when updating BIOS with Intel Alder Lake (12th Gen)
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
cjorden
n00b
n00b


Joined: 26 Jan 2022
Posts: 2

PostPosted: Wed Jan 26, 2022 10:03 pm    Post subject: Caution when updating BIOS with Intel Alder Lake (12th Gen) Reply with quote

I am writing this to inform anyone who is using Alder Lake systems to watch out for breakage when doing BIOS updates. This is most likely to be an issue in the first few months of 2022, but could persist to later. This is probably most likely an issue on certain CPUs in the Alder Lake family that only have P cores (Core i5-12500, i5-12400, i3-12300, i3-12100, Pentium Gold G7400, and Celeron G6900 at least).

These are the conditions that caused the problem I encountered:

  • Performance core-only 12th Gen Intel CPU (Core i5-12400)
  • BIOS on my motherboard was from December 2021
  • Running Gentoo (although other circumstances where someone compiles code on their systems could trigger this as well)
  • Compiling code (Gentoo CFLAGS) with -march=native

I have a Core i5-12400 that I purchased mid-January from Newegg. I also purchased a Gigabyte B660M DS3H AX DDR4 motherboard.

When I received the motherboard, there were no BIOS updates available from Gigabyte. The BIOS it ran was "F4".

I proceeded to install Gentoo and set things up. I run Gentoo with my COMMON_FLAGS="-march=native -O2 -pipe".

A couple of days ago, I checked, and saw there was a new BIOS for my board on Gigabyte's site. I proceeded to download it and flash my system with it. After a reboot, a number of things failed to start, including D-BUS and GDM. I tried to log in, but after entering my username and password in the text-mode console, it immediately appeared to log me off, and asked for my username and password again. I booted into the system with init=/bin/bash on the kernel command line, which gave me access to the filesystem. I saw in my system logs the follow errors:
Code:
Jan 25 19:11:07 localhost kernel: traps: systemd-udevd[2198] trap invalid opcode ip:55d6d6bbce73 sp:7ffc092029c0 error:0 in udevadm[55d6d6b9b000+a6000]
Jan 25 19:11:08 localhost kernel: traps: hwclock[2287] trap invalid opcode ip:55b6b74f3610 sp:7ffda5469678 error:0 in hwclock[55b6b74f1000+e000]
Jan 25 19:11:09 localhost kernel: traps: dbus-daemon[2649] trap invalid opcode ip:7fb3fa6c25d4 sp:7ffeec780440 error:0 in libexpat.so.1.8.3[7fb3fa6bc000+1e000]
Jan 25 19:11:09 localhost kernel: traps: dbus-daemon[3009] trap invalid opcode ip:7f345f2ee5d4 sp:7ffec9de44d0 error:0 in libexpat.so.1.8.3[7f345f2e8000+1e000]
Jan 25 19:11:09 localhost kernel: traps: dhcpcd[3069] trap invalid opcode ip:55ec0f9432e0 sp:7ffcabe03710 error:0 in dhcpcd[55ec0f918000+38000]
Jan 25 19:11:10 localhost kernel: traps: systemd-udevd[2169] trap invalid opcode ip:55d6d6bbce73 sp:7ffc09202830 error:0 in udevadm[55d6d6b9b000+a6000]
Jan 25 19:11:22 localhost kernel: traps: login[3293] trap invalid opcode ip:7f4413fc9a25 sp:7ffd6b311e50 error:0 in libpam.so.0.85.1[7f4413fc9000+8000]

I was surprised to see this, but I had read that AVX512 was sometimes enabled for Alder Lake, so I started investigating to see if this was from AVX512 possibly being disabled by my BIOS update. Long story short, it was.

I had not configured anything in my BIOS settings for AVX512, so I was not expecting this type of issue to crop up, but a quick look at the flags in /proc/cpuinfo showed that I did not have AVX512 while running the new "F5" BIOS. I went searching for the previous "F4" BIOS, and was fortunate enough to find it (though the download link was removed, it was still on Gigabyte's download server).

I was able to flash back to "F4", and sure enough, I found that avx512 was enabled by default with this motherboard/cpu combination. I was able to boot into my system, and it worked perfectly again. I found the cpu flags that were disabled with the bios update to "F5" to be the following:
Code:
avx512f
avx512dq
avx512ifma
avx512cd
avx512bw
avx512vl
avx512_bf16
avx512vbmi
avx512_vbmi2
avx512_vnni
avx512_bitalg
avx512_vpopcntdq
avx512_vp2intersect
avx512_fp16

I checked through the "F5" BIOS, and found some AVX setting where I could enable AVX. However, when I did that, the kernel crashed on boot. Thus, I believe the microcode included in the F5 bios disables the AVX512 instructions, and the BIOS knows that by default. Force enabling AVX512 in the BIOS on the "F5" version seems to tell the system that AVX512 is available, but the instructions fail to execute.

I ended up changing my COMMON_FLAGS to use -march=skylake, and I am doing a full system rebuild with emerge -ev @world while running the F4 BIOS. I then plan to update to the F5 BIOS and change back to -march=native, and run an emerge -ev @world again. I considered running emerge from the F5 bios when booted with init=/bin/bash, but found out that the main python library also contained AVX512 instructions, so it would generate an invalid opcode error and emerge would not run. I could just stay on the F4 bios, but I like to stay up-to-date with the BIOS and microcode updates on my systems.

In the course of investigating this, I found the elfx86exts tool, which I ran against some of the libraries that were logging invalid opcode when running the "F5" BIOS. Sure enough, they contained AVX512 instructions. Here is what I saw in "libpam.so.0.85.1":
Code:
$ elfx86exts /lib64/libpam.so.0.85.1
MODE64 (call)
CMOV (cmove)
AVX (vxorps)
NOVLX (vxorps)
AVX512 (vcvtusi2sd)
CPU Generation: Unknown

After compiling with -march=skylake, I saw this:
Code:
$ elfx86exts /lib64/libpam.so.0.85.1
MODE64 (call)
CMOV (cmove)
AVX (vxorps)
NOVLX (vxorps)
CPU Generation: Unknown

Overall, I am surprised how this turned out. The coverage of AVX512 on Alder Lake has said that disabling AVX512 would not impact anyone, but I don't think the news outlets considered CPUs without E-cores, and the possibility that some motherboards would enable AVX512 for such CPUs by default.

My suggestion is to check your Alder Lake systems to see if AVX512 is enabled. If it is, expect a future BIOS update to disable it. If you want to be prepared, I would suggest using -march=skylake as a safe march option for when such an update gets installed.

If you have any questions, reply to this thread.
Back to top
View user's profile Send private message
christoph_peter_s
Tux's lil' helper
Tux's lil' helper


Joined: 30 Nov 2015
Posts: 106

PostPosted: Fri Feb 04, 2022 10:23 am    Post subject: Reply with quote

First of all: Thank You cjorden for pointing this out. I've ordered an Alder Lake to upgrade my home server, and this information seems highly important.

I have however one additional question regarding the CFLAGS. I read here: https://gcc.gnu.org/gcc-11/changes.html that there is a new target Alderlake. Hence I ask myself in the light of Your report: Is
Code:
-march=alderlake
safe? Or would this run me into severe troubles. I am not sure, whether I would have been able to fix You issue other than sticking with the old bios (should be OK, as I've got old DDR4 RAM).

TIA & Best regards
Peter[/quote]
Back to top
View user's profile Send private message
cjorden
n00b
n00b


Joined: 26 Jan 2022
Posts: 2

PostPosted: Sat Feb 05, 2022 12:22 am    Post subject: Reply with quote

Hi christoph_peter_s,

Based on the information in the link you posted, the instructions enabled by the -march=alderlake do not include AVX512 (and Intel has clarified their position in not officially enabling AVX512 in this generation in early January too).

Thus, -march=alderlake should be safe, if you wish to use it. The flags it enables are:

Code:
the CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, KEYLOCKER, AVX-VNNI, and HRESET ISA extensions


I hope this helps.

- caljorden


christoph_peter_s wrote:
First of all: Thank You cjorden for pointing this out. I've ordered an Alder Lake to upgrade my home server, and this information seems highly important.

I have however one additional question regarding the CFLAGS. I read here: https://gcc.gnu.org/gcc-11/changes.html that there is a new target Alderlake. Hence I ask myself in the light of Your report: Is
Code:
-march=alderlake
safe? Or would this run me into severe troubles. I am not sure, whether I would have been able to fix You issue other than sticking with the old bios (should be OK, as I've got old DDR4 RAM).

TIA & Best regards
Peter
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum