On Monday, December 23, 2019 at 7:51:33 AM UTC, Vít Šesták wrote: > > Qubes123, that's an interesting finding. AFAIU, the CPUID check is rather > a sanity check – it verifies that the microcode is loaded properly. I also, > this should be no issue if Qubes provides a fresh microcode… > > (And maybe it can cause crash if you suspend after BIOS update, provided > that the BIOS contains a newer microcode.) > > Regards, > Vít Šesták 'v6ak'
I use a Corebooted system, where the latest AMD microcode is compiled into the BIOS statically. And yes, I use a newer version of the AMD Fam15h microcode, than the version in the Linux Firmware package. This change in some of the CPUID bits after resume could be a result of xen/kernel trying to load the published microcode, and then fails because the BIOS version is newer. However, the /proc/cpuinfo reported microcode version always stays the same - the BIOS version. (..assuming the /proc/cpuinfo output is updated on any microcode upgrade attempts..) As noted, I have a "special" use case, so testing the recommended change in power.c for Claudia's newer AMD system could show, that this CPUID change issue after resume is "special" for my case or "general" for some AMD users. BR, Qubes123 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5389938b-69f2-4f58-bdc3-b18c5c059cf7%40googlegroups.com.