GTR9-Pro & Fedora 43: Random Crashes & Out of Date CPU Microcode

Benjamin

I’ve been trying to get my new GTR9-Pro to be stable, and have hit a wall.

I have updated to Bios version GTRP110 and that solved a lot of the issues I was having. However I’m still having serious issues with crashes, seemingly at random. It’s not limited to any specific apps, and it feels like a hardware issue.
I’ve run memtest overnight and it passed all the ram 11 times.
It’s not overheating.
While trying to diagnose the issue, I realized that the amd-firmware package in Fedora has a newer cpu microcode file than the one included in BIOS version GTRP110. Also, it seems that it’s not possible for the OS to update the CPU microcode. It’s not even trying.
This CPU shows up like this:

$ sudo dmesg | grep CPU0
[ 0.309784] smpboot: CPU0: AMD RYZEN AI MAX+ 395 w/ Radeon 8060S (family: 0×1a, model: 0×70, stepping: 0×0)

And the latest firmware has this version:
$ amd_ucode_info.py /usr/lib/firmware/amd-ucode/microcode_amd_fam1ah.bin | grep ‘Family=0×1a Model=0×70 Stepping=0×00’
Family=0×1a Model=0×70 Stepping=0×00: Patch=0×0b700037 Length=14368 bytes

However the version the bios has is:
$ sudo dmesg | grep microcode
[ 0.522230] microcode: Current revision: 0×0b70001e
This version is also listed in the BIOS interface itself.

I’m not sure how many revisions there were between 1e>37, but there could be a lot.
I cannot update the microcode from the OS side, unless I’m missing something. I’m hoping a new BIOS can be provided so I can see if that fixes this random instability.

