Ubuntu

USB Ethernet adapter not discovered on Ubuntu 22.04.1 after leaving suspend state

Asked by Marek Hajduczenia

STEP 1: Device initialized during the boot process (RTL8152-based 2.5GE Anker USB-C adapter), all works fine

sudo dmesg | grep r8
[ 0.119521] percpu: Embedded 60 pages/cpu s208896 r8192 d28672 u262144
[ 0.119533] pcpu-alloc: s208896 r8192 d28672 u262144 alloc=1*2097152
[ 1.807418] r8152: loading out-of-tree module taints kernel.
[ 1.813359] r8152: module verification failed: signature and/or required key missing - tainting kernel
[ 2.033809] r8152 4-1:1.0 (unnamed net_device) (uninitialized): netif_napi_add() called with weight 256
[ 2.034224] r8152 4-1:1.0 eth0: v2.15.0 (2021/04/15)
[ 2.034229] r8152 4-1:1.0 eth0: This product is covered by one or more of the following patents:
[ 2.034312] usbcore: registered new interface driver r8152
[ 2.054400] r8152 4-1:1.0 enx00e04c92d40b: renamed from eth0
[ 3.757696] r8152 4-1:1.0 eth0: v2.15.0 (2021/04/15)
[ 3.757699] r8152 4-1:1.0 eth0: This product is covered by one or more of the following patents:
[ 3.812033] r8152 4-1:1.0 enx00e04c92d40b: renamed from eth0
[ 6.688353] r8152 4-1:1.0 enx00e04c92d40b: carrier on

STEP 2: device removed and then plugged back in

[ 655.501827] usb 4-1: USB disconnect, device number 2
[ 655.502134] xhci_hcd 0000:37:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
[ 667.009502] usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd
[ 667.030503] usb 4-1: New USB device found, idVendor=0bda, idProduct=8156, bcdDevice=31.00
[ 667.030513] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 667.030517] usb 4-1: Product: USB 10/100/1G/2.5G LAN
[ 667.030520] usb 4-1: Manufacturer: Realtek
[ 667.030522] usb 4-1: SerialNumber: 001000001
[ 667.166486] usb 4-1: reset SuperSpeed USB device number 3 using xhci_hcd

STEP 3: suspend the system, remove the adapter, wake the system up, and then plug in he adapter - network did come back up

[ 791.650931] usb 4-1: new SuperSpeed USB device number 4 using xhci_hcd
[ 791.671864] usb 4-1: New USB device found, idVendor=0bda, idProduct=8156, bcdDevice=31.00
[ 791.671879] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 791.671885] usb 4-1: Product: USB 10/100/1G/2.5G LAN
[ 791.671889] usb 4-1: Manufacturer: Realtek
[ 791.671893] usb 4-1: SerialNumber: 001000001
[ 791.811145] usb 4-1: reset SuperSpeed USB device number 4 using xhci_hcd

STEP 4: suspend the system, remove the adapter, (give it some time, about 2 minutes), plug in the adapter, and wake the system up with adapter in, driver is not accessible anymore and network is not visible

[ 906.078174] ACPI: EC: interrupt unblocked
[ 907.712397] xhci_hcd 0000:37:00.0: can't change power state from D3cold to D0 (config space inaccessible)
[ 907.788616] xhci_hcd 0000:37:00.0: can't change power state from D3cold to D0 (config space inaccessible)
[ 907.788639] xhci_hcd 0000:37:00.0: Controller not ready at resume -19
[ 907.788640] xhci_hcd 0000:37:00.0: PCI post-resume error -19!
[ 907.788641] xhci_hcd 0000:37:00.0: HC died; cleaning up
[ 907.788644] PM: dpm_run_callback(): pci_pm_resume+0x0/0x100 returns -19
[ 907.788652] xhci_hcd 0000:37:00.0: PM: failed to resume async: error -19
[ 908.074749] OOM killer enabled.
[ 908.074751] Restarting tasks ... done.
[ 908.085161] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[ 908.103611] thermal thermal_zone12: failed to read out thermal zone (-61)
[ 908.103904] PM: suspend exit
[ 908.111346] usbcore: registered new interface driver r8152

