I have recently installed Gentoo Linux on my AMD Ryzen 7 1700X. Now I face segmentation faults during heavy compilation loads and also random restarts in an idle state.
As a very first step I verified the current microcode version:
grep -m 1 microcode /proc/cpuinfo
microcode : 0x8001126
However, according to this table the latest microcode should be 0x08001129. It thus seems to be a good idea to update the microcode for the CPU.
So I emerged =sys-kernel/linux-firmware-20180730
(containing /lib/firmware/amd-ucode/microcode_amd_fam17h.bin
).
Further, I enabled the following options in the kernel:
CONFIG_MICROCODE=y
CONFIG_MICROCODE_AMD=y
After a reboot, I tried loading the microcode manually (late microcode update):
echo 1 > /sys/devices/system/cpu/microcode/reload
However, when I do this, no new line appears in dmesg
:
dmesg | grep microcode
[ 0.465121] microcode: CPU0: patch_level=0x08001126
[ 0.465514] microcode: CPU1: patch_level=0x08001126
[ 0.465932] microcode: CPU2: patch_level=0x08001126
[ 0.466394] microcode: CPU3: patch_level=0x08001126
[ 0.466772] microcode: CPU4: patch_level=0x08001126
[ 0.467159] microcode: CPU5: patch_level=0x08001126
[ 0.467537] microcode: CPU6: patch_level=0x08001126
[ 0.467908] microcode: CPU7: patch_level=0x08001126
[ 0.468268] microcode: CPU8: patch_level=0x08001126
[ 0.468653] microcode: CPU9: patch_level=0x08001126
[ 0.468999] microcode: CPU10: patch_level=0x08001126
[ 0.469409] microcode: CPU11: patch_level=0x08001126
[ 0.469744] microcode: CPU12: patch_level=0x08001126
[ 0.470136] microcode: CPU13: patch_level=0x08001126
[ 0.470455] microcode: CPU14: patch_level=0x08001126
[ 0.470757] microcode: CPU15: patch_level=0x08001126
[ 0.471092] microcode: Microcode Update Driver: v2.2.
I would expect something like microcode: CPU0: new patch_level=0x08001129
.
What am I missing here?
Some kernel CONFIG_
option?
Can I turn on some sort of debug information?
Or even better – how can I list the microcode version provided in microcode_amd_fam17h.bin
?
/usr/src/linux/arch/x86/kernel/cpu/microcode
... – DaBler Sep 17 '18 at 17:02if
block isn't entered; the reason seems to be that it's because the microcode revision in the CPU is already at least as high as the one on the disk. However I'm aware that this shouldn't be the case for you, according to all the info in OP. So maybe it's this otherif
that enters instead! What motherboard do you have? – Sep 18 '18 at 06:04What motherboard do you have?
question. I thought thatCFG Lock
in my BIOS had anything to do with updating microcode, but looking into it, it doesn't seem to; it's about C States and power management. – Sep 18 '18 at 06:56if
block gets hit. I really think there should be a message when the microcode update fails and it should state current and on-disk microcode revision numbers. (for inspiration see this and boris3of2.patch) – Sep 18 '18 at 07:06* CPU microcode is the latest known available version: YES (latest known version is 0x96 according to Intel Microcode Guidance, August 8 2018)
. Maybe you'll get a similar message(?) – Sep 20 '18 at 09:22pr_info
s as you suggested. – DaBler Sep 20 '18 at 11:45CPU microcode is the latest known available version: UNKNOWN (latest microcode version for your CPU model is unknown)
– DaBler Sep 20 '18 at 11:49pr_info
calls toarch/x86/kernel/cpu/microcode/…
The call path for early builtin microcode loading goes throughapply_microcode_early_amd
,scan_containers
toparse_container
, but never hits this block… which may be the problem. Not sure anyway. The call path forfind_microcode_in_initrd
goes the same way. In the case of late loading, the path ends with theNot reloading previously-loaded already-in-effect microcode!
(in the patch you linked). – DaBler Sep 20 '18 at 13:14to list the content of the microcode file
. On another note: assuming you already have SMT disabled, do you have this commit in your kernel ? What about this (non-SMT related) one ? – Sep 20 '18 at 14:25=sys-kernel/gentoo-sources-4.14.65
). I however don't have the second one. (I can try it later.) I have added a lot of debug printings and this is what I currently see indmesg|grep microcode
. The/proc/cpuinfo
still reports patch level0x8001126
. – DaBler Sep 21 '18 at 12:580x08001227
:D but due tocache_find_patch return NULL
you don't, my guess. – Sep 21 '18 at 15:220x8012
whereas my cpu rev id is0x8011
. – DaBler Sep 21 '18 at 16:41