RPi + Allo USBridge Sig | Ethernet driver ax88179_178a fails

[dsnyder0pc]

ADMIN EDIT

Workaround for 32-bit kernel users:

wget https://dietpi.com/downloads/misc/ax88179_178a.ko_new2 -O /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
depmod 5.4.51-v7+
modprobe ax88179_178a

---

Creating a bug report/issue

Required Information

• DietPi version | v6.31.2
• Distro version | buster
• Kernel version | Linux usbridge 4.19.97-v7+ DietPi-Software | Node-RED: Run under nodered? #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
• SBC model | RPi CM 3+ (armv7l)
• Power supply used | Allo Shanti
• SDcard used | SanDisk ultra

Additional Information (if applicable)

• Hardware is the Allo USBridge + RPi Compute Module 3+
• Was the software title installed freshly or updated/migrated? apt update; apt upgrade; reboot
• Can this issue be replicated on a fresh installation of DietPi? Yes

Steps to reproduce

1. ... Flash the microSD card with the latest DietPi (timestamp: Jun 14 05:02)
2. ... Attempt to boot.

Expected behaviour

• ... NIC should be recognized

Actual behaviour

• ... Observe that the internal NIC is not recognized (no LAN access)

Extra details

• ... I've been able to workaround this problem by connecting a USB NIC and downgrading the kernel to build 1.20200212-1
• ... Please restore /sys/module/ax88179_178a and /lib/modules/*/kernel/drivers/net/usb/ax88179_178a.ko to future releases

[Joulinar]

Hi,

Many thanks for your message. Just as information, DietPi is not and will not create any kernel version. The kernel is provided by the underlying Debian base image, always.

[dsnyder0pc]

@Joulinar - Looks like I'm going to have to find an O/S other than DietPi for audio use going forward. The kernel choices have been a disaster for this use case. I understand that you don't create the kernels, but the ones you've been choosing to include in DietPi releases have made DietPi nearly unusual for audio applications. This is so disappointing since DietPi was otherwise excellent. for this purpose. Cheers.

[Joulinar]

Still a misunderstanding. DietPi is not choosing for a kernel. It's provided by the Debian Base image. Depending on the SBC used, DietPi is using different Debian images like Armbian or Meveric. In case of Raspberry Pi, the kernel is provided by Raspberry OS. The version of the kernel is not influenced by DietPi.

[MichaIng]

ax88179_178a is regular part of the RPi kernel, is it really missing in your case?

We install a special version that is provided by Allo, contains some ARM enhancements and makes their USBridge Signature running better, coincidence? It is pulled from here: http://3.230.113.73:9011/Allocom/USBridgeSig/

When you upgrade the kernel to lastet version:

1. It contains the driver itself, although it seems to not support the Allo USBridge Sig that fine, which is why Allo provides the special build.
2. /etc/kernel/postinst.d/dietpi-USBridgeSig pulls their driver automatically on kernel package installs/upgrades. If this somehow fails, you should see related output during APT install. Please try to upgrade the kernel packages and watch out for the driver download/install. Here you see what the script is doing+output: https://github.com/MichaIng/DietPi/blob/master/PREP_SYSTEM_FOR_DIETPI.sh#L1627-L1639

It worked fine in my case btw:

-rw-r--r-- 1 root root 42K Jul 14 11:27 /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko

[comassky]

I also have this issue with Allo UsbBridge & latest DietPi OS (6.32).

First boot UsbBridge have lan connection, upgrade with 5.4 kernel, and no networks at the reboot.

[MichaIng]

Can you please as well check if the file exists and if the module version matches loaded kernel:

ls -al /lib/modules/*/kernel/drivers/net/usb/ax88179_178a.ko
uname -a
dpkg -l raspberrypi-kernel

[comassky]

@MichaIng

First boot 👍

During upgrade :

Reboot after update :

[MichaIng]

Okay so the modules have been installed successfully. The dietpi-config error means that ip a doesn't show any ethN interface, right?
Has the module been loaded?

lsmod | grep ax88179_178a

Or can it be loaded?

modprobe ax88179_178a

[comassky]

Yes ip a only show localhost loopback

lsmod | grep ax88179_178a

Return nothing (empty)

modprobe ax88179_178a

Return "ERROR : could not insert 'ax88179_178a' : Exec format error"

Try to use : insmod ax88179_178a.ko, return "ERROR Could not insert module ax88179_178a.ko : Invalid module format"

The Allo module is no longer compatible with the 5.4 kernel ?

[MichaIng]

