On 26/09/24 at 14:53, Jörg-Volker Peetz wrote:
A new microcode for your CPU should be inside of
/usr/lib/firmware/amd-ucode/microcode_amd_fam15h.bin
since it says 'family: 0x15' in your output.
There is a little program on https://github.com/AMDESE/amd_ucode_info to
look into the microcode file. For the package amd64-microcode on Debian
testing version 3.20240820.1 it yields:
$ amd_ucode_info.py /usr/lib/firmware/amd-ucode/microcode_amd_fam15h.bin
Microcode patches in
xx/usr/lib/firmware/amd-ucode/microcode_amd_fam15h.bin:
Family=0x15 Model=0x01 Stepping=0x02: Patch=0x0600063e Length=2592 bytes
Family=0x15 Model=0x02 Stepping=0x00: Patch=0x06000852 Length=2592 bytes
Family=0x15 Model=0x10 Stepping=0x01: Patch=0x06001119 Length=2592 bytes
So yes, your CPU microcode is up-to-date.
Thank for the exhaustive answer, I've another question: time ago I
submitted a bug report against the "linux-kbuild-6.1" package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935536
The report describes a failure of "objtool" command while compiling the
Kernel. Coincidentally when the date of the CPU's microcode was changed
and that failure of "objtool" almost they match.
So the question is: Can a CPU microcode update cause incompatibility
between objects (*.o files) built by the GCC compiler and the "objtool"
command while compiling the Kernel?
Thank again,
--
Franco Martelli
