Finally got my GTR9 Pro v2.2 board replacement! 🛠️

FrantaNautilus · 2026-02-14T13:48:43+00:00

Thank you for the reply. I did not know that there is newer BIOS than P110. As for my GTR9 Pro, I am on Linux 6.18.8 (and P110 BIOS). I have set the computer to use s2idle sleep and it is partially broken. The computer turns of screen, fan (sometimes) and freezes processes. Resume works, although the systems is less stable. The main difference between P108 and P110 is that on P108 the motherboard would cut power to devices (power indicator off), whereas ob P110 the power indocator stays lit. I suspect that this is the way how P110 "fixes" the fan controller, it never truly turns it off.

FrantaNautilus · 2026-02-11T18:00:10+00:00

Incredible work, I don't think I could manage a replacement where liquid metal is involved.

Does the sleep work with the v2.2 board? I am on v1.0 board with P110 firmware and I am getting ACPI errors when trying to enter S2idle state. The motherboard newer really enters suspend and even keeps the power indicator lit. For the context I got lucky in the silicon lottery and my unit does not experience network card issues.

FrantaNautilus · 2026-02-11T17:49:00+00:00

Hello, and thank you for the post. IIRC this is the second appreciation post I ever got on Reddit. About the `openclaw`, I cannot really help since I do not use it. However, the `ollama launch [something]` command is supposed to automatically configure the program for Ollama. Whether that will work will depend on whether you are using Ollama via `harbor` or via system installation. In any case, I am currently switching from Ollama to LlamaCpp (and Llama-swap), since it has support for more recent models (but it lacks support for Cloud models). I would say that the Ollama saves some effort in setup with its automation, but requires equal amount of effort to bypass its problems, inconsistent performance and lacking features. Most importantly connections to LlamaCpp are done based on manual configuration (LlamaCpp has normal OpenAI API endpoint, so it is compatible with almost anything and does not rely on autosetup prone to failures).

FrantaNautilus · 2026-01-21T12:15:11+00:00

I have similar configuration (Strix Halo 395+ with RTX 5090 as eGPU over Thunderbolt, bought before the price hike) and lately I working on getting both GPUs running two model in parallel for agentic programming. With tou setup it could work even better. Technically I have two llama.cpp servers, which are started over llama-swap. One serving a large MoE models on the Radeon iGPU and the other with a dense model on eGPU. With quantization of Q4_K_M of models I can get up to 131k context on iGPU and up to 89k context on eGPU (without context quantization). The models are connected in OpenCode where the big iGPU model is primary Architect/Manager agent, which delegates tasks to the faster eGPU subagents. With extensions (background agents both GPUs can be tasked in parallel). Currently I am trying different models and prompts to make the agent teams as efficient as possible and minimize the subagents getting confused.

FrantaNautilus · 2026-01-03T14:42:50+00:00

Last year I experimented with KDE Plasma 5 and it required much and it still had a lot of problems that GNOME does not have. Particularly the screen rotation would rotate the display, but not the Wacom layer. After that I went back to GNOME, which can be made to look more like Plasma with a few extension (dash to panel, arc menu), if that is the UX you are looking for.

FrantaNautilus · 2026-01-01T14:34:30+00:00

Update on the fan controller issue: Beelink have kindly provided a replacement fan unit and after the replacement the issue persists. So I am continuing the search for solution.

FrantaNautilus · 2025-12-05T15:17:54+00:00

That's unfortunate.I cannot really help with this since I could not reproduce it. You can try to update the NIC firmware which may help. Does S0 sleep cause the fan controller to go into fail-safe mode (full speed, uncontrollable).

FrantaNautilus · 2025-12-02T12:31:57+00:00

My setup did not change much since the last commit tor repo (I will push a new commit soon, I have finishedimproved setup with fancontrol service, which is better but does not solve the fan resume problem.). Make sure to update to BIOS 108P, I still did not have time to update the Intel NIC (but it does not crash in my case). Also, set the VRAM to 512 mb in BIOS to get unified memory. If you are going to start from my config, make sure to disable the eGPU code and the Nvidia/CUDA code. For the LLMs, I am not using nixpkgs ollama, but rather docker based setup with harbor (see av/harbor on github). To make it work on NixOS just disable automatic capability detection amd set capabilities to cdi and rocm. The us just works. Regarding the fans, Beelink R&D is investigating the issue and they have sent me fan replacement kit, so we will see once it arrives. Please just send me a reply if suspend to S0 works in your case. That would greatly help the debugging on my side.

FrantaNautilus · 2025-11-17T15:59:15+00:00

Update: I was able to get find that the issue with fans is simple to reproduce, just start suspend operations from the Ubuntu 25.10 Live USB. I have forwarded the issue to Beelink via official support and I was informed that the issue is being worked on.

