Linux on SER9.

old486whizz

FIX<< I have a fix for the greenscreen / random crashing.
So, after a great amount of tracking bugs down, it appears it’s down to a scheduling issue with shaders. I was able to muck about with the “amdgpu” driver to enable the mes scheduler, and disable power management etc - those reduced the occurrences butthey still happened in my specific test case.
I even tried changing the PBO (Precision Boost Override) settings since I read that over/undervolting may cause issues with timing (as well as clocking).. And allowing for a minor overvolting and allowing the CPU to sustain higher clocks for longer did reduce the times it happened - but it still hapened.
…. until I found the mesa debug variables page, describing that we can use
RADV_DEBUG=shadersync
If you add that as an environment variable before the program (or into /etc/environment…. or in Steam you can add it before %command% in the properties window) then the MESA drivers will sync the shaders.
… You’ll lose ₂% of performance (from what I can see during testing).. But I would rather have that lower performance vs a system that crashes!

support7

Here are the potential solutions:
Please try to update the driver
Please change another HDMI/DP cable.
Please go to display setting. Please adjust your display settings in the operating system or graphics driver control panel to the recommended settings.

old486whizz

So, My fix is confirmed to work (for me).
The setting of “RADV_DEBUG=syncshaders” before any program or in the steam settings prevents any crashing (I think this is probably the AMD drivers and Vulkan - but it could also be a base AMD hardware issue).

I would like to share a tip with everyone too on performance.
I can get in some cases a ₃₀% gain in performance if I set these kernel parameneters (they go into the grub configs - I could go further into details but due to different distro’s it is best to check that yourself):
amdgpu.mes=1 amdgpu.mes_kiq=1 amdgpu.uni_mes=1

These settings use the newer MES Hardware scheduler, which seems to be much better than the default scheduler in the hardware.
I monitored using “radeontop” and “sensors” (which showed me the GPU performance usages, power use and temperatures) and I didn’t notice any significant changes in the use before or after - but I was getting a significant leap in FPS in several “vkmark” results (in some cases a leap from 21000->31000 - which is ₃₀%!!).

I’m sharing these bits in the hope that others may benefit from the information.

–
old486whizz

support7

Thank you for your feedback.

oddhack

Data point: I just installed Debian Trixie (testing) from the latest ISO, and it is working, bringing up gdm, runs glxgears / vkgears with the AMD Mesa drivers. Have not tested to see whether HW acceleration is happening aside from noting that vkgears -present-mode -fullscreen runs at 6700 FPS on a 4K display, which feels like a lot for a software renderer despite how simple the image being rendered is. More encouraging than I was expecting and perhaps I won’t need to migrate to Ubuntu after all.

oddhack

Also to note, the Windows 11 install was borked up. Initially it came up in Win 11 and was extremely unhappy with me because I didn’t have a network connection, which forced a power cycle. Then trying to shrink the 950 GB partition on the first SSD seemed to succeed, but then installing trixie in the free space didn’t seem to install the bootloader properly and it returned to Windows when rebooted - followed by failing to fix the disk problems and eventually saying I’d have to reinstall. At that point I didn’t even know where the local restore partition was - I got an SER9 with 2TB SSD, which turned out to be two separate SSDs each with a huge NTFS partition on them - and I gave up and let the Debian installer completely format NVM0. So I am probably going to have to reinstall Windows 11 from an ISO, and will need the product key. I gather this requires catching the attention of support here, then PMing them a picture of the product ID sticker and the BIOS boot screen? Not sure of the process.

support10

oddhack

Hello there,

Could you please send us a picture of SN code at the bottom of machine ?

Then we will send you the corresponding the key.

Have a nice day!

old486whizz

Just to say - using the MES scheduler is actually worse for FPS.
I must have tested backwards, so please ignore my earlier comment about the MES scheduler - it knocks 30% off, not adds it on - I’m sorry.

support7

Thank you very much for your feedback on the MES scheduler.

dodosoft

I’ve just received a SER9 (Ryzen AI 9 HX 370) of the latest model with 64Gb of RAM. The SN starts with “DH”.
I’ve tried to install both Arch Linux and Fedora Linux on it. In both cases, I can boot the ISO and run the installer but upon rebooting into the newly installed system, the screen goes black as the monitor complains about a lack of Thunderbolt signal.
I can boot into Fedora only by selecting the “rescue mode” on the bootloader menu.

I noticed that both Arch and Fedora have very recently received an update for their linux-firmware package which is now at version 20250311.

Since I read above about success stories where people run the 20241210 version with the latest BIOS, I wonder whether the problem I am facing is due to the newest firmware version, which is just days old, or whether perhaps it is something specific to the 64Gb version of the hardware I am using.

Has anyone tested their PC with the 20250311 version of linux-firmware?
Does anyone have a SER9 with 64Gb of RAM running Linux?

support4

dodosoft Hi there

Please send us a picture of SN number and BIOS version .
So we would be able to know whether it is latest BIOS and send you files accordingly.
Here`s how to check your BIOS version:

Prese : Win + R ,
Type : msinfo32
Send us the screen.
or try this
https://mega.nz/#F!yuISGa4I!s1bQQajKwnsEdzjqq4nopQ

support6

dodosoft
Hello there,

The latest BIOS update has been sent to you.
Please see “Discuss Privately”.

Best regards!
Yue
Customer Support

dodosoft

support4
The BIOS version is SER9T301 with build date 01/10/2025 18:03:55
The SN is DHX375EGxxxxx (Here, I am redacting the last 5 characters. I will send an email to customer support with the full SN).

old486whizz

@dodosoft - I am using Fedora.
Mine installed pretty fine, and is booting up just fine (I use KDE), I’m using a 32GB SER9 and my Fedora is fully updated.
My bios version is “SERT103”, it came from factory with that BIOS (showing a time of 10/28/2024).
I Tried to update the BIOS using a supplied BIOS update from beelink in February, but it turned out it was the same build and apparently “the latest”.

… Unless they have produced another BIOS version for a different memory size (please tell me that’s not the case!) then maybe the new BIOS could be at fault here?

I can try to help you through some debugging steps if you’d like?

support1

old486whizz Hi there,

Could you please send us a picture of SN on the bottom of the PC, we will check if you need to update the BIOS

USA Pharma

Mine installed pretty fine, but it turned out it was the same build and apparently “the latest”.

support7

Thank you for your reply. If it is the latest BIOS, then no update is needed.

coatlicue89

A. Hartmann Regarding the amdgpu power issue for firefox videos I tried using amdgpu.dpm=0 and it worked. Later i decided to switch from grub to systemd-boot and forgot to add this param but found out that I didn’t have the issue anymore.

support7

coatlicue89 Thanks for your help and feedback.

coatlicue89

coatlicue89 correction, seems to be failing again after a linux-firmware upgrade so I guess what happened is that when i installed systemd-boot I ended up downgrading the amdgpu driver version.

support7

coatlicue89
Here are some potential solutions:
①. Confirm the driver and firmware status.
Check the currently loaded amdgpu driver version: dmesg | grep amdgpu
Check the installed firmware package version: apt list –installed | grep linux-firmware

②. Synchronize the driver and firmware versions.You can update driver from this website.kernel.org

« Previous Page Next Page »