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

decryp7

Missing drivers? I thought that you have provided them in https://dr.bee-link.cn/?dir=uploads%2FGTR%2FGTR9-395
Is there any estimated release date?

Rogi

Hi,
My new Bee-link GTR9 Pro crashes too frequently.

I will request refund unless I will be provided with help to address the issue.

There is solution described in following post: https://community.intel.com/t5/Ethernet-Products/E610-XT2-BSOD-NIC-hang-firmware-vs-driver-mismatch/m-p/1718766

I need same downloads provided by Bee-Link:

From CraigOZ post above:

**I worked with Bee-Link and got a firmware update tot he NIC to 1.3. the BSOD have now stopped the and system is stable. 
I did write     up the process here in case anyone needs it later. 

These were the fixes:

System BIOS: v1.08 (Firmware supplied by Bee-Link Support)
NIC Firmware: Intel E610 NVM 1.30 (Supplied by Bee-Link Support, appears the same as Intel version)
Driver Pack: Intel Ethernet 30.4 (Intel and Bee-Link supplied drivers both worked)**

So, Bee-Link, please provide downloads mentioned above.

**System BIOS: v1.08 (Firmware supplied by Bee-Link Support)
NIC Firmware: Intel E610 NVM 1.30 (Supplied by Bee-Link Support, appears the same as Intel version)**

Thanks!

jotapesse

Hi, you should be able to find them here: https://dr.bee-link.cn/?dir=uploads%2FGTR%2FGTR9-395%2F

BIOS 1.08: https://dr.bee-link.cn/?dir=uploads%2FGTR%2FGTR9-395%2FBIOS
(Windows) Intel LAN Driver: https://dr.bee-link.cn/uploads/GTR/GTR9-395/Driver/GTR9-Drivers.zip (2.8GB Full Drivers package).
(Linux) Intel LAN Driver 6.2.5: https://github.com/intel/ethernet-linux-ixgbe
Intel NVM 1.30 Update Package for Intel® Ethernet E610 Series: https://www.intel.com/content/www/us/en/download/845347/non-volatile-memory-nvm-update-package-for-intel-ethernet-e610-series.html?wapkw=610%20nic (should be the same as the one provided by Beelink)

tbocek

From my side, I am running BIOS 1.08 (Version: GTRP108, Release Date: 09/16/2025), NVM 1.30. Both upgraded via EFI. I still see network issues with the ethernet card that suddenly disappears. It comes back after poweroff. Wifi is also unstable, need to reconnect manually with Arch, kernel 6.16.8.

DrDre

@Rogi @tbocek yeah, the upgrades don’t help with the issue.

jotapesse

For reference the amazing work from Craig Wilson: bloq post. The issue should be resolved with:

Did you guys also checked the Intel LAN NIC Driver 6.2.5 (for Linux)?

tbocek

jotapesse Yes, it still happens:

sudo dmidecode | grep -A 5 ‘BIOS Inform’
BIOS Information
Vendor: American Megatrends International, LLC.
Version: GTRP108
Release Date: 09/16/2025
Address: 0xF0000
Runtime Size: 64 kB

sudo ethtool -i enp196s0f1
driver: ixgbe
version: 6.16.8-arch3-1
firmware-version: 1.30 0×8000e899 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

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.

jk1

Maybe that solves the problem in Linux. In Windows it does not – at least it didn’t work for me.

gtaranti

In my Linux machine I have installed the latest 1.08 BIOS Update, the latest Intel NIC Firmware update (1.30) and the latest Intel NIC Drivers (6.2.5).

I can confirm that the problem continue to exist.
I’m having a terminal watching dmesg messages and for over half an hour was downloading a new model with LM Studio with the ethernet w/o any problems. On the middle of browsing the web, I saw these messages in dmesg window:

[58193.926885] ixgbe 0000:c4:00.0: Adapter removed [58193.965136] ixgbe 0000:c4:00.0: Firmware recovery mode detected. Limiting functionality. Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.

Ofcourse ethernet is down and both send/receive lights are on. -> bricked.

I’m seriously considering sending it back to Beelink…
If there is no resolution in this SERIOUS problem…
We’are loosing many hours trying to troubleshoot a brand new (and expensive) machine!!

ivangotoy

CachyOS linux
kernel 6.12.49-3-cachyos-lts
Latest NIC firmware 1.30
uefi/bios 1.08
Out of tree linux driver from intel 6.2.5 available here https://github.com/intel/ethernet-linux-ixgbe

Boots fine, the second I run a graphically intensive app like a 3d game - NICs miserably die.!

ETA of solution?

Image description

chilango

ivangotoy

Hi there, are you sure, it is the same problem? Im running on the most recent CachyOS version as well, and also experience freezes from this bug:
https://gitlab.freedesktop.org/drm/amd/-/issues/4483
However, not saying the NIC issue is solved, but it seems to have 2 issues at the moment.

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.

kx

Hi everyone,

I’d like to report that I’m experiencing the same two issues others have mentioned:

amdgpu flip_done timed out / commit wait errors

The Ethernet port vanishes under load (or intermittently), even though all firmware/BIOS updates have been applied

Details about my setup:

NIC firmware: 1.30

BIOS: 1.08

OS: Fedora 43

Kernel: 6.17.0-63.fc43.x86_64

Here are some of the recurring log entries I see in dmesg:

amdgpu 0000:c4:00.0: [drm] *ERROR* [CRTC:86:crtc-0] flip_done timed out amdgpu 0000:c4:00.0: [drm] *ERROR* flip_done timed out amdgpu 0000:c4:00.0: [drm] *ERROR* [CRTC:86:crtc-0] commit wait timed out amdgpu 0000:c4:00.0: [drm] *ERROR* flip_done timed out amdgpu 0000:c4:00.0: [drm] *ERROR* [PLANE:83:plane-7] commit wait timed out

The flip_done timed out issue can occur under very different circumstances (sometimes while idle, sometimes under heavy load).

It happens across different desktop environments (so it doesn’t seem to be tied to GNOME/KDE/etc.).

The Ethernet disappearing issue still happens despite the firmware and BIOS updates, and usually requires a full power cycle to recover.

Running the following command helps to recover the GPU without rebooting or losing the current session:

sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover

jotapesse

I’d like to report that I’m experiencing the same two issues others have mentioned:
amdgpu flip_done timed out / commit wait errors

Here are some of the recurring log entries I see in dmesg:

amdgpu 0000:c4:00.0: [drm] ERROR [CRTC:86:crtc-0] flip_done timed out
amdgpu 0000:c4:00.0: [drm] ERROR flip_done timed out
amdgpu 0000:c4:00.0: [drm] ERROR [CRTC:86:crtc-0] commit wait timed out
amdgpu 0000:c4:00.0: [drm] ERROR flip_done timed out
amdgpu 0000:c4:00.0: [drm] ERROR [PLANE:83:plane-7] commit wait timed out

The flip_done timed out issue can occur under very different circumstances (sometimes while idle, sometimes under heavy load). It happens across different desktop environments (so it doesn’t seem to be tied to GNOME/KDE/etc.).

Running the following command helps to recover the GPU without rebooting or losing the current session:
sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover

kx Hi! I’m also on Linux and l also get those occasional system freezes, even on idle for long, apparently related to the amdgpu kernel module driver pageflip handling. I have opened a dedicated topic for that discussion here.

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.

« Previous Page Next Page »