It *seems* that waking the system up from a suspended state breaks something in the USB adapter initialization process. I am able to reproduce it reliably, i.e., after a clean system reboot, when I repeat step 4 above, I always end up with a broken network adapter irrespective of the installed drivers. If process outlined in step 3 is followed, i.e., adapter is plugged in after the system comes out of suspended state, everything seems to recover correctly and the network adapter comes back online.

Any clue what this might be and how to remedy it?

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Solved by:
Marek Hajduczenia
Solved:
Last query:
Last reply:
Revision history for this message
Manfred Hampl (m-hampl) said : 		#1

What happens if you do not remove the adapter while the computer is in sleep mode?

There is the possibility to automatically run a script before suspend and another script after wake-up.
Maybe unloading the kernel module before suspend and re-loading it after wake-up is the crucial action.

As a first step you have to find out which driver the device is using (probably r8152).
sudo lshw -C network

Then test the action the following way:

Open a terminal window and issue the command
sudo modprobe -r r8152
(if that is the driver in use)

put the computer to sleep

wake it up

Isssue the command
sudo modprobe r8152

Revision history for this message
Marek Hajduczenia (mxhajduczenia) said : 		#2

Thank you for the answer.

The drive is in use

lsmod | grep r8
r8152 241664 0

lshw -C network
  *-network
       description: Wireless interface
       product: Comet Lake PCH-LP CNVi WiFi
       vendor: Intel Corporation
       physical id: 14.3
       bus info: pci@0000:00:14.3
       logical name: wlp0s20f3
       version: 00
       serial: 10:3d:1c:07:2e:cf
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=iwlwifi driverversion=5.15.0-52-generic firmware=66.f1c864e0.0 QuZ-a0-hr-b0-66.u ip=192.168.150.64 latency=0 link=yes multicast=yes wireless=IEEE 802.11
       resources: irq:16 memory:e0110000-e0113fff
  *-network
       description: Ethernet interface
       physical id: 14
       bus info: usb@4:1
       logical name: enx00e04c92d40b
       serial: 00:e0:4c:92:d4:0b
       size: 1Gbit/s
       capacity: 1Gbit/s
       capabilities: ethernet physical mii 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8152 driverversion=v2.15.0 (2021/04/15) duplex=full ip=192.168.150.22 link=yes multicast=yes port=MII speed=1Gbit/s

and when the adapter disappears, the driver does not disappear from the system - the lsmod output is exactly the same, but the network adapter is not discovered

lshw -C network
  *-network
       description: Wireless interface
       product: Comet Lake PCH-LP CNVi WiFi
       vendor: Intel Corporation
       physical id: 14.3
       bus info: pci@0000:00:14.3
       logical name: wlp0s20f3
       version: 00
       serial: 10:3d:1c:07:2e:cf
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=iwlwifi driverversion=5.15.0-52-generic firmware=66.f1c864e0.0 QuZ-a0-hr-b0-66.u ip=192.168.150.64 latency=0 link=yes multicast=yes wireless=IEEE 802.11
       resources: irq:16 memory:e0110000-e0113fff

It is as if waking from suspend state with the adapter attached prevents the system from correctly re-discovering it. I do not think "Maybe unloading the kernel module before suspend and re-loading it after wake-up is the crucial action." does anything in this case - I did try it a few times for a good measure, though, and no change was observed.

Revision history for this message
Marek Hajduczenia (mxhajduczenia) said (last edit ): 		#3

After some additional debugging, I think you might be onto something. Once I get the OS into the target state, I do not see the driver under "lsmod | grep r8" and when it gets force loaded with "modprobe r8152", it pops right back. This would imply the kernel module is offloaded and not loaded back, I assume?

