Happy New Year! I think it's time I send you an update:
I have spent a considerable amount of time trying to get the latest
firmware working, but I find a way that does the job.
When I replaced the file with yours, the machine directly restarts on
application of the firmware.
All ways I have tried either result in the firmware not being considered
or the machine rebooting on application.
The machine is dual boot with Archlinux and on Archlinux, I have the
latest firmware running.
I have reached out to the Qubes people for help getting the latest
firmware working. I'll let you know when I succeed with that.
~Joe
On 12/19/23 11:00, Andrew Cooper wrote:
On 19/12/2023 4:28 pm, Joe Tretter wrote:
On 12/19/23 10:05, Andrew Cooper wrote:
Is it always the same test which fails, or is it random?
Which test fails seems to be random (see attached screenshot).
Looking athttps://github.com/Tarsnap/scrypt it's only a trivial piece
of userspace crypto.
The fact that running multiple instances makes it fail more easily
points towards some kind of register handling issue, but the fact that
it repros only under Xen, and even with eager-fpu (which isn't the
default on AMD, sadly), is weird.
Looking at the scrypt source, it has alternative routines for the AESNI
and SHANI instruction groups. However, because it's a Zen1, we don't
have a useful way of filtering visible for PV dom0 userspace.
First of all, can you get the exact CPU model and microcode version.
`head /proc/cpuinfo` will be enough. But while you're at it, can you
include `xl dmesg` too just in case there's something obvious showing up
there too.
I have attachted text files with the (full) cpuinfo and the dmesg.
microcode : 0x8001129
That's 0x08001129 when not rendered brokenly, and the up-to-date version
is 0x08001138 (which itself dates from 2019).
If you can, get a firmware update. Given that it's a Dell, there's a
good chance it's already on LFVS/fwupd. This is definitely the
preferred option.
If not, and you're willing to experiment in definitely unsupported
territory, then move /lib/firmware/amd-ucode/microcode_amd_fam17h.bin
sideways in dom0, and replace it with the attached SummitRidge-08001138
file (it's important to still be named microcode_amd_fam17h.bin in the
end), then rebuild the initrd and reboot.
You already have ucode=scan on Xen's command line, so after the reboot
you should see some messages about updating microcode too.
Irritatingly, AMD don't put client microcode into linux-firmware, but
there are various collections of blobs found in the wild online. I've
picked the one which I think is right for your CPU, and packaged it it
appropriately for Xen.
Anyway, I'm not sure if this will fix anything, but life is too short to
be debugging stuff like this on out-of-date firmware/ucode.
~Andrew