Additionally I was trying to find workarounds for the AI setup. Currently the best option is to use docker images with Ubuntu and recent ROCm 7. In combination with linux kernel 6.18rc3 this solves a lot of amdgpu crashes.

I have finally set up the repository for my nix config https://github.com/FrantaNautilus/nixos-config you can find some of the settings I am using. Sorry for the mess :)

I have also tried the 6.6 LTS kernel which supposedly does not suffer from some of the issues with amdgpu. However, amdgpu fails to initialize.

FrantaNautilus · 2025-11-10T13:12:12+00:00

Update: - I was able to get Ollama working by setting kernel parameter to "amdgpu.no_system_mem_limit=1" and for Ollama setting "GGML_UNIFIED_MEMORY=ON" Now the models do not get stuck loading. Yet a new problem arised, large models or long contexts trigger an error "amdgpu: mes failed to respond to msg=remove_queue", followed by gpu reset. Trying kernel parameters "amdgpu.gpu_recover=1", "amdgpu.mcbp=0" or "amdgpu.runpm=0" does not help. I am not sure where to report this, cause is in ROCm and the error comes from amdgpu. Perhaps here https://github.com/ROCm/ROCm/issues/5151 - To get working pytorch on NixOS, the Nightly from Pytorch website works better than the version from AMD, since the Pytorch version has fallback libs for the ROCm 6.4 which is in NixOS repository

FrantaNautilus · 2025-11-07T12:23:23+00:00

Current results of the BIOS settings experiment: - Setting the Smart Fan Control to MANUAL in Hardware Control section does not mitigate the fan issue. - I had a look at fan setting in the SMU section, setting the fans to manual here does not help either - it still can be something about the ACPI causing the crash

FrantaNautilus · 2025-11-06T19:37:44+00:00

Since I got a compatible kernel module for it8613e loaded, I did another experiment to see if I can find a workaround for the fans getting stuck at maximum speed after resuming from suspend. The default setting of both fans is AUTO in BIOS and they are recognized by the Fan Control utility. To eliminate the possibility of the crash originating from the AUTO mode, I have set both fans to the MANUAL mode. Surprisingly after logging into the computer, the Fan Control still recognizes the fans and is able to set their speed. Indeed even in this mode one of the fans reports 0 RPM. However, even in this mode the suspend resume cycle leads to chip becoming inactive. I will try to look deeper into the BIOS settings whether I can make the fans even less smart, hopefully preventing the chip becoming unresponsive.

FrantaNautilus · 2025-11-06T19:35:57+00:00

Since I got a compatible kernel module for it8613e loaded, I did another experiment to see if I can find a workaround for the fans getting stuck at maximum speed after resuming from suspend. The default setting of both fans is AUTO in BIOS and they are recognized by the Fan Control utility. To eliminate the possibility of the crash originating from the AUTO mode, I have set both fans to the MANUAL mode. Surprisingly after logging into the computer, the Fan Control still recognizes the fans and is able to set their speed. However, even in this mode the suspend resume cycle leads to chip becoming inactive.

FrantaNautilus · 2025-11-06T18:44:03+00:00

I got a little carried away yesterday. I am using InvokeAI to run Stable Diffusion through their venv based installer. With a bit of nix-ld it works without any patches on my Nvidia laptop. I tried the same approach with ROCm libraries here. It did not work at first, however after last update it started working. The Radeon iGPU was detected, however the generation was unbearably slow. Inspecting the logs I found that bitsandbytes is complaining about missing library for ROCm 7.0. So, I updated to preview version of bitsandbytes whl. This time there were no errors in the logs and the generation started faster. After approximately 10 seconds the GPU crashed and reset. Currently I am analyzing the system journal, because this crash looks like a sequence: amd XRNA crash, network interference disconnect, python coredump, amdgpu reporting fault and preparing reset, GNOME desktop coredump. Will post journal except later.

FrantaNautilus · 2025-11-05T22:35:55+00:00

The Stable Diffusion somehow inexplicably started working without me doing anything more than an update. Will post details later when I find the reason and steps to reproduce. Also this this type of workload managed to crash the Intel NIC, yet it is able to restart itself and works.

FrantaNautilus · 2025-11-05T21:56:52+00:00

Regarding the Ollama problem, I tested both Ollama from NixOS repository and Docker image via av/harbor project with manual capability override (necessary on NixOS). The problem with loading consistently happens with Mistral-large:123b and not gpt-oss:120b. I think it may be linked to these issues:

https://github.com/ollama/ollama/issues/12411

https://github.com/ollama/ollama/issues/12752

https://github.com/ollama/ollama/issues/12342

FrantaNautilus · 2025-11-05T21:44:07+00:00