Revision history for this message
Manfred Hampl (m-hampl) said : 		#4

Try adding the -v (=verbose) flag to the modprobe command. It will tell what it is doing.

If you do this manually:

sudo modprobe -rv r8152
put the computer to sleep
wake it up
Isssue the command
sudo modprobe -v r8152

What does it show, and does the network adapter work again?

Revision history for this message
Marek Hajduczenia (mxhajduczenia) said : 		#5

All I got from this experiment is as follows

sudo modprobe -rv r8152
rmmod r8152

<<<sleepy time>>>

sudo modprobe -v r8152
insmod /lib/modules/5.15.0-52-generic/updates/dkms/r8152.ko

lsmod | grep r8
r8152 241664 0

so driver is loaded, but this time around I did not have the adapter recognized when coming out of suspend mode.

Revision history for this message
Marek Hajduczenia (mxhajduczenia) said : 		#6

More data from dmseg sequence starting from modprobe remove command - the adapter is dead and not recognized, contrary to the expectations. I believe the driver is not the issue then

[151934.569489] usbcore: deregistering interface driver r8152
[151934.569686] r8152 4-2:1.0 enx00e04ccd1b81: Stop submitting intr, status -108
[151934.664192] PM: suspend entry (s2idle)
[151934.674681] Filesystems sync: 0.010 seconds
[151934.679986] Freezing user space processes ... (elapsed 0.177 seconds) done.
[151934.857045] OOM killer disabled.
[151934.857048] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
[151934.859996] printk: Suspending console(s) (use no_console_suspend to debug)
[151934.927088] intel_pch_thermal 0000:00:12.0: CPU-PCH is cool [57C], continue to suspend
[151935.006383] ACPI: EC: interrupt blocked
[157694.989553] ACPI: EC: interrupt unblocked
[157696.620149] xhci_hcd 0000:37:00.0: can't change power state from D3cold to D0 (config space inaccessible)
[157696.703813] xhci_hcd 0000:37:00.0: can't change power state from D3cold to D0 (config space inaccessible)
[157696.703828] xhci_hcd 0000:37:00.0: Controller not ready at resume -19
[157696.703830] xhci_hcd 0000:37:00.0: PCI post-resume error -19!
[157696.703831] xhci_hcd 0000:37:00.0: HC died; cleaning up
[157696.703835] PM: dpm_run_callback(): pci_pm_resume+0x0/0x100 returns -19
[157696.703843] xhci_hcd 0000:37:00.0: PM: failed to resume async: error -19
[157697.579471] OOM killer enabled.
[157697.579473] Restarting tasks ...
[157697.579504] usb 4-2: USB disconnect, device number 6
[157697.596521] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[157697.597026] done.
[157697.605826] thermal thermal_zone12: failed to read out thermal zone (-61)
[157697.610370] PM: suspend exit
[157697.624329] usbcore: registered new interface driver r8152
[157701.222054] wlp0s20f3: authenticate with 78:8a:20:52:e2:cf
[157701.224358] wlp0s20f3: send auth to 78:8a:20:52:e2:cf (try 1/3)
[157701.253014] wlp0s20f3: authenticated
[157701.260371] wlp0s20f3: associate with 78:8a:20:52:e2:cf (try 1/3)
[157701.263527] wlp0s20f3: RX AssocResp from 78:8a:20:52:e2:cf (capab=0x1511 status=0 aid=1)
[157701.269263] wlp0s20f3: associated
[157701.328903] wlp0s20f3: Limiting TX power to 30 (30 - 0) dBm as advertised by 78:8a:20:52:e2:cf
[157701.357452] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s20f3: link becomes ready
[157702.656103] xhci_hcd 0000:37:00.0: xHCI host controller not responding, assume dead
[157702.656115] xhci_hcd 0000:37:00.0: HC died; cleaning up
[157702.656170] xhci_hcd 0000:37:00.0: Timeout while waiting for configure endpoint command
[157783.380851] usbcore: deregistering interface driver r8152
[157784.897908] usbcore: registered new interface driver r8152
[157848.931518] usbcore: deregistering interface driver r8152
[158068.320295] wlp0s20f3: deauthenticating from 78:8a:20:52:e2:cf by local choice (Reason: 3=DEAUTH_LEAVING)
[158072.905158] PM: suspend entry (s2idle)
[158072.914443] Filesystems sync: 0.009 seconds
[158072.927254] Freezing user space processes ... (elapsed 0.003 seconds) done.
[158072.930490] OOM killer disabled.
[158072.930491] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[158072.932200] printk: Suspending console(s) (use no_console_suspend to debug)
[158073.040889] intel_pch_thermal 0000:00:12.0: CPU-PCH is cool [54C], continue to suspend
[158073.116910] ACPI: EC: interrupt blocked
[158077.021967] ACPI: EC: interrupt unblocked
[158078.428514] xhci_hcd 0000:37:00.0: enabling device (0400 -> 0402)
[158079.303848] OOM killer enabled.
[158079.303853] Restarting tasks ... done.
[158079.322395] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[158079.324979] thermal thermal_zone12: failed to read out thermal zone (-61)
[158079.329417] PM: suspend exit
[158079.342749] usbcore: registered new interface driver r8152
[158082.891628] wlp0s20f3: authenticate with 78:8a:20:52:e2:cf
[158082.894033] wlp0s20f3: send auth to 78:8a:20:52:e2:cf (try 1/3)
[158082.923059] wlp0s20f3: authenticated
[158082.923968] wlp0s20f3: associate with 78:8a:20:52:e2:cf (try 1/3)
[158082.927833] wlp0s20f3: RX AssocResp from 78:8a:20:52:e2:cf (capab=0x1511 status=0 aid=1)
[158082.933535] wlp0s20f3: associated
[158083.001194] wlp0s20f3: Limiting TX power to 30 (30 - 0) dBm as advertised by 78:8a:20:52:e2:cf

