Realtek rlt8153 USB Ethernet adapter not working after upgrade

After installing the august 2021 update last week on my Vero 4k, the USB 3.0 Gigabit Ethernet interface is not working any more. It has a RTL8153 chipset:

osmc@osmc:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 001 Device 002: ID 2017:1688
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The system loaded the cdc_ether module for the device. After blacklisting that module the r8152 module was loaded. Unfortunately dmesg shows the version of this card is unkown:

osmc@osmc:~$ dmesg | grep r8152
[    7.076543] usbcore: registered new interface driver r8152
[    7.414735] r8152 1-2:1.0 (unnamed net_device) (uninitialized): Unknown version 0x6010
[    7.414744] r8152 1-2:1.0 (unnamed net_device) (uninitialized): Unknown Device

I tried compiling the kernel module provided by Realtek (downloaded from here: https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-usb-3-0-software), but got two errors compiling.

gcc: error: unrecognized command line option '-mgeneral-regs-only'
gcc: error: unrecognized command line option '-mcmodel=large'

It seems (so web searching tells me) to be related to arm64 specific switches not supported on the installed gcc. The command gcc --version --verbose lists the following line Target: arm-linux-gnueabihf. That seems odd to me.
I installed the build-essential package to install all the needed build tools.

Was someone able to compile kernel modules, or perhaps this r8152 kernel module after the august update?

Best regards,
Floris Jan

I can’t say why the driver is failing to recognise your device, but if you want to build a kernel driver natively on the Vero4k (or Pi 4, for that matter), you’ll need to do it inside the 64-bit toolchain (package: aarch64-toolchain-osmc). This is because the V4K and Pi4 are both multi-architecture devices, having a 64-bit kernel and 32-bit userspace.

To use the toolchain, you need to bind mount relevant directories to the toolchain, which will be installed to /opt/osmc-tc/aarch64-toolchain-osmc. To enter the toolchain run sudo chroot /opt/osmc-tc/aarch64-toolchain-osmc. If you need to download/install anything into the toolchain, remember to update (the toolchain’s) /etc/resolv.conf.

Just a FYI. The r8152 driver is “in tree”, so is part of the official kernel code-base.

The Vero4k kernel (v4.9.113) is on driver version 1.08.9. The RPi kernel (v5.10.32) is now up to version 1.12.11. So it could be that the driver version is simply too old for the hardware.

Yes, I think you are right about that. The version seems to be supported in 1.12.11.

Thanks for the explanation about the toolchain, the compiler works. The latest driver from Realtek (2.15.0) does not compile for the Vero 4k kernel version (something about 2.5G en 5G not being supported).
Then I tried to compile the in-tree driver (1.12.11) but got (a lot) errors as well. As I just downloaded the relevant files from the kernel source and tried to compile them seperately, this probably was to be expected. :wink:

So I’ll just have to wait for the kernel to get more recent in the Vero 4k for this interface to be supported, I guess. Maybe I’ll look into it more, but 100mbit is usually enough, I think I can wait…

What’s wrong with using the Veros built in WiFi? It’s faster than 100M and works on 2.4 and 5Ghz.

Isn’t this an ethernet adapter, not wifi? Even so is it going to be faster than Vero 4k’s ethernet?

Yes. This is an ethernet adapter, no WiFi. I prefer wired connections. The USB GE adapter is quicker than Vero 4k’s 100Mbit ethernet port. I think i got 250mbps or something, enough for all bandwith intensive blurays.

Since you say it previously worked with kernel v3.14, I can only assume you hit some kind of regression.

I checked the link to the Realtek drivers but they wanted my e-mail address to d/l the code – and that wasn’t going to happen. However, I did find a random github source for the driver at GitHub - wget/realtek-r8152-linux: A kernel module for Realtek RTL8152/RTL8153 Based USB Ethernet Adapters - Meant to be used in distributions only - For upstream bugs, please report them to your distribution maintainer or to Realtek. that does compile.