Hmm, the only explanation is that the module from Allo is broken. Generally Linux 5.4 is not an issue, they build it for (nearly) all versions, even the ones not packaged for RPi repo: http://3.230.113.73:9011/Allocom/USBridgeSig/
I'll forward it. Until then, revert to default package module:

wget https://dietpi.com/downloads/misc/ax88179_178a.ko -O /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
depmod 5.4.51-v7+
modprobe ax88179_178a

Reported to Allo: allocom/USBridgeSig#1

[comassky]

Oh no :(

There is an sound quality impact ?

[MichaIng]

I'm afraid yes, but I don't know the details. Here are the driver sources, you could try to build it yourself, raspberrypi-kernel-headers and build-essentials required, probably more: https://github.com/allocom/USBridgeSig/tree/master/ethernet
Here is some discussion around it: raspberrypi/linux#2942
Sad that the manufacturer (ASIX) did not send this driver to be included into Linux upstream from where all would benefit.

---

Worst case is that you need to downgrade the kernel + bootloader + firmware, I guess: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/?C=M;O=D
But probably I find time tomorrow to try compiling the driver, lets see.

[Joulinar]

@MichaIng
Just for my understanding. This is specific for these Allo devices?

[MichaIng]

It's when you use this: https://allo.com/sparky/usbridge-signature-pcb.html
It has ASIX ax88179 GBit Ethernet, but the Linux upstream driver for it seems to work not good on ARMs, according to Allo leading to audio distortion in that combination and lower transfer rates as well. ASIX provided a new ARM-optimised driver to them which they provide via their servers. We install their driver on RPi automatically via /etc/kernel/postinst.d/dietpi-USBridgeSig. I remember one case where they uploaded the new driver a little late, so the script failed to download it and the default one stays in place instead. But a broken driver is of course a problem, especially since there might be other ASIX ax88179 USB Ethernet users without the Allo PCB.

[Joulinar]

Thx for explanation @MichaIng

[MichaIng]

Running into this error when trying to compile the module: https://askubuntu.com/questions/1215551/ubuntu-server-19-10-ax88179-driver-problem
This looks like the reason: https://patchwork.kernel.org/patch/10578933/
Driver needs to be updated it seems, however probably its possible to ignore this warning or not treat as error.

[comassky]

So the next step is that Allo ask to ASIX to upgrade the module to be compatible with the current 5.4 kernel ?

[MichaIng]

So the next step is that Allo ask to ASIX to upgrade the module to be compatible with the current 5.4 kernel ?

Yes indeed that should be done.

I'm not sure how Allo manages to build the module with this error. I just commented this deprecated (now removed) option definitions, like it was done here: acooks/tn40xx-driver#9 (comment)
The new ones seem to take procedure anyway, if I understand the patch comment correctly, so defining the old one has no effect. I tried replacing the old [gs]et_settings with [gs]et_link_ksettings but that leads to some "incompatible pointer type" error.

Please try this:

wget https://dietpi.com/downloads/misc/ax88179_178a.ko_new -O /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
depmod 5.4.51-v7+
modprobe ax88179_178a

[comassky]

So the next step is that Allo ask to ASIX to upgrade the module to be compatible with the current 5.4 kernel ?

Yes indeed that should be done.

I'm not sure how Allo manages to build the module with this error. I just commented this deprecated (now removed) option definitions, like it was done here: acooks/tn40xx-driver#9 (comment)
The new ones seem to take procedure anyway, if I understand the patch comment correctly, so defining the old one has no effect. I tried replacing the old [gs]et_settings with [gs]et_link_ksettings but that leads to some "incompatible pointer type" error.

Please try this:

wget https://dietpi.com/downloads/misc/ax88179_178a.ko_new -O /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
depmod 5.4.51-v7+
modprobe ax88179_178a

curl https://dietpi.com/downloads/misc/ax88179_178a.ko_new => 403 ;)

[MichaIng]

Whoopsie, just fixed permissions 😄.

[dsnyder0pc]

I just tested with the October 22nd DietPi_RPi-ARMv7-Buster_AlloGUI.img image, which is still v6.32.2, IIRC. The Allo USBridge Signature booted with no networking (missing a working ax88179_178a). I transferred the microSD card to another RPi and applied the workaround:

#!/bin/bash
curl -LO https://dietpi.com/downloads/misc/ax88179_178a.ko_new2
cp ax88179_178a.ko_new2 /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
depmod 5.4.51-v7+
modprobe ax88179_178a

After that, I was able to use dietpi-update to upgrade to DietPi v6.33.3, reboot, and still have networking. Here's the version of the driver in 5.4.72-v7+ (after the update):

# ls -l ax88179_178a.ko
-rw-r--r-- 1 root root 29544 Oct 22 15:25 ax88179_178a.ko
# md5sum ax88179_178a.ko
4d605f9759a8cb9af0eb8c8945c368fd  ax88179_178a.ko

So, Allo USBridge Signature owners are still in for a bumpy ride with the October 22nd image, but if the image after this one includes this new driver, they should be good to go. Thanks again, @MichaIng and @allocom for working on this. If they have another Raspberry Pi and a USB microSD card reader, they can use these commands to "patch" the October 22nd image so that it boots with networking:

ALLO_MICROSD=/dev/sdb  # use lsblk or dmesg to find the correct device for your card reader
curl -LO https://dietpi.com/downloads/images/DietPi_RPi-ARMv7-Buster_AlloGUI.7z
7z x DietPi_RPi-ARMv7-Buster_AlloGUI.7z
wipefs -a "${ALLO_MICROSD}"
dd if=DietPi_RPi-ARMv7-Buster_AlloGUI.img  of="${ALLO_MICROSD}" bs=4M conv=fsync
mount "${ALLO_MICROSD}2" /mnt
curl -L https://dietpi.com/downloads/misc/ax88179_178a.ko_new2 -o /mnt/lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
sync
umount /mnt

[dsnyder0pc]

BTW, while testing the above "patch" process, I observed a few 404 errors in the output. @allocom , this may be worth looking into:

FWIW, it looks like fall-back to the default driver actually worked, but fixing these 404's should be easy and is probably the right thing to do.

Here's a recording of the complete first-boot and dietpi-update process for the October 22nd image with my "patch" from above: https://youtu.be/rIt3jVPn6RM

[dsnyder0pc]

Not related to this issue, but I should add that the October 22nd kernel (5.4.72-v7+) is unusable for audio. When playing out to a USB DAC (what the USBridge Signature was made for), there's a constant stream of pops and ticks. :-\

Trying this workaround to roll back to the previous kernel (5.4.51-v7+):

curl -LO https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20200902-1_armhf.deb
curl -LO https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-bootloader_1.20200902-1_armhf.deb
curl -LO https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/libraspberrypi0_1.20200902-1_armhf.deb
curl -LO https://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/libraspberrypi-bin_1.20200902-1_armhf.deb
dpkg -i *1.20200902-1*.deb
apt-mark hold $(dpkg -l | awk '/1.20200902-1/ {print $2}')

This seems to have resolved the pops and ticks for now. @allocom - please let me know if you have experienced the same thing in your testing of the 5.4.72-v7+ kernel on the USBridge Signature.

[dsnyder0pc]

I've tossed these kernel downgrade steps into a script to make it a bit easier:

curl -L ws-e.com/to-5451.sh | bash

[MichaIng]

Thanks for the hint, yes totally makes sense to add the fixed driver to our Allo GUI image! EDIT: Done

The issue with 5.4.72 is that there is no build available yet: http://3.230.113.73:9011/Allocom/USBridgeSig/
@allocom would you mind to trigger one as 5.4.72 has been officially released by RPi Foundation? 🙂 And would be great if the stable builds could be done for ARMv8 as well, as only the stable 5.4.51-v7+ has been build, no 5.4.51-v8+.

Possible 404 errors during kernel update are btw expected, note the "No matching stable driver found, trying to...".
We try to pull the updated ASIX driver for 5.4.X-v7+ and 5.4.X-v8+ for stable kernel build first, if that fails (404) or the module layout does not match, we try to pull it for master kernel build and if that fails the default RPi kernel driver stays in place, which is sadly unusable with audio output as you recognised.
@dsnyder0pc
Do you have an idea how we can make it clearer that the one or the other 404 is expected here? 🤔
I don't want to hide the HTTP response completely to not mute errors that really need to be fixed and we tried to keep the explanations short to not spam the console more that it already does, especially since it is only relevant for USBridge Sig users.

A pain that ASIX did not manage until now to push the updated driver to mainstream Linux. RPi Foundation refused to accept the new drivers when done coming from upstream 😞.

---

@dsnyder0pc
Just to assure, http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/rpi-usbs-5.4.51-v7+/ax88179_178a.ko works fine for your as well, right?

[dsnyder0pc]

@MichaIng - Yes. http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/rpi-usbs-5.4.51-v7+/ax88179_178a.ko works fine for me. I've verified that it's the same as what I'm currently running:

root@usbridge:~# curl -LO http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/rpi-usbs-5.4.51-v7+/ax88179_178a.ko
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 42895  100 42895    0     0  73324      0 --:--:-- --:--:-- --:--:-- 73450
root@usbridge:~# cksum ax88179_178a.ko /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko
1297844159 42895 ax88179_178a.ko
1297844159 42895 /lib/modules/5.4.51-v7+/kernel/drivers/net/usb/ax88179_178a.ko

I think the "No matching driver found. Cleaning up and aborting…" bit was the most concerning. I did notice that it was part of an "[INFO]" message, so, I didn't think I should take it too seriously. I guess if I was checking for a number of resources that may or may not exist, I'd probably just do a series of HEAD requests and say something like:

[INFO] Checking for updated Allo networking driver…[OK]

or

[INFO] Checking for updated Allo networking driver…[No Found]

Of course, if there's an error actually pulling down the driver, you should report that (eg., no space or whatever). But, probably no need to report the HTTP status code from the HEAD request.

For example:

curl -sL --head http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/rpi-usbs-5.4.51-v7+/ax88179_178a.ko | awk '/^HTTP/ {print substr($0, 14, 80)}'
OK

curl -sL --head http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/rpi-usbs-5.4.51-v7+/random_file_not_there | awk '/^HTTP/ {print substr($0, 14, 80)}'
Not Found

[MichaIng]

Many thanks for your suggestion. That would match a bid the way we perform downloads within dietpi-software currently, first with basically a HEAD request (wget --spider), then in case of success, do the actual download. But actually I wanted to skip the first test and directly perform the download, as in case of failure it produces the same error messages that can be parsed/printed. So actually a separate first test is an overhead that can take a few seconds on some internet connections (satellite, mobile, such).

But indeed here we expect at least one 404 for at least one of the two kernels (v7+ and v8+). An alternative to the separate HEAD request is to redirect error outputs into a variable first, and only if it's present + no 404, print it to console, if it's 404, print the smoother "No matching stable branch driver found, trying master branch driver..." actually is enough.
In case of failing master branch driver download, it however makes sense to print the error since this should not happen. It only affects users that actually use the driver of course, so most likely only USBridge Sig users, but it breaks their audio as you verified. I'm thinking about a way to reliably detect if it's actually in use/loaded, but that is actually hard since after a kernel upgrade, modprobe/modinfo do not work anymore as on RPi the old /lib/modules/* directory is removed directly 🤔.

[dsnyder0pc]

Well, the USBridge Signature is a Raspberry Pi Compute Module 3+

- Device model : RPi CM 3+ (armv7l)

Probably only a small percentage of non-industrial end users are running DietPi on CM 3+ boards, so perhaps you could only go to this trouble if you detect that you're installing on a CM 3+. :)

[MichaIng]

Good point, theoretically it could be completely skipped on non-CM3 🤔.

[theskystalker]

Hi, same issue on my Raspberry Pi 2 Model B V1.1

first setup of DietPi hangs in endless loop, trying to get Kernel-Module from this strange Server http://3.230.113.73:9011/Allocom/USBr.....

Raspi OS works like a charm without this stuff, but i want to use DietPi because of the other nice features

is there a option in the dietpi.txt to skip this step?

below is the console output of my 3rd try to finish setup :/

BR
Stefan

Removing 'diversion of /boot/overlays/uart2.dtbo to /usr/share/rpikernelhack/overlays/uart2.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/uart3.dtbo to /usr/share/rpikernelhack/overlays/uart3.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/uart4.dtbo to /usr/share/rpikernelhack/overlays/uart4.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/uart5.dtbo to /usr/share/rpikernelhack/overlays/uart5.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/udrc.dtbo to /usr/share/rpikernelhack/overlays/udrc.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/upstream-pi4.dtbo to /usr/share/rpikernelhack/overlays/upstream-pi4.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/upstream.dtbo to /usr/share/rpikernelhack/overlays/upstream.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/vc4-fkms-v3d.dtbo to /usr/share/rpikernelhack/overlays/vc4-fkms-v3d.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/vc4-kms-kippah-7inch.dtbo to /usr/share/rpikernelhack/overlays/vc4-kms-kippah-7inch.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/vc4-kms-v3d-pi4.dtbo to /usr/share/rpikernelhack/overlays/vc4-kms-v3d-pi4.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/vc4-kms-v3d.dtbo to /usr/share/rpikernelhack/overlays/vc4-kms-v3d.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/vga666.dtbo to /usr/share/rpikernelhack/overlays/vga666.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/w1-gpio-pullup.dtbo to /usr/share/rpikernelhack/overlays/w1-gpio-pullup.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/w1-gpio.dtbo to /usr/share/rpikernelhack/overlays/w1-gpio.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/w5500.dtbo to /usr/share/rpikernelhack/overlays/w5500.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/wittypi.dtbo to /usr/share/rpikernelhack/overlays/wittypi.dtbo by rpikernelhack'
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.4.72+ /boot/kernel.img
run-parts: executing /etc/kernel/postinst.d/dietpi-USBridgeSig 5.4.72+ /boot/kernel.img
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.4.72-v7+ /boot/kernel7.img
run-parts: executing /etc/kernel/postinst.d/dietpi-USBridgeSig 5.4.72-v7+ /boot/kernel7.img
/etc/kernel/postinst.d/dietpi-USBridgeSig:
[ INFO ] Updating asix ax88179 driver for kernel 5.4.72-v7+, as provided by allo.com:
[ INFO ] - https://github.com/allocom/USBridgeSig/tree/master/ethernet
[ INFO ] Downloading driver...
--2020-11-16 17:17:34--  http://3.230.113.73:9011/Allocom/USBridgeSig/rpi-usbs-5.4.72-v7+/ax88179_178a.ko
Connecting to 3.230.113.73:9011... failed: Connection timed out.
Retrying.

--2020-11-16 17:19:47--  (try: 2)  http://3.230.113.73:9011/Allocom/USBridgeSig/rpi-usbs-5.4.72-v7+/ax88179_178a.ko
Connecting to 3.230.113.73:9011...

[Joulinar]

@theskystalker
your issue is different than the original one. Looks like a temp issue at Allo side. At least for me the download is working fine right now. Just checked it on my Windows box.

[theskystalker]

@Joulinar you were right.
I can download the file from my web server.
Looks like my IP is blocked by this server. :(

[Joulinar]

Hmm probably your ISP is blocking it? 🤔

[theskystalker]

Looks like only the Webserver on this machine blocks my IP. There is also running an FTP Server and from there I got an answer. 🤷‍♂️

Maybe it would be an good idea to load the source from Github an compile it on the pi, because loading "Stuff" from unknown sources is not best practice,

at least comparing the hash would be fine, but there is nothing provided on github

[Joulinar]

This is the Allo web server. But maybe there is something else in between blocking HTTP traffic?

[MichaIng]

Connecting to 3.230.113.73:9011... failed: Connection timed out.
Retrying.

--2020-11-16 17:19:47-- (try: 2)...

Strange that curl is retrying, as actually by default it should give up on a failure. Ah when updating from v6.32 to v6.33 then it is still the old script that used wget which does 20 retries by default. So that is solved already.

Okay, let's make this a minimal noise implementation:

• USBRidge Sig is RPi CM3+, so let's only apply the module upgrade for this single device. I was thinking that a better driver for this ASIX Ethernet chip is generally good, but finally it creates more issues/worries when the download fails compared to the near-to-zero change that someone attaches the same external Ethernet device onto another RPi model (which does still work, only breaks USB audio), especially as all but CMs have onboard Ethernet and CM1 is incompatible due to ARMv6 kernel.
• The pre-flashed DietPi image is using the ARMv7 kernel, switching to ARMv8 is possible but not reasonable without flashing the ARMv8 image. So no need to attempt downloading for both kernel versions, but only the one that is used. Furthermore Allo did not build the ARMv8 module for the last few versions anymore, and we don't have an Allo GUI ARMv8 image either, so we'll revert to only upgrade for ARMv7 for now.
• I'll adjust the messages to make it clear that a failing download can be ignored when not using the Allo USBridge Sig and otherwise that the script should be retried later: /etc/kernel/postinst.d/dietpi-USBridgeSig

@theskystalker
In your case: rm /etc/kernel/postinst.d/dietpi-USBridgeSig
You don't need it 😉.

[theskystalker]

Nice, and thanks for the Tip, will try it tomorrow 👍

Ah when updating from v6.32 to v6.33 then it is still the old script that used wget which does 20 retries by default.

Oh, ok that's 40 minutes 😁 , nearly endless loop 😆

[MichaIng]

Another reason why migrating all downloads to curl is a good idea, aside of the fact that it inits faster (relevant for small downloads and HEAD requests).

Reopened to not forget about this.

[MichaIng]

Will now only be applied on CM 3+ now and only for v7+ kernel: d8ace2f

A build for the latest stable kernel is btw available now: http://3.230.113.73:9011/Allocom/USBridgeSig/stable_rel/
@dsnyder0pc so you could update your kernel now.