Revision history for this message
Marek Hajduczenia (mxhajduczenia) said : 		#7

So just an update after a few hours of digging into Realtek fora in Chinese in translation ... I upgraded from 2.15.0 kernel driver to 2.16.3 (official released by Realtek).

[ 87.042493] usbcore: deregistering interface driver r8152
[ 87.042811] r8152 4-1:1.0 enx00e04c92d40b: Stop submitting intr, status -108
[ 225.349787] usb 4-1: USB disconnect, device number 2
[ 236.750691] usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd
[ 236.771300] usb 4-1: New USB device found, idVendor=0bda, idProduct=8156, bcdDevice=31.00
[ 236.771303] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 236.771304] usb 4-1: Product: USB 10/100/1G/2.5G LAN
[ 236.771305] usb 4-1: Manufacturer: Realtek
[ 236.771306] usb 4-1: SerialNumber: 001000001
[ 236.918259] usb 4-1: reset SuperSpeed USB device number 3 using xhci_hcd
[ 236.998512] r8152 4-1:1.0 eth0: v2.16.3 (2022/07/06)
[ 236.998520] r8152 4-1:1.0 eth0: This product is covered by one or more of the following patents:
                 US6,570,884, US6,115,776, and US6,327,625.

[ 236.998623] usbcore: registered new interface driver r8152
[ 237.026247] r8152 4-1:1.0 enx00e04c92d40b: renamed from eth0
[ 240.071287] IPv6: ADDRCONF(NETDEV_CHANGE): enx00e04c92d40b: link becomes ready
[ 240.071627] r8152 4-1:1.0 enx00e04c92d40b: carrier on

This is the suspend event and this time around it seems that the device was properly rediscovered on resume, with carrier discovered correctly. I ran the sequence at least 3 times with different suspend mode duration and every time the adapter recovered.

