In order to utilize GTR Pro full potential for AI applications, I’m required to install Ubuntu 24.04 along with AMD ROCm (which is not supported on windows 11). After installing Ubuntu, I noticed a recurring problem with the built in ethernet adapters. Whenever the computer encounters load on the GPU, the ethernet card would crash and the only way to get it to work again is to unplug my machine from power. It seems that other users of GTR Pro are also experiencing this issue: https://community.intel.com/t5/Ethernet-Products/Intel-Ethernet-Controller-E610-Firmware-Recovery-Mode-Under-Load/td-p/1719424 Linux Kernel is 24.04c oem as required by ROCm Things I’ve tried: Installing the ubuntu LAN driver version 6.0.6 provided in the beelink driver package - fails under ubuntu 24.04 Installing the latest LAN driver from Intel website - The ethernet card still crashes Installing an older version (6.1.4) - The ethernet card still crashes. Please advise as this makes the machine unusable as a server under Linux. It happens on gaming distributions such as Bazzite, as well.

I am on manjaro linux, and it seems like you can just use the intel default package for nvm updates for the 610 NIC ( https://www.intel.com/content/www/us/en/download/845408/non-volatile-memory-nvm-update-package-for-intel-ethernet-e610-series-linux.html ) to flash it to 1.30. Just make sure you can see the nic with lspci before you start (if not, coldstart).

f70w I attempted the above, no luck unfortunately. Beelink is working on a solution

Sorry for the trouble. Currently, the Lan issue of the GTR9 395 persists, and its root cause lies in the Ethernet driver. As of now, there is no new driver available to resolve the problem of the Intel E610. The current workarounds are as follows: Perform a physical power-off and re-plug the power cable. We suggest you to to use a Wi-Fi connection instead. A complete resolution to this issue will only be possible once a new driver is released

Beelink CS-George I was just about to place an order for this device… after reading these posts and the implicated lack of urgency in your response (not even and indicated time-line) to this major issue. I’ll hold off and quite likely look at the Framework product.

Oh, and the fact that your driver web page is inaccessible…

Welly Hi there, it is accessible, here is the link https://dr.bee-link.cn/?dir=uploads%2FGTR%2FGTR9-395

Welly Sorry for the inconvenience. We already urge Intel to develop a good driver. We will update it once it is released.

Beelink CS-George I will keep an eye out for this news.

Thanks for the update but what’s the confidence level that the new driver will resolve this issue? Are you able to reproduce it? What is the root cause? Could you share more details? Thank you very much.

LEPT Thank you for your understanding and patience. decryp7 Thank you for your response. The issue stems from missing drivers, which have caused the Ethernet functionality to become inoperable. New drivers are currently under development.

GTR 9 Pro Ethernet Malfunction under load

jotapesse

tbocek

But I’m not running out-of-tree modules (https://github.com/intel/ethernet-linux-ixgbe). @ivangotoy reports that also with the out-of-tree module, it does not run.

That’s likely the issue - as there isn’t yet a proper match with the NVR Firmware 1.30 and the Intel-maintained ixgbe-6.2.5 driver. And I’m guessing that both @ivangotoy and @gtaranti didn’t made sure the Intel-maintained ixgbe-6.2.5 driver is actively in use instead of the stock in-kernel ixgbe driver. Please make good note of the Steps 2 and 3 on Craig Wilson’s bloq post:

Step 2 — Confirm which module is loaded

(…)

Step 3 — Addressing issues
In my case, the kernel’s stock module reported only version: 6.14.0-1012-oem and failed to display the NVM version (0.00 0×0). After compiling and installing the official Intel driver release (ixgbe-6.2.5), the interface correctly reported both the updated driver and the actual firmware version.

If Secure Boot is enabled, the new module must be signed with a Machine Owner Key (MOK) before it can be loaded at boot. Otherwise, the kernel will silently reject it.

gtaranti

jotapesse
Image description
You’re not correct.
It’s still happening with all updated. BIOS, LAN firmware, LAN drivers

ivangotoy

jotapesse
The out of tree kernel module was used in my previous example and is crashing.
Now I use the kernel supplied module (which is also crashing but at least no need to deal with pure out-of-tree Intel incompetence)

sudo ethtool -i eth1
driver: ixgbe
version: 6.17.1-2-cachyos
firmware-version: 1.30 0×8000e899 1.3863.0
expansion-rom-version:
bus-info: 0000:c5:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

Kinda sick of being a free QA of a product I actually f-ing paid for, if this s hit is not resolved in 2 weeks time I’m just returning it and life will be 100 times better. 😣

DesruX

gtaranti I have also performed the NIC firmware update to 1.3 and updated BIOS to 1.08 - I still have crashes. Seems system not stable under load - disabling NICs in windows helps but there are still issues with stability.
Also I cannot get the system to sleep - need to do shutdown every time.
There are two fans in the system, but I can only get RPM on one of them - might be unrelated.

kx

I could reproduce the problem with ixgbe driver provided by the recent Fedora 43 kernel and also dkms version compiled from https://github.com/intel/ethernet-linux-ixgbe/releases/tag/v6.2.5

sudo ethtool -i enp196s0f1np1
driver: ixgbe
version: 6.2.5
firmware-version: 1.30 0x8000e899 1.3863.0
expansion-rom-version:
bus-info: 0000:c4:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

I have also tried on ArchLinux, the same issue.

jotapesse

@tbocek @gtaranti @kx Ok, my bad then. I stand corrected! Sorry! Perhaps that blog post should be updated to make it clear as it gave me the worng impression. Still waiting on my GTR 9 Pro to arrive to test it myself… I really hope a solution for it comes along fast! 🙏

jotapesse

Perhaps that blog post should be updated to make it clear as it gave me the worng impression.

Yep, now updated with much more details and clear issues distinction. 🙏

tis

Agree. I solved the list of crashes my box performed, but I am still running tests and not having LAN attached yet. If this keeps being unstable I will need to return as well.
A professional use is not possible in this manner.

jotapesse

@tbocek @gtaranti @kx @ivangotoy On Linux, what process do you guys use to replicate the issue of the NICs to enter a non-recoverable lock state and for how long do you run it to trigger that issue? Furmark?

ivangotoy

jotapesse
Try to stress the gpu with some 3d… - play a 3d game or open a website with many animations - just stress the 3d component of the gpu a bit and see how it goes. Once I managed to crash nics by opening too many animated gifs on discord ☺ pathetic

tbocek

jotapesse I was using llama.cpp and was testing models. After a couple of prompts, I ran into the NIC issue.

jotapesse

Ok, I’m on Linux only and wanted to use Linux native apps. I recently received my GTR 9 Pro and I have set it on Performance 140W mode and used Furmark 2 and pushed the GPU 100% up to 85ºC temperature for several minutes while taxing a 1GBps internet connection on the NIC and couldn’t replicate it. I had updated the Intel NVR firmware to latest version 1.30 but kept the Linux kernel default/stock ixgbe driver module (kernel 6.17.0). That’s why asked what was the process and for how long it must be run to trigger it. I don’t seem to be able to replicate it here.

ivangotoy

jotapesse
I didn’t realize you needed more details.
It’s CachyOS linux running kde/plasma with Wayland, running standard cachyos kernel (non lts)
A very quick demo how things go from hero to 0 in less than 2 minutes:

jotapesse

ivangotoy Thanks! Ok, you are using a game with Doom Runner launcher for Doom based games. I guess that if you try to use the Furmark 2 benchmark and push the GPU 100% for several minutes you should be able to trigger it and get the same results right? Could please try it and let us know?

jotapesse

tbocek Thanks! Could you please also try to use the Furmark 2 benchmark and push the GPU 100% for several minutes and confirm if you are able to trigger it and get the same results? Let us know please.

ivangotoy

jotapesse
Cannot trigger this by running furmark with many different options, unigine superposition also does not trigger it on my end but at least gzdoom with vulkan renderer + special doom2 mods works like a charm 🤣

decryp7

jotapesse

I don’t quite understand what you are trying to do. I already pointed out it is not reproducible using furmark and also share my scenario with ollama which you can use to reproduce it. 😄

ivangotoy

ivangotoy
p.s. when changing game renderer from vulkan to “opengl es” game is playable without triggering nic fw crash for 5 min. as a test

jotapesse

decryp7 I’m trying to understand everything, establish an easy Linux common reproducible process for all and understand in what conditions the issues can be triggered or not. Different people reported different experiences. Not everyone uses LLMs as you have. Specifically regarding Furmark 2 I’m trying to establish if it doesn’t trigger it for everyone or just for me or the case you reported and why - because it clearly stresses the GPU 100% - so it’s odd to not trigger it. Or maybe it can trigger it on certain conditions (what and why?).

Reported triggers:

LLM: Open WebUI Chat (gpt-oss:20b);
LLM: llama.cpp (several models);
3D Game: Doom Runner (gzdoom/doom2.wad - Vulkan);
WebApp: Opening many animated GIFs on Discord;

jotapesse

decryp7 Hi! I really can’t reproduce this on Linux. I tested it on LM Studio 0.3.28 with openai/gpt-oss-120B (vulkan) on NixOS Linux (kernel 6.17.1) with multiple chat messages with Reasoning Effort: High. No issues at all. All good!

decryp7

Hi All,
Can you try to enable ECO mode in Bios and try again?
Thank you very much.

tbocek

I’m just wondering if Beelink is looking into this issue. Any information is appreciated about the progress. I read somewhere that Beelink needs to wait for new firmware from Intel. So, are you still waiting? Did Intel acknowledge the bug, can you push Intel to deliver faster?

decryp7

tbocek

Hi,

Can you try to enable Eco mode and try to reproduce the phenomenon again? It looks like after I enabled Eco mode, the problem disappears. It can be a workaround at least until the driver is released.

« Previous Page Next Page »