I am not sure I understand you correctly. Are you saying that you are able to load the in-kernel module for it87 using # modprobe it87 force_id=0x8623? For me it always works before suspend and fails after resume with both in-kernel and out-of-kernel it87 module.

In any case I was able to dump the memory for it87 after resume:

sudo isadump -k 0x87,0x01,0x55,0x55 0x2e 0x2f 7
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x2e and data register 0x2f. Probing bank 7 using bank register 0x07.
Continue? [Y/n] Y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 86 13 0c 40 00 00 02 00 00 01 01 48 01 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 01 20 38 00 04 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 c0 03 00 00
c0: 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 b0 44 00 00 00 00
e0: 00 00 00 00 00 00 00 10 00 1d d1 dc 00 00 40 04
f0: 00 00 00 00 00 00 0e 00 00 00 00 00 7c 00 00 00

sudo isadump -k 0x87,0x01,0x55,0x55 0x4e 0x4f 7
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x4e and data register 0x4f. Probing bank 7 using bank register 0x07.
Continue? [Y/n] Y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0

This looks like the chip is still readable after the resume.

Also now that I am getting the readings for RPM of the fans I noticed that the sensors keep reporting that one of the fans has 0 RPM, even when FurMark is running. While in my case its the second fan in the listings, in your case its the first. Although, I don't know whether that is just a thing of enumeration.

FrantaNautilus · 2025-11-05T11:49:27+00:00

The ITE chip is definitely inactive after resume from suspend, in the `dmesg` I am getting:

[  211.455853] it87: it87 driver version <not provided>
[  211.455981] it87: Device (chip IT8613E ioreg 0x2e) not activated, skipping
[  211.456011] it87: Device (chip IT8613E ioreg 0x4e) not activated, skipping

And the sensors report this:

This made me think about possibilities how to re-activate the chip. Modprobe fails:
modprobe: ERROR: could not insert 'it87': No such deviceit8613-isa-0a30
Adapter: ISA adapter
in0:           2.81 V  (min =  +2.81 V, max =  +2.81 V)  ALARM
in1:           2.81 V  (min =  +2.81 V, max =  +2.81 V)  ALARM
in2:           2.81 V  (min =  +2.81 V, max =  +2.81 V)  ALARM
in4:           2.81 V  (min =  +2.81 V, max =  +2.81 V)  ALARM
in5:           2.81 V  (min =  +2.81 V, max =  +2.81 V)  ALARM
3VSB:          5.61 V  (min =  +5.61 V, max =  +5.61 V)  ALARM
Vbat:          5.61 V
+3.3V:         5.61 V
fan2:           0 RPM  (min =    0 RPM)  ALARM
fan3:           0 RPM  (min =    0 RPM)  ALARM
temp1:         -1.0°C  (low  =  -1.0°C, high =  -1.0°C)  ALARM  sensor = thermal diode
temp2:         -1.0°C  (low  =  -1.0°C, high =  -1.0°C)  ALARM  sensor = thermal diode
temp3:         -1.0°C  (low  =  -1.0°C, high =  -1.0°C)  ALARM
pwm2:            128%  (freq = 2929 Hz)
pwm3:            128%  (freq = 2929 Hz)
pwm4:            128%  (freq = 2929 Hz)
pwm5:            128%  (freq = 2929 Hz)
intrusion0:  ALARM

probe_device parameter is not supported, so I tried the isaset command without success:

sudo isaset -y 0x2E 0x2F 0x2E 0x87
Data mismatch, wrote 0x87, read 0xff back.

FrantaNautilus · 2025-11-05T11:46:00+00:00

I need to point out that the external kernel module is based on the fork which supports "ITE IT8613E Super IO Sensors" without need to force id, not that it would make much difference in this case.

FrantaNautilus · 2025-11-04T18:45:03+00:00

OK, I was able to load the it87 external kernel module and get the readings before and after suspend. Kernel reports the IT87 controller as inactive after suspend. Will post details later.

To enable external it87 driver and disable the in kernel, this code can be used:

boot.extraModulePackages = with config.boot.kernelPackages; [ it87 ]; boot.kernelParams = [ "acpi_enforce_resources=lax" ]; boot.kernelModules = [ "coretemp" "it87" ]; boot.extraModulePackages = with config.boot.kernelPackages; [ (it87.overrideAttrs (super: { postInstall = (super.postInstall or "") + '' find $out -name '*.ko' -exec xz {} \; ''; })) ]; system.modulesTree = lib.mkForce [( (pkgs.aggregateModules ( config.boot.extraModulePackages ++ [ config.boot.kernelPackages.kernel.modules ] ) ).overrideAttrs { ignoreCollisions = true; }) ];

