You are not logged in.
Pages: 1
Hey. I'm running Arch on Asus Zenbook 14 UX425QA laptop using a USB hub docking station (Baseus Working Station). It has a gigabyte ethernet adapter, which is working weirdly. It randomly can drop connections with Tx status -71 error. I tried to use kernel drivers and also r8152-dkms aur package, no changes. Also, I had issues with the previous Ugreen adapter.
inxi -b
System:
Host: vd-pc Kernel: 5.15.104-1-lts-515-git arch: x86_64 bits: 64
Desktop: Xfce v: 4.18.1 Distro: Arch Linux
Machine:
Type: Laptop System: ASUSTeK product: ZenBook UX425QA_UM425QA v: 1.0
serial: <superuser required>
Mobo: ASUSTeK model: UX425QA v: 1.0 serial: <superuser required>
UEFI: American Megatrends LLC. v: UX425QA.306 date: 11/22/2022
Battery:
ID-1: BATT charge: 33.2 Wh (60.0%) condition: 55.3/63.1 Wh (87.7%)
volts: 12.0 min: 12.0
CPU:
Info: 8-core AMD Ryzen 7 5800H with Radeon Graphics [MT MCP] speed (MHz):
avg: 1197 min/max: 1200/4462
Graphics:
Device-1: AMD Cezanne [Radeon Vega Series / Radeon Mobile Series]
driver: amdgpu v: kernel
Device-2: Quanta USB2.0 HD UVC WebCam type: USB driver: uvcvideo
Display: x11 server: X.Org v: 21.1.8 with: Xwayland v: 23.1.1 driver: X:
loaded: amdgpu unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu
resolution: 1: 2560x1080 2: 1920x1080 3: 1920x1080~60Hz
API: OpenGL v: 4.6 Mesa 23.0.1 renderer: AMD Radeon Graphics (renoir LLVM
15.0.7 DRM 3.42 5.15.104-1-lts-515-git)
Network:
Device-1: Intel Wireless 8265 / 8275 driver: iwlwifi
Device-2: Intel Bluetooth wireless interface type: USB driver: btusb
Device-3: Realtek RTL8153 Gigabit Ethernet Adapter type: USB driver: r8152
Drives:
Local Storage: total: 1.82 TiB used: 815.48 GiB (43.8%)
Info:
Processes: 397 Uptime: 2h 45m Memory: 15.03 GiB used: 5.41 GiB (36.0%)
Shell: Zsh inxi: 3.3.26
Dmesg
[ 3547.955940] r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -71
[ 3547.964069] r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -71
[ 3547.972186] r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -71
[ 3547.980316] r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -71
[ 3547.988440] r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -71
[ 3547.996559] r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -71
[ 3548.004689] r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -71
[ 3548.012814] r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -71
[ 3548.020938] r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -71
[ 3548.029064] r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -71
lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 006: ID 2109:0820 VIA Labs, Inc. VL820 Hub
Bus 002 Device 008: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 002 Device 005: ID 2109:0817 VIA Labs, Inc. USB3.0 Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2b Intel Corp. Bluetooth wireless interface
Bus 001 Device 002: ID 0408:30c0 Quanta Computer, Inc. USB2.0 HD UVC WebCam
Bus 001 Device 015: ID 2109:2820 VIA Labs, Inc. VL820 Hub
Bus 001 Device 020: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver
Bus 001 Device 018: ID 046d:0acb Logitech, Inc. G435 Wireless Gaming Headset
Bus 001 Device 021: ID 0c76:161e JMTek, LLC. USB PnP Audio Device
Bus 001 Device 019: ID 1ea7:0907 SHARKOON Technologies GmbH Keyboard
Bus 001 Device 017: ID 214b:7250 Huasheng Electronics USB2.0 HUB
Bus 001 Device 016: ID 0c76:161f JMTek, LLC. USB PnP Audio Device
Bus 001 Device 014: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 013: ID 2109:2817 VIA Labs, Inc. USB2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
|__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 3: Dev 8, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
|__ Port 4: Dev 6, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 1: Dev 13, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 14, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 16, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 16, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 16, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 16, If 3, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 17, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 19, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 19, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 1: Dev 19, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 21, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 4: Dev 21, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 4: Dev 21, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 18, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 18, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 18, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 18, If 3, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 20, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 20, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 20, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 15, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 3: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 3: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 3: Dev 2, If 2, Class=Video, Driver=uvcvideo, 480M
|__ Port 3: Dev 2, If 3, Class=Video, Driver=uvcvideo, 480M
|__ Port 3: Dev 2, If 4, Class=Application Specific Interface, Driver=, 480M
|__ Port 4: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 4: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
TLP conf
USB_DENYLIST="0bda:8153"
Offline
How does the system behave w/o TLP and/or usb autosuspend completely disabled, https://wiki.archlinux.org/title/Power_ … utosuspend ?
Otherwise please post your complete system journal for the boot - not some random dmesg grep:
sudo journalctl -b | curl -F 'file=@-' 0x0.st
Offline
Thanks for your reply!
How does the system behave w/o TLP and/or usb autosuspend completely disabled
No impact if I'll disable auto suspend for a device or entirely for all devices. Same for TLP, nothing is changing.
Here's a complete system journal: http://0x0.st/HXaS.txt
For a quick workaround, I do:
sudo rmmod r8153_ecm r8152 && sudo modprobe r8153_ecm r8152
It helps for some time, but then the issue appears again. And also after this command, it can throw me a trace below, and only a reboot could bring the device back alive.
Apr 06 17:32:50 vd-pc kernel: ------------[ cut here ]------------
Apr 06 17:32:50 vd-pc kernel: NETDEV WATCHDOG: enp4s0f3u1u3 (r8152): transmit queue 0 timed out
Apr 06 17:32:50 vd-pc kernel: WARNING: CPU: 12 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x260/0x270
Apr 06 17:32:50 vd-pc kernel: Modules linked in: r8153_ecm r8152(OE) rfcomm xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c xt_addrtype iptable_filter snd_seq_dummy snd_hrtimer snd_seq br_netfilter bridge stp llc tun hid_semitek bnep qrtr ns overlay uvcvideo btusb videobuf2_vmalloc snd_usb_audio videobuf2_memops btrtl videobuf2_v4l2 btbcm videobuf2_common snd_usbmidi_lib btintel snd_rawmidi videodev snd_seq_device bluetooth mc ecdh_generic ccm algif_aead des_generic libdes ecb algif_skcipher cmac md4 algif_hash af_alg cdc_ether usbnet mii snd_ctl_led joydev mousedev snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_soc_dmic snd_acp3x_pdm_dma snd_acp3x_rn snd_soc_core snd_hda_codec_hdmi snd_compress intel_rapl_msr ac97_bus snd_pcm_dmaengine hid_multitouch iwlmvm intel_rapl_common snd_hda_intel mac80211 edac_mce_amd snd_intel_dspcfg snd_intel_sdw_acpi libarc4 snd_hda_codec snd_hda_core kvm_amd snd_hwdep
Apr 06 17:32:50 vd-pc kernel: snd_pci_acp5x snd_pcm kvm iwlwifi ucsi_acpi vfat snd_timer snd_rn_pci_acp3x sp5100_tco typec_ucsi irqbypass rapl typec asus_nb_wmi wmi_bmof k10temp pcspkr cfg80211 snd i2c_piix4 snd_pci_acp3x soundcore roles pinctrl_amd cm32181 industrialio i2c_hid_acpi amd_pmc acpi_cpufreq mac_hid vboxnetflt(OE) vboxnetadp(OE) vboxdrv(OE) pkcs8_key_parser dm_multipath ledtrig_timer sg crypto_user fuse acpi_call(OE) loop bpf_preload ip_tables x_tables usbhid dm_crypt cbc encrypted_keys dm_mod trusted asn1_encoder tee rtsx_pci_sdmmc crct10dif_pclmul mmc_core crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd ccp rtsx_pci i2c_hid fat ext4 crc32c_generic crc32c_intel crc16 mbcache jbd2 xhci_pci serio_raw xhci_pci_renesas i8042 atkbd libps2 serio asus_wmi sparse_keymap video platform_profile rfkill wmi amdgpu drm_ttm_helper ttm gpu_sched [last unloaded: r8152]
Apr 06 17:32:50 vd-pc kernel: CPU: 12 PID: 0 Comm: swapper/12 Tainted: G W OE 5.15.104-1-lts-515-git #1 100274d201da93a64d6fb55c04c07668cde25f7b
Apr 06 17:32:50 vd-pc kernel: Hardware name: ASUSTeK COMPUTER INC. ZenBook UX425QA_UM425QA/UX425QA, BIOS UX425QA.306 11/22/2022
Apr 06 17:32:50 vd-pc kernel: RIP: 0010:dev_watchdog+0x260/0x270
Apr 06 17:32:50 vd-pc kernel: Code: ff eb a8 4c 8b 3c 24 c6 05 03 7b 42 01 01 4c 89 ff e8 d4 c5 f9 ff 89 d9 4c 89 fe 48 c7 c7 f0 04 76 b8 48 89 c2 e8 a3 59 18 00 <0f> 0b eb 86 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 41
Apr 06 17:32:50 vd-pc kernel: RSP: 0018:ffffb26140480e88 EFLAGS: 00010282
Apr 06 17:32:50 vd-pc kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027
Apr 06 17:32:50 vd-pc kernel: RDX: ffff9f587e7206e8 RSI: 0000000000000001 RDI: ffff9f587e7206e0
Apr 06 17:32:50 vd-pc kernel: RBP: ffff9f575291841c R08: 0000000000000000 R09: ffffb26140480c98
Apr 06 17:32:50 vd-pc kernel: R10: ffffb26140480c90 R11: 0000000000000003 R12: ffff9f577f15b680
Apr 06 17:32:50 vd-pc kernel: R13: 000000000000000c R14: ffff9f57529184c0 R15: ffff9f5752918000
Apr 06 17:32:50 vd-pc kernel: FS: 0000000000000000(0000) GS:ffff9f587e700000(0000) knlGS:0000000000000000
Apr 06 17:32:50 vd-pc kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Apr 06 17:32:50 vd-pc kernel: CR2: 00007fc8fbdb1000 CR3: 00000001276e0000 CR4: 00000000007506e0
Apr 06 17:32:50 vd-pc kernel: PKRU: 55555554
Apr 06 17:32:50 vd-pc kernel: Call Trace:
Apr 06 17:32:50 vd-pc kernel: <IRQ>
Apr 06 17:32:50 vd-pc kernel: ? pfifo_fast_enqueue+0x150/0x150
Apr 06 17:32:50 vd-pc kernel: call_timer_fn+0x27/0xf0
Apr 06 17:32:50 vd-pc kernel: __run_timers+0x219/0x280
Apr 06 17:32:50 vd-pc kernel: run_timer_softirq+0x19/0x30
Apr 06 17:32:50 vd-pc kernel: __do_softirq+0xd0/0x295
Apr 06 17:32:50 vd-pc kernel: ? sched_clock_cpu+0x9/0xa0
Apr 06 17:32:50 vd-pc kernel: irq_exit_rcu+0x99/0xc0
Apr 06 17:32:50 vd-pc kernel: sysvec_apic_timer_interrupt+0x6e/0x90
Apr 06 17:32:50 vd-pc kernel: </IRQ>
Apr 06 17:32:50 vd-pc kernel: <TASK>
Apr 06 17:32:50 vd-pc kernel: asm_sysvec_apic_timer_interrupt+0x16/0x20
Apr 06 17:32:50 vd-pc kernel: RIP: 0010:cpuidle_enter_state+0xc7/0x360
Apr 06 17:32:50 vd-pc kernel: Code: 8b 3d 25 97 54 48 e8 e8 8a 80 ff 49 89 c5 0f 1f 44 00 00 31 ff e8 e9 98 80 ff 45 84 ff 0f 85 0e 01 00 00 fb 66 0f 1f 44 00 00 <45> 85 f6 0f 88 1a 01 00 00 49 63 ce 48 8d 04 49 48 8d 04 81 49 8d
Apr 06 17:32:50 vd-pc kernel: RSP: 0018:ffffb261401efea8 EFLAGS: 00000246
Apr 06 17:32:50 vd-pc kernel: RAX: ffff9f587e731280 RBX: 0000000000000002 RCX: 000000000000001f
Apr 06 17:32:50 vd-pc kernel: RDX: 0000118a083c713f RSI: 00000000281348c4 RDI: 0000000000000000
Apr 06 17:32:50 vd-pc kernel: RBP: ffff9f5584704c00 R08: 0000000000000002 R09: ffff9f587e72fd84
Apr 06 17:32:50 vd-pc kernel: R10: 0000000000000018 R11: 000000000000012e R12: ffffffffb8f4d5a0
Apr 06 17:32:50 vd-pc kernel: R13: 0000118a083c713f R14: 0000000000000002 R15: 0000000000000000
Apr 06 17:32:50 vd-pc kernel: ? cpuidle_enter_state+0xb7/0x360
Apr 06 17:32:50 vd-pc kernel: cpuidle_enter+0x29/0x40
Apr 06 17:32:50 vd-pc kernel: do_idle+0x1eb/0x280
Apr 06 17:32:50 vd-pc kernel: cpu_startup_entry+0x19/0x20
Apr 06 17:32:50 vd-pc kernel: secondary_startup_64_no_verify+0xc2/0xcb
Apr 06 17:32:50 vd-pc kernel: </TASK>
Apr 06 17:32:50 vd-pc kernel: ---[ end trace daabd078aca03e05 ]---
Apr 06 17:32:50 vd-pc kernel: r8152 2-1.3:1.0 enp4s0f3u1u3: Tx timeout
Apr 06 17:32:50 vd-pc kernel: r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -2
Apr 06 17:32:50 vd-pc kernel: r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -2
Apr 06 17:32:50 vd-pc kernel: r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -2
Apr 06 17:32:50 vd-pc kernel: r8152 2-1.3:1.0 enp4s0f3u1u3: Tx status -2
Apr 06 17:32:50 vd-pc kernel: usb 2-1.3: reset SuperSpeed USB device number 8 using xhci_hcd
Also I have this udev rule to be sure that auto-suspend is disabled.
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0bda", ATTR{idProduct}=="8153",
ATTR{product}=="USB 10/100/1000 LAN", TEST=="power/control",
ATTR{power/control}:="on"
Last edited by Vadosssss (2023-04-07 13:58:01)
Offline
You've iwd enabled and NM draws in wpa_supplicant.
While that doesn't affect the eth NIC directly, it'll make NM hyperactive.
In addition, you get 8h leases but renew every ~3h
So let's quiet this down and since you're using dhclient anyway, stop and disable NM and iwd, get a lease w/ dhclient directly and see how the system behaves on that.
The next step would be to get teh virtual devices out of the equation.
Fyi
Apr 06 12:12:28 vd-pc (udev-worker)[1800]: rx-0: /etc/udev/rules.d/10-dock-fix.rules:3 Failed to write ATTR{/sys/devices/virtual/net/ztwdjhqgzn/queues/rx-0/power/control}, ignoring: No such file or directory
Apr 06 12:12:28 vd-pc (udev-worker)[1799]: tx-0: /etc/udev/rules.d/10-dock-fix.rules:3 Failed to write ATTR{/sys/devices/virtual/net/ztwdjhqgzn/queues/tx-0/power/control}, ignoring: No such file or directory
Apr 06 12:13:40 vd-pc (udev-worker)[4544]: rx-0: /etc/udev/rules.d/10-dock-fix.rules:3 Failed to write ATTR{/sys/devices/virtual/net/tun0/queues/rx-0/power/control}, ignoring: No such file or directory
Apr 06 12:13:40 vd-pc (udev-worker)[4558]: tx-0: /etc/udev/rules.d/10-dock-fix.rules:3 Failed to write ATTR{/sys/devices/virtual/net/tun0/queues/tx-0/power/control}, ignoring: No such file or directory
Offline
So let's quiet this down and since you're using dhclient anyway, stop and disable NM and iwd, get a lease w/ dhclient directly and see how the system behaves on that.
Thanks! I disabled iwd and NM. I'll write later about the results.
Apr 06 12:12:28 vd-pc (udev-worker)[1800]: rx-0: /etc/udev/rules.d/10-dock-fix.rules:3 Failed to write ATTR{/sys/devices/virtual/net/ztwdjhqgzn/queues/rx-0/power/control}, ignoring: No such file or directory Apr 06 12:12:28 vd-pc (udev-worker)[1799]: tx-0: /etc/udev/rules.d/10-dock-fix.rules:3 Failed to write ATTR{/sys/devices/virtual/net/ztwdjhqgzn/queues/tx-0/power/control}, ignoring: No such file or directory Apr 06 12:13:40 vd-pc (udev-worker)[4544]: rx-0: /etc/udev/rules.d/10-dock-fix.rules:3 Failed to write ATTR{/sys/devices/virtual/net/tun0/queues/rx-0/power/control}, ignoring: No such file or directory Apr 06 12:13:40 vd-pc (udev-worker)[4558]: tx-0: /etc/udev/rules.d/10-dock-fix.rules:3 Failed to write ATTR{/sys/devices/virtual/net/tun0/queues/tx-0/power/control}, ignoring: No such file or directory
About virtual devices, as far as I remember, tun0 interface belongs to Pritunl VPN, and ztwdjhqgzn is in use for ZeroTier.
Offline
Yes, and there's also docker0 from, guess what, docker (same udev error, I guess that rule just runs over everything and tries to switch the power control?)
Offline
same udev error, I guess that rule just runs over everything and tries to switch the power control?
Maybe. I just faced the same error with using only dhclient. The new log is here: http://0x0.st/HX1A.txt
What will be the next steps? Get rid of virtual interfaces such as docker0, ztwdjhqgzn and tun0?
Offline
You could try to limit the dhclient interface (dhclient -4 enp4s0f3u1u3) and then remove the virtual interfaces.
The general approach is to simplify the setup until it either stabilizes or figure that even on a bare-bones system, the NIC will run into those errors.
Though google actually has this a lot, incl. https://bugzilla.kernel.org/show_bug.cgi?id=198931
Offline
You could try to limit the dhclient interface (dhclient -4 enp4s0f3u1u3) and then remove the virtual interfaces.
Done, the same result.
Also, I just reverted the installation of the r8152-dkms package since there are some fixes in vanilla kernel. Will keep looking.
Though google actually has this a lot, incl. https://bugzilla.kernel.org/show_bug.cgi?id=198931
Yep, I saw this too. Seems like there's no 100% fix for it.
Offline
I think I found a 100% fix for this issue.
I am running the Linux LTS kernel (tested with 6.1.57)
Install AUR package r8152-dkms
Run lsusb and note the what hardware ids show up when you plug in your USB dongle. I had three show up which will be used in usbquirks.conf.
Create a file in /etc/modprobe.d for example /etc/modprobe.d/usbquirks.conf with the following content:
options usbcore quirks=2357:0601:bjkm,0bda:0411:bjkm,0bda:5411:bjkm
You need to replace the 8 digit hardware ids with your specific hardware which shows up in lsusb as described above.
I also added these before to tlp.conf (I run tlp) to USB_DENYLIST but it had no effect. You have to use the modprobe.d file method described above. You also don't need to edit your kernel command line. Just edit the file in modprobe.d.
Don't forget to reboot. I stress tested this configuration by repeatedly running Internet speed tests while simultaneously writing to one of three USB ports on my multi-port USB device: "TP-Link USB 3.0 to Ethernet Adapter, Portable 3-port USB Hub with 1 Gigabit RJ45 Ethernet Port Laptop Network Adapter, Supports Win 7/8/8.1/10, Mac OS X (10.6-10.14), Linux OS and Chrome OS" I bought on Amazon: https://www.amazon.com/dp/B01N9M32TA
Last edited by agradzki (2023-10-12 14:48:23)
Offline
https://raw.githubusercontent.com/torva … meters.txt
b = USB_QUIRK_RESET_RESUME (device can't resume correctly so reset it instead);
j = USB_QUIRK_IGNORE_REMOTE_WAKEUP (device generates spurious wakeup, ignore remote wakeup capability);
k = USB_QUIRK_NO_LPM (device can't handle Link Power Management);
m = USB_QUIRK_DISCONNECT_SUSPEND (Device needs to be disconnected before suspend to prevent spurious wakeup);
Is this S3 related? Otherwise "k" being the relevant quirk? "b"?
Offline
The issue arises on a fresh boot prior to S3. It is unclear whether S3 causes problems. I added that quirk out of an abundance of caution; it may not be necessary.
Offline
Additional problems can also be mitigated by unplugging the ethernet cable, then plugging the adapter into the USB port. Only plug the ethernet cable in after the adapter has been plugged into the USB port.
Offline
Small update: The disconnection problems remain. Suspending the computer just once makes the problems much worse afterwards.
r8152-cfgselector 2-2.4: Failed to set U1 timeout to 0x0,error code -19
r8152-cfgselector 2-2.4: Failed to set U1 timeout to 0xff,error code -19
cdc_ether 2-2.4:2.0: usb_probe_interface Failed to disable LPM for driver cdc_ether
cdc_ether: probe of 2-2.4:2.0 failed with error -16
r8152 2-2.4:2.0: usb_probe_interface Failed to disable LPM for driver r8152
r8152-cfgselector 2-2.4: reset SuperSpeed USB device number 28 using xhci_hcd
r8152 2-2.4:1.0 (unnamed net_device) (uninitialized): get_registers -71
r8152-cfgselector 2-2.4: reset SuperSpeed USB device number 30 using xhci_hcd
r8152 2-2.4:1.0 (unnamed net_device) (uninitialized): get_registers -110
r8152 2-2.4:1.0 (unnamed net_device) (uninitialized): get_registers -71
r8152 2-2.4:1.0 eth0: v2.17.1 (2023/06/13)
> uname -a
Linux x1c6 6.1.62-1-lts #1 SMP PREEMPT_DYNAMIC Thu, 09 Nov 2023 17:21:17 +0000 x86_64 GNU/Linux
Last edited by agradzki (2023-11-13 16:42:12)
Offline
try to disable "SG"
ethtool -K INSERT_NAME_OF_DEVICE_HERE sg off
Offline
Replying to this old thread since it's one of the top search results for this issue.
I have the same issue and it's because the adapter overheats. The only way to get it work is either turning off hardware acceleration using ethtool and limiting the connection speed to 100 Mbit, or adding an additional fan. I live in a very warm country, but the adapter gets extremely hot (burn your finger hot), so I wouldn't be surprised if temperature is the main cause for this issue.
Offline
Pages: 1