On Mon Aug 12, 2024 at 1:43 AM CEST, Henrique de Moraes Holschuh wrote: > > I got the *impression* that some heuristic was used to determine whether the > > microcode update should be applied. > > No. It has a simple heuristic to not increase the initramfs size by adding AMD > microcode updates unless either it is running on an AMD processor when the > amd64-microcode package is installed, OR you configure amd64-microcode to > always add the updates to the initramfs. It is an "all or nothing" thing, > and currently it has absolutely no "processor-model-aware" logic.
Good to know, thanks :) And now I could also find that ``debian/initramfs.hook`` has it. The main thing that had me worried was from ``amd64-microcode-blacklist.conf``: > # The microcode module attempts to apply a microcode update when > # it autoloads. This is not always safe, so we block it by default. I had written a couple of paragraphs before I realized the check is for kernels *older* then 4.4. Since then the module is built-in (and not selectable), so that file no longer 'actually' does something. > *Uploading* the microcode update to the processor is handled by the kernel > ... [ interesting description on how it works ] ... It turns out that the problem is not with the CPU, but Asus BIOS/firmware: > It appears that the BIOS has blocked access to the MMIO range for the > CCP so that during initialization, when attempting to read the number of > queues available, 0xffffffff is read instead of the actual number of > queues available, which as Jason noted, results in the "broken BIOS" > message. https://lore.kernel.org/linux-crypto/c28836c4-e823-dc36-e753-1a5ee3831...@amd.com/ But it seems Asus isn't interested in fixing it because they consider AM4 an outdated platform and I should just accept that some things won't work... Which I ofc will never accept, so that'll be a RMA :-/ > > I'd like to know whether I'm actually running the latest microcode, but I > > haven't figured out a way how? > > /proc/cpuinfo should report the running microcode version on a recent enough > kernel. It will also log the microcode revision when it does a microcode > update. FWIW: That same version is also reported in ``dmesg``. > There is no facility to check whether what is in your system's > /lib/firmware/amd-ucode is the latest available microcode update that has been > issued by AMD to the linux-firmware project, That sucks as this was the thing I was looking for. But as written above, it seems irrelevant to the original problem I tried so solve. > I hope this information solves any lingering doubts about how it works? It does and was an interesting read, so thanks for that. AFAIC you can close this bug. I'll leave it up to you whether it's useful/worth it to maybe update some comments (like not applicable with kernels > 4.4). Cheers, Diederik
signature.asc
Description: PGP signature
