Package Details: r8152-dkms 2.15.20210629-1

Git Clone URL: (read-only, click to copy)
Package Base: r8152-dkms
Description: A kernel module for Realtek RTL8152/RTL8153/RTL8154/RTL8156 Based USB Ethernet Adapters
Upstream URL:
Licenses: GPL
Conflicts: r8152
Submitter: crocowhile
Maintainer: wget (hcartiaux)
Last Packager: hcartiaux
Votes: 9
Popularity: 0.88
First Submitted: 2016-09-17 11:34
Last Updated: 2021-06-29 14:56

Latest Comments

1 2 3 Next › Last »

johntdavis commented on 2021-03-02 18:42

Hello, Thanks for making this available. I'm testing it on Manjaro now, with the help of someone who actually knows how to compile new modules into the kernel. I realize y'all can't support Manjaro installs. I'm posting more to see if anyone has noticed the same behavior.

I and another user have run into an issue. With an adapter using the 8156 chipset attached to a Raspberry Pi running Manjaro ARM via the first USB 3.0 port, the Pi can no longer boot from an SSD attached to the second USB 3.0 port. No drive activity at all.

The current solution is to plug the SSD drive into the USB 2.0 port. It works fine, but it's slower.

There's a better than even chance the Pi 4b's USB 3 bus just can't deal with more than one high performance device. The hardware predates USB booting on the Pi being a thing, for example, and a lot of people ran into issues with the USB 3 bus having enough power to boot the machine when that was first announced.

I'm not sure where I should be looking for error logs. My dmesg record did not include info going back far enough. Any suggestions for troubleshooting would be welcome.


ptb commented on 2020-11-21 13:35

Shouldn't line 28 -e "s/@PKGVER@/${_pkgbase}/g" \ be -e "s/@PKGVER@/${pkgver}/g" \ ?

lawa42 commented on 2020-06-17 07:25

Solves the problem thanks

wget commented on 2020-06-16 10:24

Thanks a lot mic_e for your patch. PR merged and package updated :)

mic_e commented on 2020-06-12 00:06

Seems to be broken. With kernel 5.7.2-arch1-1 and r8152-dkms 2.13-1

I get the error message "couldn't register device" with the following traceback:

There's no upstream update, and upstream says that it works up to Linux 5.6 only :(

I'll see if there's an easy patch... I wish they'd just upstream this driver, but looking at the source code it's unlikely to happen.

Edit: I've bisected the kernel between 5.6 and 5.7 to arrive here:

9000edb71ab29d184aa33f5a77fa6e52d8812bb9 is the first bad commit commit 9000edb71ab29d184aa33f5a77fa6e52d8812bb9 Author: Jakub Kicinski Date: Mon Mar 16 13:47:12 2020 -0700

net: ethtool: require drivers to set supported_coalesce_params

Now that all in-tree drivers have been updated we can
make the supported_coalesce_params mandatory.

To save debugging time in case some driver was missed
(or is out of tree) add a warning when netdev is registered
with set_coalesce but without supported_coalesce_params.

Edit: I've created a PR:

wget commented on 2020-02-06 16:50

@stuartiannaylor You are right wrt. the udev rule file. It isn't applied to our package. I'll make sure to copy that file to the right location. That's something we forgot IMHO.

@all I removed the issue tracker on the GitHub repo hosting sources for this package because a lot of people were reporting issues that were meant to be handled upstream :)

hcartiaux commented on 2019-08-27 09:32

@stuartiannaylor: I cannot support Manjaro, never used it

stuartiannaylor commented on 2019-07-28 16:36

@hcartiaux output blank but it is a usb device?

I am also on Arm64 Manjaro just to let know and also had to install linux-headers.

Doh though I just had to copy 50-usb-realtek-net.rules to /etc/udev/udev.rules

I did do a depmod -a & mkinitcpio -p linux-aarch64 But not sure if I had to or that made any difference but on majaro

install headers

install aur

cp 50-usb-realtek-net.rules /etc/udev/udev.rules/50-usb-realtek-net.rules

There is one last thing if you are running tlp or some form of powersave service as make sure the adaptor is excluded.

sudo nano /etc/default/tlp



I am wondering as some distro's post 4.15 don't need the driver and presume use the r8152 mainline kernel driver? Its brilliant that someone has created an Aur but yeah should the r8152 driver load and its just the module.order?

Also not bad for an Armsoc with makepkg -Acs was expecting about 2.35Gbs with approx 95% efficiency looks like its struggling slightly with 2.15Gbs avg.

If it goes on a big core it manages 2.3+ Gbs echo 5 > /proc/irq/223/smp_affinity_list

many thanks will have to see how things go with Samba :)

hcartiaux commented on 2019-07-28 08:25

@stuartiannaylor Can you share the output of "lspci -knn" ?

stuartiannaylor commented on 2019-07-28 04:23

I have installed via makepkg and pacman Prob being dumb but even after a depmod -a its still using the cdc_ncm driver

Anyone help? :)