[Bug 1232668] New: displaylink driver uses wrong ethernet module cdc_ncm instead of r8152
https://bugzilla.suse.com/show_bug.cgi?id=1232668 Bug ID: 1232668 Summary: displaylink driver uses wrong ethernet module cdc_ncm instead of r8152 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel:Drivers Assignee: kernel-bugs@suse.de Reporter: cookie170@web.de QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- The Lenovo USB-C Hybrid Dock (40AF) comes with a Realtek chip for the ethernet connection: r8152 and as far as I can see the displaylink.rules assume, the correct driver for ethernet were cdc_ncm. But no: There is a special r8152 driver, which seems to be included in the kernel. cdc_ncm does not work well with this chip. Suspend leads to crash which causes strange network effects in LAN. See this file: https://build.opensuse.org/projects/X11:XOrg/packages/displaylink-driver/fil... Discussion see here: https://forums.opensuse.org/t/realtek-r8152-build-with-dkms-fails/179813 The displaylink driver is provided by X11:Xorg repo https://download.opensuse.org/repositories/X11:/XOrg/ Workaround: - Download r8152 from github, make, sudo depmod -a, sudo make install. Copy the udev-rules file from downloaded archive to /etc/udev/rules.d. The ethernet connection will work, until the next kernel update. I've no idea why dkms fails with r8152, I've described my efforts in the openSUSE forum, as linked above. I'm a user. It's simply my assumption that the rules file were the culprit. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232668 https://bugzilla.suse.com/show_bug.cgi?id=1232668#c3 --- Comment #3 from Keks Dose <cookie170@web.de> --- (In reply to Joan Torres from comment #2)
So have you been able to run the displaylink with the r8152?
Please, could you tell me what you get when running lsusb with the dock plugged.
hwinfo --netcard 45: USB 00.0: 0200 Ethernet controller [Created at usb.122] Unique ID: NRyp.SW7EWJRoTxC Parent ID: W5SY.F3xf6emGGiB SysFS ID: /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6.3/3-6.3:1.0 SysFS BusID: 3-6.3:1.0 Hardware Class: network Model: "Lenovo ThinkPad Lan" Hotplug: USB Vendor: usb 0x17ef "Lenovo" Device: usb 0xa359 "ThinkPad Lan" Revision: "31.03" Serial ID: "301F5A52C" Driver: "r8152" Driver Modules: "r8152" Device File: enp0s20f0u6u3 Speed: 480 Mbps HW Address: 00:50:b6:f5:a5:2c Permanent HW Address: 00:50:b6:f5:a5:2c Link detected: yes Module Alias: "usb:v17EFpA359d3103dc00dsc00dp00icFFiscFFip00in00" Driver Info #0: Driver Status: r8152 is active Driver Activation Cmd: "modprobe r8152" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #58 (Hub) lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 015: ID 17ef:a356 Lenovo USB3.1 Hub Bus 002 Device 016: ID 17ef:a357 Lenovo USB3.1 Hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 003: ID 04f2:b6ea Chicony Electronics Co., Ltd Integrated Camera Bus 003 Device 005: ID 8087:0026 Intel Corp. AX201 Bluetooth Bus 003 Device 016: ID 06cb:00fc Synaptics, Inc. Prometheus Fingerprint Reader Bus 003 Device 017: ID 17ef:1028 Lenovo USB2.0 Hub Bus 003 Device 018: ID 17e9:6015 DisplayLink ThinkPad Hybrid USB-C with USB-A Dock Bus 003 Device 019: ID 17ef:a359 Lenovo ThinkPad Lan Bus 003 Device 020: ID 17ef:1029 Lenovo USB2.0 Hub Bus 003 Device 021: ID 1a40:0101 Terminus Technology Inc. Hub Bus 003 Device 022: ID 17ef:a354 Lenovo Billboard Device Bus 003 Device 023: ID 17ef:6099 Lenovo Lenovo Traditional USB Keyboard Bus 003 Device 024: ID 1395:0052 DSEA A/S Sennheiser SDW 5 BS - EU Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub ethtool enp0s20f0u6u3 Settings for enp0s20f0u6u3: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on Port: MII PHYAD: 20 Transceiver: internal Supports Wake-on: pumbg Wake-on: g Current message level: 0x00007fff (32767) drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol Link detected: yes Sorry for very late answer! -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232668 https://bugzilla.suse.com/show_bug.cgi?id=1232668#c5 --- Comment #5 from Keks Dose <cookie170@web.de> --- (In reply to Joan Torres from comment #4)
If you use the driver installed from Sauerland repo: https://build.opensuse.org/package/show/home:Sauerland:hardware/r8152
r8152 driver should be updated when the kernel is updated, I think that could fix your issue.
If you are using Tumbleweed: zypper addrepo https://download.opensuse.org/repositories/home:Sauerland:hardware/ openSUSE_Tumbleweed/home:Sauerland:hardware.repo zypper ref zypper in r8152-kmp-default r8152-udev-rules r8152-ueficert
Thank you! The idea of this bugreport is broader than coming to terms with my own installation. Isn't there a reason why the kernel loads the wrong driver as described in my report? By the way: There are multiple eth2usb chips. Most current notebooks lack a RJ45 socket, so people buy a kind of adapter. I own three, all three equipped with a different chip. Only one works out of the box. One needs help: the command 'hwinfo --netcard' somehow triggers loading it. See here: https://bugzilla.suse.com/show_bug.cgi?id=1217503 What I'm trying (with this bugreport e.g.) is to help to improve the situation not only for me, but for all users and I "only" receive help for my issue. I just talked to a friend (who is a professional programmer on MS platforms). He laughed about it: So Linux still is "plug & pray" for some USB adapters? Haha. I understand the difficulty: the developers don't own all usb dongles to test. But the problem will be here as long as we have eth2usb chips and right now the industrie starts offering "2.5 Gb/s" dongles. If I can help (well, not professionally: I'm a lawyer in renewable energies business), let me know. And many thanks for your time and effort. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232668 https://bugzilla.suse.com/show_bug.cgi?id=1232668#c7 --- Comment #7 from Keks Dose <cookie170@web.de> --- (In reply to Joan Torres from comment #6)
The r8152 driver is already provided by kernel-default.
Could the lack of udev rules for r8152 make it use cdc_ncm instead of r8152?
Please, Keks, could you remove r8152-kmp-default and r8152-ueficert. And leave only the rules: r8152-udev-rules.
Does that make it work?
Takashi, who should we reach if something at r8152 driver is missing?
1. I downloaded the source code here: https://github.com/wget/realtek-r8152-linux and make, sudo depmod -a, make install after a kernel update. The install step often fails at the first attempt with an error message. I got the udev-rule from github as well and copied it to /etc/udev/rules.d, the name is 50-usb-realtek-net.rules If the kernel module would work, I'd see it after any kernel update. But after a kernel update the r8152 module will not be loaded, despite the udev rule still in place. May it be the wrong place? Should I copy or move it to /usr/lib/udev/rules.d ? 2. I don't know what you exactly mean with "remove": make uninstall? 3. zypper search r8152 Repository-Daten werden geladen... Installierte Pakete werden gelesen... Keine passenden Objekte gefunden. While: zypper search ueficert Repository-Daten werden geladen... Installierte Pakete werden gelesen... S | Name | Summary | Type ---+----------------------+----------------------------------------------------------+------ | broadcom-wl-ueficert | UEFI Secure Boot Certificate For Package broadcom-wl-kmp | Paket i+ | evdi-ueficert | UEFI Secure Boot Certificate For Package evdi-kmp | Paket | xpadneo-ueficert | UEFI Secure Boot Certificate For Package xpadneo-kmp | Paket So there is no r8152 package with an ueficert installed. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232668 https://bugzilla.suse.com/show_bug.cgi?id=1232668#c9 Keks Dose <cookie170@web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? --- Comment #9 from Keks Dose <cookie170@web.de> --- (In reply to Takashi Iwai from comment #8)
(In reply to Joan Torres from comment #6)
The r8152 driver is already provided by kernel-default.
Could the lack of udev rules for r8152 make it use cdc_ncm instead of r8152?
Please, Keks, could you remove r8152-kmp-default and r8152-ueficert. And leave only the rules: r8152-udev-rules.
Does that make it work?
Takashi, who should we reach if something at r8152 driver is missing?
I guess that the upstream r8512 driver doesn't support this model (17ef:a359) yet.
The downstream r8152 driver has the support of the newer chip, and possibly this device belong to it. Or, if it's an old model but just missing the USB ID entry in the probe table, it's easy to activate with the upstream kernel driver, too.
Basically someone who worked on the downstream driver should send the fix patch to the upstream, but it didn't happen automagically, unfortunately.
So would it be helpful if I open an issue at the mentioned github r8152 site and refer to this conversation here? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1232668 https://bugzilla.suse.com/show_bug.cgi?id=1232668#c12 --- Comment #12 from Keks Dose <cookie170@web.de> --- (In reply to Takashi Iwai from comment #11)
(In reply to Keks Dose from comment #9)
Basically someone who worked on the downstream driver should send the fix patch to the upstream, but it didn't happen automagically, unfortunately.
So would it be helpful if I open an issue at the mentioned github r8152 site and refer to this conversation here?
If they hear the github issues, yeah, go ahead.
https://github.com/wget/realtek-r8152-linux/issues/45 -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com