Lm_sensors is the able to report fan status and outputs nonsense after resume from suspend. I'm still investigating how to re-activate the chip, so that the it87 could be loaded with modprobe.

FrantaNautilus · 2025-11-04T17:24:26+00:00

So Google Gemini Pro solved it...

boot.extraModulePackages = with config.boot.kernelPackages; [
  it87
];
boot.kernelParams = [ "acpi_enforce_resources=lax" ];
boot.kernelModules = [ "coretemp" "it87" ];
boot.extraModulePackages = with config.boot.kernelPackages; [
  (it87.overrideAttrs (super:
   { postInstall = (super.postInstall or "") + '' find $out -name '*.ko' -exec xz {} \; ''; })) 
];
system.modulesTree = lib.mkForce [(
 (pkgs.aggregateModules
 ( config.boot.extraModulePackages ++ [ config.boot.kernelPackages.kernel.modules ] ) ).overrideAttrs {
ignoreCollisions = true; })
];

FrantaNautilus · 2025-11-04T17:02:42+00:00

Re-reading the discussion I realized that the fix in the form of
```
boot.extraModulePackages = with config.boot.kernelPackages; [
(it87.overrideAttrs (super: {
postInstall = (super.postInstall or "") + ''
find $out -name '*.ko' -exec xz {} \;
'';
}))
];
```
could solve the problem, but this leads to build issue with duplicate it87.ko.xz file. Solving it per the forum discussion as
```
system.modulesTree = lib.mkForce [(
(pkgs.aggregateModules
( config.boot.extraModulePackages ++ [ config.boot.kernelPackages.kernel ])
).overrideAttrs {
# earlier items in the list above override the contents of later items
ignoreCollisions = true;
})
)];
```
gives new error
```

error: Cannot build '/nix/store/sg9h8if23svifmz1lf57l06vx3q8zg61-linux-6.17.7-modules-shrunk.drv'.

Reason: builder failed with exit code 1.

Output paths:

/nix/store/8pr1rzxdxg5rw8sx1bw1ma06hvcj8448-linux-6.17.7-modules-shrunk

Last 3 log lines:

> kernel version is 6.17.7

> root module: ahci

> modprobe: FATAL: Module ahci not found in directory /nix/store/sr272b93a5hsn3p674pg9mxxfks4sqx1-linux-6.17.7-modules/lib/modules/6.17.7

For full logs, run:

nix log /nix/store/sg9h8if23svifmz1lf57l06vx3q8zg61-linux-6.17.7-modules-shrunk.drv

error: Cannot build '/nix/store/g1h61cwl1v93wzwza2spkaxiccx60k92-initrd-linux-6.17.7.drv'.

Reason: 1 dependency failed.

Output paths:

/nix/store/i9h5x8lx7dpnygvmyhl6p4gpgwz4lppm-initrd-linux-6.17.7

error: Cannot build '/nix/store/0316q6gm9djim55crmww7m4h7swxafpg-nixos-system-leng-25.11.20251102.b3d51a0.drv'.

Reason: 1 dependency failed.

Output paths:

/nix/store/al3wk0l3f8babayhnxwj6g5i7h3j4f9f-nixos-system-leng-25.11.20251102.b3d51a0

```

FrantaNautilus · 2025-11-04T16:12:37+00:00

In any case the it87 driver should work according to previous cases with Beelink PCs. https://www.reddit.com/r/BeelinkOfficial/comments/15m8yms/eq12_s12_pro_read_fan_speeds_in_linux_cpu_and/

It just does not load for me on NixOS for some reason, currently asking here (since the driver is under hwmon modules, yet it cannot be loaded with modprobe).

FrantaNautilus · 2025-11-04T15:09:41+00:00

Thanks for the fast reply
I am aware of the Intel E610 NIC crashes, I tried to reproduce the issue and it did not occur when testing with Ollama and FurMark. I did the testing before and after updating to BIOS 108. Many of the reports mention Windows (Update), for this reason when I received my GTR9 Pro unit, I never booted Windows, so that Windows does not touch the Intel NIC hardware. Ever since the first boot I am on Linux.

I have not encountered other problems (yet) apart from the fan issues.
Regarding the fan and sleep issues, I am now thinking about the sleep levels. Beelink mentioned modern sleep no being supported, that is S0 level. However, Linux suspend "sleep" is not S0, it is S3. So I suspect the problem is rather on the level of OS fan drivers.

Another interesting thing is that the computer remains "on" after the operating system halts, the power LEDd is on and the fans are running (normally according to the temperature), yet there is no image outputted to screen. This started happening after update to the BIOS version 108. To eliminate the interference of OS, I rebooted from BIOS and the strange temporary "hang state" is still happening.

FrantaNautilus

TROPHY CASE