[ 5169.615121] wlp0s20f3: deauthenticating from 78:8a:20:52:e2:cf by local choice (Reason: 3=DEAUTH_LEAVING)
[ 5171.795237] PM: suspend entry (s2idle)
[ 5171.809671] Filesystems sync: 0.014 seconds
[ 5172.086248] Freezing user space processes ... (elapsed 0.006 seconds) done.
[ 5172.092375] OOM killer disabled.
[ 5172.092376] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 5172.094036] printk: Suspending console(s) (use no_console_suspend to debug)
[ 5172.406116] intel_pch_thermal 0000:00:12.0: CPU-PCH is cool [46C], continue to suspend
[ 5172.482742] ACPI: EC: interrupt blocked
[ 5177.737607] ACPI: EC: interrupt unblocked
[ 5179.577703] OOM killer enabled.
[ 5179.577704] Restarting tasks ...
[ 5179.581242] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[ 5179.582274] done.
[ 5179.607532] thermal thermal_zone12: failed to read out thermal zone (-61)
[ 5179.610974] PM: suspend exit
[ 5182.859178] IPv6: ADDRCONF(NETDEV_CHANGE): enx00e04c92d40b: link becomes ready
[ 5182.862361] r8152 4-1:1.0 enx00e04c92d40b: carrier on
[ 5183.227659] wlp0s20f3: authenticate with fc:ec:da:a5:93:9c
[ 5183.237581] wlp0s20f3: send auth to fc:ec:da:a5:93:9c (try 1/3)
[ 5183.328451] wlp0s20f3: authenticated
[ 5183.331173] wlp0s20f3: associate with fc:ec:da:a5:93:9c (try 1/3)
[ 5183.336153] wlp0s20f3: RX AssocResp from fc:ec:da:a5:93:9c (capab=0x1511 status=0 aid=2)
[ 5183.342133] wlp0s20f3: associated
[ 5183.408150] wlp0s20f3: Limiting TX power to 30 (30 - 0) dBm as advertised by fc:ec:da:a5:93:9c
[ 5183.410088] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s20f3: link becomes ready
[ 5187.056079] wlp0s20f3: disconnect from AP fc:ec:da:a5:93:9c for new auth to 78:8a:20:52:e2:cf
[ 5187.084017] wlp0s20f3: authenticate with 78:8a:20:52:e2:cf
[ 5187.088885] wlp0s20f3: send auth to 78:8a:20:52:e2:cf (try 1/3)
[ 5187.119435] wlp0s20f3: authenticated
[ 5187.123335] wlp0s20f3: associate with 78:8a:20:52:e2:cf (try 1/3)
[ 5187.126459] wlp0s20f3: RX ReassocResp from 78:8a:20:52:e2:cf (capab=0x1511 status=0 aid=1)
[ 5187.132169] wlp0s20f3: associated
[ 5187.142340] wlp0s20f3: Limiting TX power to 30 (30 - 0) dBm as advertised by 78:8a:20:52:e2:cf

I will continue observing but it seems that it was a driver issue all along and the only problem is that whether the next kernel releases override anything or not.

Revision history for this message
Manfred Hampl (m-hampl) said : 		#8

From the output in comment #6
[157696.703813] xhci_hcd 0000:37:00.0: can't change power state from D3cold to D0 (config space inaccessible)
[157696.703828] xhci_hcd 0000:37:00.0: Controller not ready at resume -19
[157696.703830] xhci_hcd 0000:37:00.0: PCI post-resume error -19!
[157696.703831] xhci_hcd 0000:37:00.0: HC died; cleaning up
it seems that at that time the general USB driver crashed.

Anyhow, if it works in the moment, I hope that it will stay like that.

Revision history for this message
Marek Hajduczenia (mxhajduczenia) said : 		#9

Well, the driver did not change anything on the USB hub side of things so perhaps the newer driver did resolve the crash, whatever was causing it. Either way, it seems to be working with no glitches now and the laptop woke up after all night suspend with no issues at all.