Bug 215939 - r8152: 4-1.2:1.0 enxd481d7358c11: Stop submitting intr, status -71, after resume from sleep
Summary: r8152: 4-1.2:1.0 enxd481d7358c11: Stop submitting intr, status -71, after res...
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Network (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_network@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-04 07:39 UTC by Piotr Kołaczkowski
Modified: 2022-08-10 07:42 UTC (History)
0 users

See Also:
Kernel Version: 5.18.0-051800rc5-generic
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Piotr Kołaczkowski 2022-05-04 07:39:21 UTC
I'm using Dell Precision 5520 laptop connected to TB16 Dell Dock. 

Initially everything works fine after boot. 

When I suspend and then wake up the system into sleep, the ethernet link is not detected any more:

$ sudo ethtool enxd481d7358c11
Settings for enxd481d7358c11:
	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:  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/Half 1000baseT/Full
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Port: MII
	PHYAD: 32
	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: no


The following error appears in syslog many times after resume:

May  3 19:28:05 p5520 kernel: [123137.406218] r8152 4-1.2:1.0 enxd481d7358c11: Stop submitting intr, status -71

Sometimes there is additional error nearby (not sure if related), but this doesn't appear every time:

May  3 19:28:04 p5520 kernel: [123136.941783] pcieport 0000:00:1d.6: AER: Corrected error received: 0000:06:00.0
May  3 19:28:04 p5520 kernel: [123136.941795] pcieport 0000:06:00.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
May  3 19:28:04 p5520 kernel: [123136.941798] pcieport 0000:06:00.0:   device [8086:1576] error status/mask=00000080/00002000
May  3 19:28:04 p5520 kernel: [123136.941802] pcieport 0000:06:00.0:    [ 7] BadDLLP               


I tried passing pcie_aspm=off to kernel, but it didn't help.

The only workaround that I've found so far is to replug the dock thunderbolt cable. 

The problem also exists in the kernel 5.15.0 shipped with Ubuntu 22.04 LTS. 

I'm running the most up-to date bios / firmware for the laptop, as well as the most up-to-date TB16 firmware (confirmed both with Linux fwupdmgr as well as the official TB16 update utility from Dell for Windows 10). 


$ fwupdmgr update
Devices with no available firmware updates: 
 • Dell TB16 EC
 • Dell TB16 Port Controller 1
 • Dell TB16 Port Controller 2
 • Dell TB16 Thunderbolt Cable
 • THNSN5512GPUK NVMe TOSHIBA 512GB
 • Thunderbolt Cable
 • Thunderbolt Dock
 • UEFI dbx
Devices with the latest available firmware version:
 • System Firmware
 • Thunderbolt host controller
Comment 1 Piotr Kołaczkowski 2022-08-10 07:42:30 UTC
The bug still exists in the newest Ubuntu mainline kernel:
Linux p5520 5.19.0-051900-generic #202207312230 SMP PREEMPT_DYNAMIC Sun Jul 31 22:34:11 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux.

One more observation:
Frequently the system is able to resume ethernet correctly on the *first* suspend/resume after fresh boot. It typically fails the *second* time. But once it loses the ethernet connectivity, no number of subsequent suspend/resume cycles brings it back.

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