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:
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?
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.
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ā¦
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.
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.
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
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
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