I really, really hope I don’t need to RMA this thing. :(

Rong

Benjamin However the version the bios has is:
$ sudo dmesg | grep microcode
[ 0.522230] microcode: Current revision: 0×0b70001e
This version is also listed in the BIOS interface itself.

I’m not sure how many revisions there were between 1e>37, but there could be a lot.
I cannot update the microcode from the OS side, unless I’m missing something.

Upgrading microcode from OS is only possible when the base microcode revision is >0×0b700031 due to the “Entrysign” vulnerability.
See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/cpu/microcode/amd.c?h=v6.18#n230

Beelink CS-George

1.Disable the NIC: BIOS > Advanced > Demo Board > “Device 3 Fun 2”: Disabled
2.Boot to OS
3.Run something that brings the temp. up to _75℃ for a while (e.g: furmark with appropriate fan profile)
4.Boot to BIOS and re-enable the NIC
5.Please do not remove the power supply.

Please also try this firmware https://www.intel.com/content/www/us/en/download/845347/non-volatile-memory-nvm-update-package-for-intel-ethernet-e610-series.html

Benjamin

I’m back in the office. Happy Monday. I will attempt this, but I’m not having any issues at all with the ethernet. In fact I stress tested it at 10Gb/s for more than 30 minutes, and the SWITCH started dropping packets.

Maybe that’s not the nature of the problem you’re suggesting, so I’ll try this and reply.

jotapesse

However I’m still having serious issues with crashes, seemingly at random.

I will attempt this, but I’m not having any issues at all with the ethernet. In fact I stress tested it at 10Gb/s for more than 30 minutes, and the SWITCH started dropping packets. Maybe that’s not the nature of the problem you’re suggesting, so I’ll try this and reply.

Benjamin I would say that your issue doesn’t seem to be related at all to the specific NIC issue on this thread. Best to raise it on a separate thread please, so that you don’t hijack this (already long) thread with it. Also, on that new thread to be raised, try to check and indicate your Fedora system logs errors at about the time of the system crash, they can help to pinpoint the issue. Thanks! 🙏

Benjamin

jotapesse
Jotapesse, I don’t understand. I started this thread, and didn’t say anything about a NIC issue in my original post.
The Beelink Admin/Mod brought this up as a possible fix for my random crashing issues, and I’ve applied them to see if that fixes it.
I think you’re replying in the incorrect thread.

jotapesse

Jotapesse, I don’t understand. I started this thread, and didn’t say anything about a NIC issue in my original post. I think you’re replying in the incorrect thread.

Benjamin Ahhh… Apologies! Nevermind, my bad, I was under the impression this was a different thread. Too much threads on my mind. Sorry!

try to check and indicate your Fedora system logs errors at about the time of the system crash, they can help to pinpoint the issue.

Anyway, my suggestion above stands. You should check your linux system logs to find any possible errors prior or about the time the system crashed. You may find errors that can point you/us to the right direction. In example, on my GTR9 Pro, myself and others have experienced random system freezes due to the atomic modesetting pageflip issues (within the amdgpu kernel driver). You may read more about it, the logged errors and the current workaround on that thread.

Benjamin

For the record, here is my CPU temps while using stress-ng, with the NIC disabled in BIOS:
Image description
And here is the result of updating the NIC Firmware:
$ diff before after
← [Module type=“EFI” version=“8.2.96” update=“0”]
→ [Module type=“EFI” version=“8.3.5” update=“0”]

← [Module type=“NVM” version=“8000EA8C” update=“0”]
→ [Module type=“NVM” version=“8000EDE1” update=“0”]

← [Module type=“EFI” version=“8.2.96” update=“0”]
→ [Module type=“EFI” version=“8.3.5” update=“0”]

← [Module type=“NVM” version=“8000EA8C” update=“0”]
→ [Module type=“NVM” version=“8000EDE1” update=“0”]

So the NIC did get updated. I’ll report back with results.

Benjamin

jotapesse
Thanks!
I did have freezes before updating the BIOS, now it’s seemingly random process crashes, and weird SSL issues. This just happened:

C05C7BB8D37F0000:error:1C80009E:Provider routines:ml_kem_pairwise_test:invalid key:providers/implementations/keymgmt/ml_kem_kmgmt.c:144:public part of ML-KEM-768 private key fails to match private C05C7BB8D37F0000:error:030000B4:digital envelope routines:new_raw_key_int:key setup failed:crypto/evp/p_lib.c:468: ssh_dispatch_run_fatal: Connection to 10.10.2.6 port 22: error in libcrypto

This is using SSH Agent, and the next connection works fine. I have it connecting once a second in a loop to test, and once in a while I get this.

Also have Firefox crashing, chrome tabs crashing, and random SSL connection errors. It’s like it’s not doing the math right.

It seems a little better since the LAN firmware update, but maybe there are multiple issues. I really wish there was a BIOS with updated CPU microcode to at least eliminate that as a possibility.

What version does yours show in the BIOS? Mine shows 0×0b70001e

jotapesse

I really wish there was a BIOS with updated CPU microcode to at least eliminate that as a possibility. What version does yours show in the BIOS? Mine shows 0×0b70001e

Benjamin Same here. Desktop CPU microcode updates are done via BIOS/UEFI, therefore we depend on @Beelink to validate those updates and provide a BIOS/UEFI update with it. So hopefully this can be raised internally @Beelink CS-George?

Current latest AMD Ryzen AI MAX+ 395 (family: 0×1a, model: 0×70, stepping: 0×0) cpu microcode update available from AMD is 0x0b700032. But we are all on the older 0x0b70001e.

$ sudo dmesg | grep microcode
[    0.517926] microcode: Current revision: 0x0b70001e

Regarding all those issues you are experiencing… something is off there. Potentially those SSL/certificates errors can lead to browser crashing, but I’m just speculating, you would need to check the logs on each of them to better understand what may have happened. Hopefully you are running a recent Linux kernel version? Have you tried a different Linux install/distro and see if you get tthe same exact issues?

Benjamin

jotapesse
$ uname -a Linux BflStrixWS 6.18.5-200.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jan 11 17:09:32 UTC 2026 x86_64 GNU/Linux
Quite up do date Kernel. I could try another distro, but I’m running this same setup on an older all-amd system without any issues like this.
Signal (the messaging app) just quit with a corrupted database. This is all pointing to encryption issues. I wonder if there is a specific CPU function that’s not working.

I’m going to swap out to another SSD, install another distro, and see how it goes. Maybe it’ll help pin it down.

Benjamin

Rong
I read about that. That’s why we need the new microcode included in a BIOS update from Beelink. Once it’s up to date, we should be able to keep up with the firmware at the distro level.

Hopefully it’s coming in the next BIOS update, but I haven’t heard anything yet.

jotapesse

Rong and @Benjamin I just contributed on this post here with a request provide BIOS/UEFI updates with the latest required microcode (uCode) updates to address existing AMD CPUs vulnerabilities. 🙏 Feel free to contribute/reinforce it there, hopefully Beelink will notice it and address it.

Benjamin

I have replaced my SSD, and gone though several tests.

TL;DR = Did I have a bad install, or was the SSD bad?

I could not replicate the crashes with any other distro (as long as it had a 6.18 kernel).
I then tried cloning the original SSD to the new one, and the crashes we’re still there.
Then I tried the Fedora Live USB… no crashes.
Then I reinstalled to the new SSD… no crashes (yet).

I’m rebuilding my environment now, and if the crashes don’t come back, I can only assume that either the original SSD has an issue, or something got really corrupted in my old install and that was causing the issue.

I’ll report back tomorrow evening if the issue seems resolved.

jotapesse

Benjamin I could not replicate the crashes with any other distro (as long as it had a 6.18 kernel).
I then tried cloning the original SSD to the new one, and the crashes we’re still there.

Yes, that really sounds like a bad or corrupted system install. 🤦 Glad to know you’ve sorted it. Not sure why, but yes, there is the potential for a bad SSD as well.

Benjamin

I have not had any crashes or other issues since I reinstalled on a new ssd. I haven’t fully tested the old ssd, so it may be bad or may be fine. Unknown.

I consider the issue resolved. If anyone else finds this thread, I hope it’s useful.

… would still be nice to have that updated cpu microcode in the next BIOS update… :)