Asustor Flashstor Gen 2 — FS6812x/FS6806x — Debian Support and AMD XGMAC 10 GbE NICs
Asustor recently released the new model of their Flashstor series, the "Gen 2", models FS6812x (with twelve NVMe bays) and FS6806x (for the one with six NVMe bays). Despite the identical looks and similar naming to their "Gen 1", there are some quite serious improvements under the hood, with a much beefier processor and support for ECC RAM and PCIe 4.
Being a happy user of their Gen 1 model, I bought one of these to have it replace my main NAS. I am not what you'd call a "typical" user though, so I wasn't satisfied with running their default ADM software (as competent as it may be) — no, I need to have full Debian with ZFS running on this machine to take advantage of all its power. On the older model, that was as simple as booting with an attached screen (as it came with integrated graphics and a HDMI port), going into the BIOS/UEFI and selecting a different boot drive.
Not so much here:
- First of all, there is no integrated GPU, thus no way to attach a display and get into the BIOS. Fortunately, a workaround exists for that.
- Even once booted into an alternative OS, there is a major problem: none of the available kernels, from 6.1.119 (latest stable as of this time) to 6.11.5 (latest available in backports) support the integrated 10GbE NIC, known as
[1022:1458] Ethernet controller: Advanced Micro Devices, Inc. [AMD] XGMAC 10GbE Controller
inside Linux. That could really put a damper on the whole project, given the "N" in NAS stands for "Network"...
In order to solve the first issue, we can take advantage of the fact that this enclosure has plenty of M.2 slots to connect NVMe drives (at least six) and that the M.2 connector is in many ways just a small PCIe connector — thus, adapters of all shapes and sizes exist! In our case, an M.2-to-PCIe card such as this one, paired with an external power supply and a portable display.
The result is an unholy mess of cables and connectors that looks something like the image on the right... But it works!
Once able to get an image, a quick <F2>
gets us into the BIOS/UEFI, and from here under the Boot menu we can point the device to load the OS from one of the NVMe drives, an external USB or even a Floppy disk (?).
All is well and good, and I could get Debian 12 Bookworm loading just fine, but then we run into problem number 2: neither of the 10GbE ports on the machine work, despite the driver being in the kernel and technically supporting this exact model. The module is called amd-xgbe
, and we can see the card detected under both ifconfig
and ethtool
, but the link stubbornly refuses to come up:
# dmesg | grep xgbe
[ 1.080344] amd-xgbe 0000:ea:00.2: enabling device (0000 -> 0002)
[ 1.082434] xgbe_get_all_hw_features pps_out_num 2 aux_snap_num 2
[ 1.085123] amd-xgbe 0000:ea:00.2 eth0: net device enabled
[ 1.086820] amd-xgbe 0000:ea:00.3: enabling device (0000 -> 0002)
[ 1.088565] xgbe_get_all_hw_features pps_out_num 2 aux_snap_num 2
[ 1.091042] amd-xgbe 0000:ea:00.3 eth1: net device enabled
[ 1.143111] amd-xgbe 0000:ea:00.2 lan1: renamed from eth0
[ 1.228931] amd-xgbe 0000:ea:00.3 enp234s0f3: renamed from eth1
[ 33.638354] amd-xgbe 0000:ea:00.2 lan1: Link is Down
# ethtool enp228s0f2
Settings for enp228s0f2:
Supported ports: [ TP ]
Supported link modes: 1000baseT/Full
10000baseT/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseT/Full
10000baseT/Full
2500baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: on
Port: None
PHYAD: 0
Transceiver: internal
Current message level: 0x00000034 (52)
link ifdown ifup
Link detected: no
Nothing seems to bring the link up, despite trying various kernel versions, parameters and arcane incantations.
Investigation
Initial discussion around this took place within the comments section of a couple of YouTube videos reviewing the device, but eventually moved over to Reddit. Fortunately, Asustor has very helpful staff engaging with users and the community on both platforms (this sets them well ahead of many other manufacturers, it has to be said), and they pointed towards a bundle of AMD Linux Drivers that supported the NICs. After some digging on the very unhelpful and badly designed AMD website, I identified the "Ryzen Embedded V3000 Series Drivers & Support" page with the relevant downloads.
Most of the contents of that package are actually irrelevant for our use case here, since they deal with graphics support, while the "Ryzen Embedded V3C14" processor in the FS68xxx does not even have any graphics. But buried deep in the documentation, we can see references to "XGBE", and indeed the package contains kernel sources and a lot of patches for exactly amd-xgbe
.
I initially attempted to extract these patches and apply them to the kernel source from Debian, both 6.1.119 and 6.11.5. Unfortunately, despite applying cleanly and compiling without any errors, the resulting amd-xgbe
module still refused to bring the link up.
Update — 14 December 2024: I later realised that I'd made mistakes in the process of compiling and installing the modules, and this actually worked fine. More information below or you can skip directly to the instructions.
I then followed the AMD documentation to compile their custom kernel with all the custom patches; the result was a 6.6.43 kernel that installed and booted, yet it really conflicted with something in Debian in a way that rendered the machine unusable — both the USB ports as well as network was inoperable, despite the machine being alive and well and responding the ACPI events. However, booting into a minimal system with no processes running resulted in the link coming alive for the first time!
Inspired by the partial success, I then proceeded to re-compile the AMD source with the Debian configuration from their official kernels. This worked fine, and produced kernel packages that not only installed properly, but they actually booted perfectly fine and also brought up the NICs interface. Success!
# dmesg | grep xgbe
[ 1.080344] amd-xgbe 0000:ea:00.2: enabling device (0000 -> 0002)
[ 1.082434] xgbe_get_all_hw_features pps_out_num 2 aux_snap_num 2
[ 1.085123] amd-xgbe 0000:ea:00.2 eth0: net device enabled
[ 1.086820] amd-xgbe 0000:ea:00.3: enabling device (0000 -> 0002)
[ 1.088565] xgbe_get_all_hw_features pps_out_num 2 aux_snap_num 2
[ 1.091042] amd-xgbe 0000:ea:00.3 eth1: net device enabled
[ 1.143111] amd-xgbe 0000:ea:00.2 lan1: renamed from eth0
[ 1.228931] amd-xgbe 0000:ea:00.3 enp234s0f3: renamed from eth1
[ 103.917320] amd-xgbe 0000:ea:00.2 lan1: Link is Up - 10Gbps/Full - flow control off
[ 107.638354] amd-xgbe 0000:ea:00.2 lan1: Link is Down
[ 113.805272] amd-xgbe 0000:ea:00.2 lan1: Link is Up - 10Gbps/Full - flow control off
If you want to read more about this very process and perhaps compile your own custom kernel, you can read all about it — but it is not necessary for getting the NIC to function! Read on for the much easier version.
After getting the link up, I spent some time trying to determine what the difference between the working/non-working kernels was. As the default settings provided no clues in the logs at all, I anded up on this very useful thread from the "netdev" Linux Kernel mailing list, where I found out about the amd_xgbe.dyndbg=+p
parameter which can be added to the kernel boot command line in order to write a wealth of additional debug information to the logs. In Debian, this can be done by editing /etc/grub/default
to have GRUB_CMDLINE_LINUX_DEFAULT="amd_xgbe.dyndbg=+p"
, then re-running update-grub
and rebooting.
Having this line present allowed me to compare the working and non-working module versions, and it turned out that the problem was related to the Auto-Negotiation (AN) part of the link establishment.
Here are the logs when the NIC is working and the link comes up:
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.6.43 root=LABEL=root ro amd_xgbe.dyndbg=+p
[ 0.011980] Kernel command line: BOOT_IMAGE=/vmlinuz-6.6.43 root=LABEL=root ro amd_xgbe.dyndbg=+p
[ 1.065344] amd-xgbe 0000:ea:00.2: enabling device (0000 -> 0002)
(...)
[ 95.264660] amd-xgbe 0000:ea:00.2 lan1: receiver reset complete
[ 95.264666] amd-xgbe 0000:ea:00.2 lan1: RX_VALID or LF_SIGDET is unset, issue rrc
[ 95.264889] amd-xgbe 0000:ea:00.2 lan1: Mailbox CMD 5 , SUBCMD 0
[ 95.266911] amd-xgbe 0000:ea:00.2 lan1: receiver reset complete
[ 95.266914] amd-xgbe 0000:ea:00.2 lan1: 10GbE KR mode set
[ 95.287639] amd-xgbe 0000:ea:00.2 lan1: Mailbox CMD 1 , SUBCMD 2
[ 95.289868] amd-xgbe 0000:ea:00.2 lan1: 1GbE SGMII mode set
[ 95.289871] amd-xgbe 0000:ea:00.2 lan1: phy_start_aneg pdata->an_mode:4 phydev_mode:2
[ 95.290146] amd-xgbe 0000:ea:00.2 lan1: AN PHY configuration
[ 95.290295] amd-xgbe 0000:ea:00.2 lan1: CL73 AN disabled
[ 95.290306] amd-xgbe 0000:ea:00.2 lan1: CL37 AN disabled
[ 100.397195] amd-xgbe 0000:ea:00.2 lan1: Ext PHY changed interface mode to 2 so AN is needed
[ 100.397205] amd-xgbe 0000:ea:00.2 lan1: phy_start_aneg pdata->an_mode:4 phydev_mode:2
[ 100.397210] amd-xgbe 0000:ea:00.2 lan1: phy_start_aneg not called
[ 100.397213] amd-xgbe 0000:ea:00.2 lan1: AN PHY configuration
[ 100.397488] amd-xgbe 0000:ea:00.2 lan1: Mailbox CMD 4 , SUBCMD 1
[ 100.400641] amd-xgbe 0000:ea:00.2 lan1: Enabling RX adaptation
[ 100.608644] amd-xgbe 0000:ea:00.2 lan1: Block_lock done
[ 100.608652] amd-xgbe 0000:ea:00.2 lan1: 10GbE KR mode set
[ 100.608662] amd-xgbe 0000:ea:00.2 lan1: CL73 AN disabled
[ 100.608675] amd-xgbe 0000:ea:00.2 lan1: CL37 AN disabled
[ 101.421212] amd-xgbe 0000:ea:00.2 lan1: Link is Up - 10Gbps/Full - flow control off
... And here are the same logs on another kernel, which is not able to bring the link up:
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.11.5+bpo-amd64 root=LABEL=root ro amd_xgbe.dyndbg=+p
[ 0.013568] Kernel command line: BOOT_IMAGE=/vmlinuz-6.11.5+bpo-amd64 root=LABEL=root ro amd_xgbe.dyndbg=+p
[ 1.366709] amd-xgbe 0000:ea:00.2: enabling device (0000 -> 0002)
[ 1.370462] amd-xgbe 0000:ea:00.2 eth0: net device enabled
[ 1.372397] amd-xgbe 0000:ea:00.3: enabling device (0000 -> 0002)
[ 1.378409] amd-xgbe 0000:ea:00.3 eth1: net device enabled
[ 1.387833] amd-xgbe 0000:ea:00.3 enp234s0f3: renamed from eth1
[ 1.392496] amd-xgbe 0000:ea:00.2 lan1: renamed from eth0
[ 77.759096] amd-xgbe 0000:ea:00.2 lan1: phy powered off
[ 77.759110] amd-xgbe 0000:ea:00.2 lan1: CL73 AN disabled
[ 77.759121] amd-xgbe 0000:ea:00.2 lan1: CL37 AN disabled
[ 77.761498] amd-xgbe 0000:ea:00.2 lan1: starting PHY
[ 77.761503] amd-xgbe 0000:ea:00.2 lan1: starting I2C
[ 77.763316] amd-xgbe 0000:ea:00.2 lan1: 10GbE KR mode set
[ 77.792683] amd-xgbe 0000:ea:00.2 lan1: 10GbE KR mode set
[ 77.792702] amd-xgbe 0000:ea:00.2 lan1: CL73 AN initialized
[ 77.793034] amd-xgbe 0000:ea:00.2 lan1: AN PHY configuration
[ 77.793045] amd-xgbe 0000:ea:00.2 lan1: CL73 AN disabled
[ 77.793055] amd-xgbe 0000:ea:00.2 lan1: CL37 AN disabled
[ 77.793069] amd-xgbe 0000:ea:00.2 lan1: CL73 AN initialized
[ 77.793077] amd-xgbe 0000:ea:00.2 lan1: CL73 AN enabled/restarted
[ 78.353106] amd-xgbe 0000:ea:00.2 lan1: CL73 AN Incompatible-Link
[ 78.353116] amd-xgbe 0000:ea:00.2 lan1: CL73 AN result: No-Link
[ 78.353121] amd-xgbe 0000:ea:00.2 lan1: CL73 AN Ready
[ 82.897238] amd-xgbe 0000:ea:00.2 lan1: AN link timeout
[ 82.897538] amd-xgbe 0000:ea:00.2 lan1: AN PHY configuration
[ 82.897554] amd-xgbe 0000:ea:00.2 lan1: CL73 AN disabled
[ 82.897567] amd-xgbe 0000:ea:00.2 lan1: CL37 AN disabled
[ 82.897584] amd-xgbe 0000:ea:00.2 lan1: CL73 AN initialized
[ 82.897596] amd-xgbe 0000:ea:00.2 lan1: CL73 AN enabled/restarted
[ 83.457620] amd-xgbe 0000:ea:00.2 lan1: CL73 AN Incompatible-Link
[ 83.457629] amd-xgbe 0000:ea:00.2 lan1: CL73 AN result: No-Link
[ 83.457635] amd-xgbe 0000:ea:00.2 lan1: CL73 AN Ready
[ 88.017180] amd-xgbe 0000:ea:00.2 lan1: AN link timeout
(... repeats ad nauseam ...)
We can observe the CL73 AN Incompatible-Link
/ CL73 AN result: No-Link
timing out and repeating continuously (AN here referring to "Auto-Negotiation"), with no resolution. A similar thing happened on the working sample, but there eventually another part of the code takes over with Enabling RX adaptation
, etc. and the link comes up — although it does take its sweet time, as we can see from the timestamps on the left, almost two minutes for the link to become properly active, with a few false starts as well. It could be that other fixes are still necessary to optimise the process.
What prompted a head-scratching moment here though was the fact that I distinctly recalled seeing some references to very similar-sounding patches in the AMD Linux Driver package. So back I went, and lo-and-behold, there they were:
0004-amd-xgbe-add-support-for-rx-adaptation.patch
0013-amd-xgbe-Start-AN-with-KR-training-auto-start.patch
0014-amd-xgbe-AN-force-modeset-to-10GKR-for-resetting-HW.patch
There may as well be other patches that helped with the problem as well, but these were particularly obvious. So, I went and gave the "compile just the module with patches" idea another try, this time carefully following the compilation and especially installation process step-by-step. And d'oh! it turned out I'd installed them wrong before, and after rebooting I was still loading the broken module instead of the shiny, new, patched one. Lack of sleep probably is to blame, what can I say...
But, the great news was that the properly patches modules actually worked just fine, in both the 6.1.119 (stable) Debian kernel as well as the 6.11.5 (backports) one! Which meant no more full recompilation was necessary, and we could even use DKMS to streamline the installation under future kernel updates (although this still needs to be tested to make sure the new driver is loaded instead of one that comes with the kernel).
I'll provide below the patched module source for kernel 6.1.x which should work just fine for current stable versions of Debian, as well as instructions on how to make your own which can be extended to any future version as well.
Warning: While less complex than full kernel compilation and replacement, messing with the default kernel modules can render your device inoperable and failing to come online. Only proceed if you know what you're doing and are willing to debug and fix problems as they appear. I will not be responsible for any harm coming to your device, bricking it or loss of data!
Debian Support for AMD XGMAC 10GbE NICs — HOWTO
- Boot into you Debian installation on the Flashstor
- Install build tools and the kernel headers for the running version:
- for stable:
$ sudo apt install build-essential linux-headers-amd64
- for latest kernel in backports as of the date of publication:
$ sudo apt install build-essential linux-headers-6.11.5+bpo-amd64
- This will also install a number of additional packages including
gcc
,libraries
, etc. Accept them all.
- for stable:
- Download and copy the patched module source:
$ cd $ wget https://mihnea.net/amd-xgbe-asustor-0.6.1.tar.bz2 $ tar xvf amd-xgbe-asustor-0.6.1.tar.bz2
- Compile the module:
$ cd amd-xgbe-asustor-0.6.1 $ make
- Install the module:
$ sudo make install
- DKMS (optional):
- This is optional, but very useful to have in place so that the module will be recompiled automatically whenever new versions of the kernel are installed as part of OS updates
$ sudo apt install dkms $ sudo make dkms
- Update initramfs for the current running kernel:
$ sudo update-initramfs -u -k `uname -r`
- Reboot
- Note: Make sure to allow some time for the link to come up, this driver can be slow to "connect" (sometimes over two minutes). But after that, you should see it going fine. Also, remember that the NIC needs to have an IP address assigned (either statically or via DHCP) in order to come up, otherwise it will not activate.
If you later want to remove the patched module, you can run $ sudo make dkms_clean
to delete it from DKMS, then re-install the distribution kernel image to overwrite the modules under /lib/modules/<kernel-version>
:
$ sudo apt install --reinstall linux-image-6.1.0-28-amd64
Of course, all of the specific numbers listed here will change as new kernel versions are released by the Debian team, but the instructions should work just the same as long as the module version is applicable to the kernel version (i.e. don't try to compile a module meant for 6.11.x on a 6.1.x kernel).
Testing and Validation
- Check the logs:
# dmesg | grep xgbe [ 1.080344] amd-xgbe 0000:ea:00.2: enabling device (0000 -> 0002) [ 1.082434] xgbe_get_all_hw_features pps_out_num 2 aux_snap_num 2 [ 1.085123] amd-xgbe 0000:ea:00.2 eth0: net device enabled [ 1.086820] amd-xgbe 0000:ea:00.3: enabling device (0000 -> 0002) [ 1.088565] xgbe_get_all_hw_features pps_out_num 2 aux_snap_num 2 [ 1.091042] amd-xgbe 0000:ea:00.3 eth1: net device enabled [ 1.143111] amd-xgbe 0000:ea:00.2 lan1: renamed from eth0 [ 1.228931] amd-xgbe 0000:ea:00.3 enp234s0f3: renamed from eth1 [ 103.917320] amd-xgbe 0000:ea:00.2 lan1: Link is Up - 10Gbps/Full - flow control off [ 107.638354] amd-xgbe 0000:ea:00.2 lan1: Link is Down [ 113.805272] amd-xgbe 0000:ea:00.2 lan1: Link is Up - 10Gbps/Full - flow control off
- This is from a FS6812X with two 10GbE ports; on the FS6806X which has only one port, you'll see some errors related to the MAC address, ignore them as they only pertain to the "disabled" NIC that is still present on the board
- You should see the "Link is Up" message here; note that it took about 100 seconds to come up on this boot, not sure why that was the case, most times it's quick though
- If you don't see the "Link is Up" message, make sure that the
dhclient
(DHCP request) process has started on that interface, or give it a static IP address manually; the link will not be shown as "up" otherwise! - Note that the NIC port link/activity LEDs will not light up even when it's working, so do not rely on those for indication that you have a link! Look at your switch instead
- Confirm network link speed:
# ethtool enpXXX (whatever name it chose on your machine; you can make this human-readable by editing the files under /etc/system/network)
- Check for:
Speed: 10000Mb/s
andDuplex: Full
in the output - If these show up as
Unknown!
instead, something went wrong; try un-plugging and re-plugging the Ethernet cable, giving it a few minutes, power cycling, etc. — sometimes it takes some convincing
- Test performance:
- I was able to achieve a sustained rate around 9.85 Gbps with a couple of different hosts on my network (using MTU 9000 or "jumbo frames"); YMMV of course, depending on your own conditions and equipment
(remote) $ iperf3 -c 10.0.0.2 --bidir -t60 $ iperf3 -s ---------------------------------------------------------- Server listening on 5201 (test #4) ----------------------------------------------------------- Accepted connection from , port 35264 [ 5] local 10.0.0.2 port 5201 connected to 10.0.0.1 port 35268 [ 8] local 10.0.0.2 port 5201 connected to 10.0.0.1 port 35280 [ ID][Role] Interval Transfer Bitrate Retr Cwnd [ 5][RX-S] 0.00-1.00 sec 1.14 GBytes 9.83 Gbits/sec [ 8][TX-S] 0.00-1.00 sec 1.15 GBytes 9.89 Gbits/sec 0 2.01 MBytes [ 5][RX-S] 1.00-2.00 sec 1.15 GBytes 9.84 Gbits/sec (...) [ 8][TX-S] 58.00-59.00 sec 1.15 GBytes 9.86 Gbits/sec 0 1.66 MBytes [ 5][RX-S] 59.00-60.00 sec 1.15 GBytes 9.84 Gbits/sec [ 8][TX-S] 59.00-60.00 sec 1.15 GBytes 9.88 Gbits/sec 0 1.78 MBytes [ 5][RX-S] 60.00-60.00 sec 2.19 MBytes 9.81 Gbits/sec [ 8][TX-S] 60.00-60.00 sec 2.50 MBytes 11.3 Gbits/sec 0 1.78 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID][Role] Interval Transfer Bitrate Retr [ 5][RX-S] 0.00-60.00 sec 68.7 GBytes 9.83 Gbits/sec receiver [ 8][TX-S] 0.00-60.00 sec 68.9 GBytes 9.86 Gbits/sec 2132 sender -----------------------------------------------------------
I have tested these steps on my own devices and confirm that they are valid and working as of December 2024; of course, things can change without notice and some of the packages linked here may stop working. Ideally, the various patches AMD applies to the kernel will be merged upstream and Debian will package those new kernels, so this whole process can be avoided.
If you encounter errors or problems following these instructions, please add a comment below and I'll do my best to answer and update the text if needed, but please understand that I can't promise anything, as I have no control over the Asustor devices or the AMD driver packages.
The above instructions are meant to be easy to follow and include an already patched amd-xgbe
kernel module. But if you'd rather create that from scratch, or potentially update it in the future with different kernel versions and AMD Linux Driver packages, you can find the kernel module patching details below.
Debian Support for AMD XGMAC 10GbE NICs — Kernel Module Patching — HOWTO
I. Preparations
- Download the AMD Drivers (you'll need to use a full browser, as they very unhelpfully block
wget
/curl
and force you to actually browse there):- I got: https://drivers.amd.com/drivers/embedded/amd_ubuntu-22.04.2_kernel_6.1.49_v2023_30_3241_ga_public_v3k.tar.bz2 by going to "Previous Drivers" on the AMD website, because this is the latest package supporting the current stable Debian 12 kernels in the 6.1.x series
- For better compatibility with the latest Debian backports kernels in the 6.11.x series, you can use:
https://drivers.amd.com/drivers/embedded/AMD_Ubuntu-24.04_Kernel_6.6.43_2024_30_GA_15.tar.bz2
- Copy the AMD package to the Flashstor — easiest is to
scp
it from your local machine - Boot into Debian on the Flashstor
II. On the Flashstor NAS
- Install kernel headers and source for the running version:
- For stable:
$ sudo apt install build-essential linux-headers-amd64 linux-source-6.1
- For the latest version in backports as of publication time:
$ sudo apt install build-essential linux-headers-6.11.5+bpo-amd64 linux-source-6.11
- This will also install a number of additional packages including
gcc
, libraries, etc. Accept them all.
- For stable:
- Unpack the linux source in
/usr/src
:$ cd /usr/src $ mkdir amd-xgbe-patched $ chown <your-user> amd-xgbe-patched $ tar xvf /usr/src/linux-source-*.tar.xz
- Unpack the AMD driver package and extract just the relevant patches:
$ tar xvf <path>amd_ubuntu-22.04.2_kernel_6.1.49_v2023_30_3241_ga_public_v3k.tar.bz2 $ grep -l "amd/xgbe" AMD_Ubuntu-22.04.2_Kernel_6.1.49_v2023_30_3241_GA/patches/kernel/*
- This should find 19 patch files for our module in the 22.04 package, names and paths will of course vary depending on the AMD package being used
- If compiling against the backports kernel, make sure to download a more recent AMD driver package, the latest one works fine at the moment despite being made for 6.6.43: AMD_Ubuntu-24.04_Kernel_6.6.43_2024_30_GA_15
- Apply the patches:
$ cd linux-source-6.1 $ for i in `grep -l "amd/xgbe" ../AMD_Ubuntu-22.04.2_Kernel_6.1.49_v2023_30_3241_GA/patches/kernel/*`; do patch -p1 < $i; done
- There will be some "Reversed (or previously applied) patch detected!" notices, in all of those cases just take the default action of *not* applying it again (press Enter)
- Prepare the kernel:
- Note that we'll do the minimum necessary to be able to compile our module, without going through the full process
$ cp /usr/src/linux-headers-`uname -r`/Module.symvers . $ cp /usr/src/linux-config-6.1/config.amd64_none_amd64.xz . $ unxz config.amd64_none_amd64.xz $ mv config.amd64_none_amd64 .config $ make oldconfig <press Enter on all questions> $ make prepare $ make modules_prepare
- Re-compile the module
$ make -C /lib/modules/`uname -r`/build M=$(pwd)/drivers/net/ethernet/amd/xgbe modules
- Install the new module, overwriting the existing one:
- IMPORTANT: Overwriting is necessary, otherwise the old module may take precedence; we need to ensure it's completely gone
$ sudo cp drivers/net/ethernet/amd/xgbe/amd-xgbe.ko /lib/modules/`uname -r`/kernel/drivers/net/ethernet/amd/xgbe/amd-xgbe.ko $ sudo depmod -a
- Update
initramfs
for the running kernel:$ sudo update-initramfs -u -k `uname -r`
- Reboot
TrueNAS
Update — 15 December 2024: I was able to also get TrueNAS SCALE (version ElectricEel-24.10.0.2) to boot up with networking on the Flashstor, using a similarly patched kernel module. Obviously, this is an experimental setup only, with no support from the TrueNAS developers and team, but if you want to read more head over to the detailed instructions page.
Next Steps
At this point, there are still a number of missing items that prevent the support from being 100% good, but with this major milestone the Flashstor Gen 2 FS6812x/FS6806x models become usable under a variety of alternative operating systems. Here are the remaining issues:
- The NIC link and activity LEDs do not light up at all, even when the connection is active and working just fine. This makes testing and debugging harder, but is a minor issue at present.
- The two fans of the device cannot be controlled from Debian, which leads to pretty high temperatures when under heavy load (such as the kernel compilation above). This was also a problem with the previous Gen 1 hardware, but it was solved by the
asustor_it87
patched driver which supports various Asustor products. Unfortunately, switching to the AMD platform has rendered that driver inoperable. - The front LEDs are not controllable either, one is constantly blinking and the others in various states of on and off. This was also something that the
asustor_it87
driver fixed, but it may be achievable again by investigating the various GPIO outputs.
Comments