root@osmc-4k:/home/osmc/realtek-r8152-linux# modinfo r8152.ko
filename:       /home/osmc/realtek-r8152-linux/r8152.ko
version:        v2.15.0 (2021/04/15)
license:        GPL
description:    Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
author:         Realtek nic sw <nic_swsd@realtek.com>
srcversion:     23FFB571BE579EABEDA73C5
alias:          usb:v2BAFp0012d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v2BAFp0012d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v2BAFp0012d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v13B1p0041d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v13B1p0041d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v13B1p0041d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v0955p09FFd*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v0955p09FFd*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v0955p09FFd*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v2357p0601d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v2357p0601d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v2357p0601d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFpA387d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFpA387d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFpA387d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFpA359d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFpA359d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFpA359d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp8153d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp8153d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp8153d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp721Ed*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp721Ed*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp721Ed*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp7214d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp7214d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp7214d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp720Cd*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp720Cd*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp720Cd*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp720Bd*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp720Bd*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp720Bd*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp720Ad*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp720Ad*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp720Ad*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp7205d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp7205d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp7205d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp3098d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp3098d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp3098d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp3082d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp3082d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp3082d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp3069d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp3069d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp3069d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp3062d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp3062d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp3062d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp3057d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp3057d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp3057d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp3054d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp3054d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp3054d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp3052d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp3052d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp3052d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v17EFp304Fd*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v17EFp304Fd*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v17EFp304Fd*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v04E8pA101d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v04E8pA101d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v04E8pA101d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v045Ep07C6d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v045Ep07C6d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v045Ep07C6d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v045Ep07ABd*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v045Ep07ABd*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v045Ep07ABd*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v0BDAp8156d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v0BDAp8156d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v0BDAp8156d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v0BDAp8155d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v0BDAp8155d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v0BDAp8155d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v0BDAp8153d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v0BDAp8153d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v0BDAp8153d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v0BDAp8152d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v0BDAp8152d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v0BDAp8152d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v0BDAp8053d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v0BDAp8053d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v0BDAp8053d*dc*dsc*dp*icFFisc*ip*in*
alias:          usb:v0BDAp8050d*dc*dsc*dp*ic02isc0Dip00in*
alias:          usb:v0BDAp8050d*dc*dsc*dp*ic02isc06ip00in*
alias:          usb:v0BDAp8050d*dc*dsc*dp*icFFisc*ip*in*
depends:        
vermagic:       4.9.113-45-osmc SMP preempt mod_unload modversions aarch64

modinfo for that on 3.14 doesn’t list a version but it’s clearly been backported.

I no longer have a 3.14 device as a reference but the r8152 driver has been in the kernel since v3.10 for USB 2.0 / 100 Mbps and since v3.14 has supported 1 Gbps. As such, there should have been no need for any backporting.

https://cateee.net/lkddb/web-lkddb/USB_RTL8152.html

Edit. Just checked in /boot and the 3.14 config definition is still there. Yay!

osmc@osmc-4k:/boot$ grep 8152 config-3.14.29-160-osmc 
CONFIG_USB_RTL8152=m

So should be there as a module.

I also found that repository, but was a bit anxious to try ‘a random GitHub repository’ :wink:

Maybe I’ll give it a go after reviewing the code.

1 Like

Can you downgrade to the older version and run lsmod on both devices?
This should let us see if something is missing and I can get it included promptly for you

Sam

FWIW, here is 3.14 with a 8152 device plugged in:

osmc@vero4k:/lib/modules/3.14.29/kernel/drivers/net/usb$ sudo modinfo r8152.ko
filename:       /lib/modules/3.14.29/kernel/drivers/net/usb/r8152.ko
license:        GPL
description:    Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
author:         Realtek linux nic maintainers <nic_swsd@realtek.com>
alias:          usb:v04E8pA101d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8153d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v0BDAp8152d*dc*dsc*dp*ic*isc*ip*in*
depends:
intree:         Y
vermagic:       3.14.29 SMP mod_unload aarch64
osmc@vero4k:/lib/modules/3.14.29/kernel/drivers/net/usb$ lsmod
Module                  Size  Used by
cdc_ether               5066  0
bnep                   12492  2
hci_uart               25989  1
ipt_MASQUERADE          2224  1
bridge                118162  0
stp                     1856  1 bridge
llc                     4341  2 stp,bridge
btsdio                  3618  0
bluetooth             286328  22 bnep,btsdio,hci_uart
6lowpan_iphc            6159  1 bluetooth
iptable_nat             3340  1
nf_conntrack_ipv4       9173  1
nf_defrag_ipv4          1609  1 nf_conntrack_ipv4
nf_nat_ipv4             4545  1 iptable_nat
nf_nat                 15099  3 ipt_MASQUERADE,nf_nat_ipv4,iptable_nat
nf_conntrack           63916  5 ipt_MASQUERADE,nf_nat,nf_nat_ipv4,iptable_nat,nf_conntrack_ipv4
iptable_filter          1686  0
dhd                   790896  0
cfg80211              406609  1 dhd
snd_usb_audio         130089  0
snd_hwdep               8245  1 snd_usb_audio
snd_usbmidi_lib        23316  1 snd_usb_audio
snd_rawmidi            23333  1 snd_usbmidi_lib
dwc_otg               260876  0
snd_seq_device          6421  1 snd_rawmidi
ir_lirc_codec           5052  3
lirc_dev                9136  1 ir_lirc_codec
wifi_dummy               886  0
mali                  227975  5
meson_ir                4333  0
rc_core                26059  4 lirc_dev,meson_ir,ir_lirc_codec
amlvideodri            12770  0
videobuf_res            5722  1 amlvideodri
videobuf_core          18318  2 amlvideodri,videobuf_res
videodev              162267  1 amlvideodri
media                  24739  1 videodev

No version number but it was from the kernel source code.

Edit. I just noticed that you only loaded cdc_ether, and not r8152, so perhaps @fjgalesloot was also loading cdc_ether in 3.14.

I found a useful article here that might help. Although it talks about loading two modules (cdc_ether and r8152) together, it explains how an alias can be created so that one is favoured over the other.

Looking at my 4.9 device, module aliases for cdc_ether and r8152 appear to be identical for 0bda:8153. Perhaps it chooses them in character order:

osmc@osmc-4k:/lib/modules/4.9.113-45-osmc$ grep 8153 !$
grep 8153 modules.alias
alias usb:v0BDAp8153d*dc*dsc*dp*ic02isc06ip00in* r8152
alias usb:v0BDAp8153d*dc*dsc*dp*icFFisc*ip*in* r8152
alias usb:v0BDAp8153d*dc*dsc*dp*ic02isc06ip00in* cdc_ether

cdc_ether seems to not be as performant if I recall, and we had some posts about this.

But lsmod shows that cdc_ether is not being used on @grahamh’s device.

I’ll check CONFIG_ now between 3.14 and 4.9.

Okay, in 4.9 we have both:

+CONFIG_USB_RTL8152=m
+CONFIG_USB_NET_CDCETHER=m

For r8152/3

3.14 is at:

commit 10c3271712f58215f4d336a1e30aa25be09cd5d1
Author: hayeswang <hayeswang@realtek.com>
Date:   Tue Mar 4 20:47:48 2014 +0800

    r8152: disable the ECM mode
    
    There are known issues for switching the drivers between ECM mode and
    vendor mode. The interrup transfer may become abnormal. The hardware
    may have the opportunity to die if you change the configuration without
    unloading the current driver first, because all the control transfers
    of the current driver would fail after the command of switching the
    configuration.
    
    Although to use the ecm driver and vendor driver independently is fine,
    it may have problems to change the driver from one to the other by
    switching the configuration. Additionally, now the vendor mode driver
    is more powerful than the ECM driver. Thus, disable the ECM mode driver,
    and let r8152 to set the configuration to vendor mode and reset the
    device automatically.
    
    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

And 4.9 is at:

commit 14a61b6f2d3fbf941128fab5d6e20519d8e5309e
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Feb 25 19:12:10 2018 -0800

    r8152: fix tx packets accounting
    
    [ Upstream commit 4c27bf3c5b7434ccb9ab962301da661c26b467a4 ]
    
    r8152 driver handles TSO packets (limited to ~16KB) quite well,
    but pretends each TSO logical packet is a single packet on the wire.
    
    There is also some error since headers are accounted once, but
    error rate is small enough that we do not care.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

So 3.14 doesn’t have anything special backported and 4.9 is more recent.

I think we need to see lsmod and dmesg output on 3.14 vs 4.9 from @fjgalesloot to gain a further understanding as to what the issue is

Sam

My understanding has always been that cdc_ether is not being used by any other module – and can therefore be unloaded.

Thinking about it afterwards, it might also be something in a udev rule. :frowning: