Due to a recent update on Javascript code a full page refresh on your browser might be needed.
Bug 1713657 - Dell DA200 Ethernet (Realtek R8153) not finding link
Summary: Dell DA200 Ethernet (Realtek R8153) not finding link
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 30
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-24 12:16 UTC by Gergely Gombos
Modified: 2020-03-20 07:35 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-09 07:53:49 UTC
Type: Bug


Attachments (Terms of Use)
dmesg (108.96 KB, text/plain)
2019-05-24 12:16 UTC, Gergely Gombos
no flags Details


Links
System ID Priority Status Summary Last Updated
Debian BTS 919656 None None None 2019-05-25 16:32:33 UTC

Description Gergely Gombos 2019-05-24 12:16:42 UTC
Created attachment 1572885 [details]
dmesg

1. Please describe the problem:

Dell DA200 (USB-C Thunderbolt adapter) has a Realtek R8153 Ethernet interface, uses r8152 driver.
The connection works in Windows with the same machine so it's not a hardware issue.
Machine: Dell XPS 9560.
The interface shows up in Network Manager, but finds no link.

dmesg:
[  107.397788] usb 4-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd
[  107.410281] usb 4-1.1: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00
[  107.410289] usb 4-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[  107.410293] usb 4-1.1: Product: USB 10/100/1000 LAN
[  107.410297] usb 4-1.1: Manufacturer: Realtek
[  107.410300] usb 4-1.1: SerialNumber: 000001000000
[  107.487204] usb 4-1.1: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
[  107.503728] r8152 4-1.1:1.0 (unnamed net_device) (uninitialized): Using pass-thru MAC addr 10:65:30:87:ae:82
[  108.079751] r8152 4-1.1:1.0 eth0: v1.09.9
[  108.231251] r8152 4-1.1:1.0 enp62s0u1u1: renamed from eth0
[  138.999098] r8152 4-1.1:1.0 enp62s0u1u1: Stop submitting intr, status -71

I read that it may be a power management issue, but blacklisting the device in TLP or even creating an udev rule didn't help.

ethtool (with Ethernet cable connected to router):
Settings for enp62s0u1u1:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  Not reported
	Advertised pause frame use: No
	Advertised auto-negotiation: No
	Advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Half
	Port: MII
	PHYAD: 32
	Transceiver: internal
	Auto-negotiation: off
	Supports Wake-on: pumbg
	Wake-on: p
	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: no

I wonder why auto-negotiation is off and ethtool -s enp62s0u1u1 autoneg on doesn't turn it on apparently.

ifconfig:
enp62s0u1u1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 10:65:30:87:ae:82  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

2. What is the Version-Release number of the kernel:
5.0.17-300.fc30.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
The last reports of a working DA200 on the Internet were for kernel 4 so they don't tell much.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
Plug in the dock. The Ethernet green connection LED stays on, the other is flashing, then stops flashing.
(HDMI, USB etc. are all working fine)

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
Couldn't test it, I get a GPG key error when trying to update. :(

6. Are you running any modules that not shipped with directly Fedora's kernel?:
No

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Comment 1 Gergely Gombos 2019-05-25 16:32:33 UTC
I got a solution for the issue, applying a usbcore quirk kernel parameter:
usbcore.quirks=0bda:8153:k
which activates USB_QUIRK_NO_LPM flag.

I took the idea from a Surface Dock hardware solution: https://github.com/jakeday/linux-surface/issues/259#issuecomment-450585243
For that hardware, a kernel patch is on the way containing the quirk parameter.

But this is not a power-connected dock so turning off LPM for the Ethernet adapter may not be a correct solution, just a workaround?

See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919656

What do you think, what could be the correct course of action?

Comment 2 Justin M. Forbes 2019-08-20 17:41:39 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs.

Fedora 30 has now been rebased to 5.2.9-200.fc30.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31.

If you experience different issues, please open a new bug report for those.

Comment 3 Gergely Gombos 2019-08-26 07:37:20 UTC
I tested it. The issue still persists with kernel 5.2.9-200.fc30, usbcore quirks mode is still needed for this device.

Comment 4 Justin M. Forbes 2020-03-03 16:34:46 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs.

Fedora 30 has now been rebased to 5.5.7-100.fc30.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31.

If you experience different issues, please open a new bug report for those.

Comment 5 Gergely Gombos 2020-03-09 07:53:49 UTC
Closing this as I no longer have the device.

Comment 6 Gergely Gombos 2020-03-20 07:35:44 UTC
Closing this as I no longer have the device.


Note You need to log in before you can comment on or make changes to this bug.