Bug 212731

Summary:	USB Ethernet adapter ASIX AX88179 disconnects under heavy load.
Product:	Networking	Reporter:	Alex (kozyavk)
Component:	Other	Assignee:	Stephen Hemminger (stephen)
Status:	NEW ---
Severity:	normal	CC:	a.kambas, adam, anders.collstrup, bjorn.forsman, ceticamarco, christian.rohmann, francesco, ger, huan, jakub.gargul+krn, kernelbugzilla, kevin.buckley.pawsey.org.au, msylwester, tlinux, yanmercier
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	5.11.13	Subsystem:
Regression:	No	Bisected commit-id:

Description Alex 2021-04-20 02:24:51 UTC

Hi!

I bought three USB3.0-Ethernet adapters (AX88179) on Aliexpress in attempt to make three small arm servers from scavenged tablets.

Two of the tablets are Allwinnwer A10 based and one is based on Amlogic 8726-MX.
For A10 tablets I compiled the latest mainline kernel (5.11.13). For Amlogic I compiled kernel sources which they provided in 2014 (3.10.10). All boards have Ubuntu 20.04 rootfs.
I tried ax88179 driver included in kernel, I also tested the latest driver from ASIX web site. All possible combinations of these boards, kernels and drivers have similar problem:

When I install and run transmission-daemon to download some torrents - network connection between tablet and external devices disappears (Transmission loses connection too). From inside of tablet I can ping ASIX adapter's IP, but I can't ping router or any Internet address. I can't ping tablet from outside.
Adapter's LINK LED in ON and even ACT LED is blinking but there is no actual connection.
There are no (relevant) error messages in syslog or dmesg.

I tried to disable green ethernet etc - didn't help (options ax88179_178a bEEE=0 bGETH=0).
I tried to find some buffers I could increase or some options like ethernet flow control that could possibly help me, but ethtool refuses to set any of them which is strange, because all those options are available in driver for Windows OS.

I also tried to provide separate power supply for the adapter, add more capacitors to stabilize adapter's power supply, used different USB ports and external hubs, different ethernet cables... it changed nothing.

When systemd-networkd is used to manage network, the connectivity of dead adapter usually could be restored by replugging ethernet cable. I can see "link state is 0 link state is 1" in syslog
The connectivity can also be restored by running
ip link set dev usbnet0 down
ip link set dev usbnet0 up

The amount of time between the launch of Transmission and network disappearance is usually less than 5 minutes on download speed about 20-40Mbps ( 3 files, 10 peers each). If download speed is limited in Transmission's config to less than 10Mbps - the time before network disappearance can be much larger but the device could stay online for 5 hours and then have dozen of disconnects during the sixth hour. So this timeout is unsteady.

I also made a test on DELL Latitude 3490 laptop with latest KDE Neon installed (I think it has Ubuntu's x86_64 kernel as is). The problem with adapter remains on conventional laptop too. After a few minutes of downloading the message appears "Limited connection. The adapter appears to be connected to network but Internet in unreachable" - something like that.

Then I connected my laptop to my network provider directly (bypassing router) - the problem remained.

So the problem is not in my switch/router or my old ARM boards. It is either adapter itself or something in the software.

And finally, I made two tests on the same laptop running Windows 10. I used uTorrent instead of Transmission but with the same heavy load.
The adapter works flawlessly on Windows under any load. At least during 24 hours.

So, I think there is some problem with driver for AX88179 devices.
I hope actually, that the problem is just in the size of some buffers in USB or TCP/IP stack, but I have no clue what could it be.
I use some tuning of TCP/IP for higher network load on my other device:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.udp_mem = 8388608 12582912 16777216
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 65536 8388608

but it doesn't help me with ASIX.

Comment 1 Alex 2021-04-20 02:36:28 UTC

I should add - when I found that the latest stable kernel doesn't work for me I tried two other longterm kernels - 5.10 and 5.4
The problem was there too.

Comment 2 christian.rohmann 2022-02-04 08:39:08 UTC

I observed a similar issue of random losses of traffic handling on Kernel 5.16.4-arch1-1 with a 
  Bus 007 Device 009: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet 

which is part of an
  Anker PowerExpand 8-in-1 USB-C PD 10Gbps Data Hub

reporting in with
  Bus 006 Device 012: ID 291a:8383 Anker Anker USB-C HUB Device



If I unplug the RJ45 and plug it back it the link works fine again.

Comment 3 christian.rohmann 2022-02-24 15:03:34 UTC

There have been some changes committed for 5.17 ... see https://github.com/torvalds/linux/commit/57bc3d3ae8c14df3ceb4e17d26ddf9eeab304581

Comment 4 Francesco Lovergine 2022-05-11 07:45:38 UTC

Hi, I can confirm this problem with 5.10.106 (Debian 11). 
It seems due to some random pattern and generally the device disconnects when using Skype in a few seconds (WTF?). But for that, the disconnection happens randomly even not under heavy load.

Typically a message such as:

[mer mag 11 08:45:29 2022] ax88179_178a 4-6:1.0 enxf8e43b8c0541: Failed to read reg index 0x0040: -32

appears and the link is permanently lost. It can be enabled again by issuing:

ip link set dev <device> down && ip link set dev <device> up

Sometimes a kernel panic appears too:




[ven mag  6 15:09:05 2022] ------------[ cut here ]------------
[ven mag  6 15:09:05 2022] NETDEV WATCHDOG: enxf8e43b8c0541 (ax88179_178a): transmit queue 0 timed out
[ven mag  6 15:09:05 2022] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:467 dev_watchdog+0x25c/0x260
[ven mag  6 15:09:05 2022] Modules linked in: tun nf_log_ipv4 nf_log_common nft_limit xt_LOG xt_limit xt_multiport xt_MASQUERADE xt_REDIRECT nft_chain_nat xt_nat nf_nat xt_tcpudp ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defr
ag_ipv6 nf_defrag_ipv4 nft_compat nft_counter nf_tables nfnetlink intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek kvm_intel binfmt_misc snd_hda_codec_generic ledtrig_audio kvm snd_hda_
codec_hdmi snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation irqbypass snd_soc_core snd_compress soundwire_cadence ghash_clmulni_intel mei_hdcp mei_wdt snd_hda_codec aesni_intel snd_hda_core libaes crypto_simd sn
d_hwdep iTCO_wdt cryptd soundwire_bus glue_helper rtsx_usb_ms snd_pcm_oss rapl ax88179_178a intel_pmc_bxt intel_cstate memstick snd_mixer_oss snd_pcm iTCO_vendor_support usbnet mei_me intel_uncore mii joydev pcspkr at24 snd_timer mei sg w
atchdog snd soundcore intel_pch_thermal fujitsu_laptop
[ven mag  6 15:09:05 2022]  sparse_keymap evdev loop parport_pc ppdev auth_rpcgss lp parport fuse sunrpc configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async
_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod hid_logitech_hidpp hid_logitech_dj hid_generic rtsx_usb_sdmmc mmc_core usbhid hid rtsx_usb i915 sd_mod t10_pi crc_t10dif crct10dif_generic i2
c_algo_bit drm_kms_helper ahci libahci cec xhci_pci libata xhci_hcd drm ehci_pci crct10dif_pclmul crct10dif_common ehci_hcd e1000e crc32_pclmul scsi_mod lpc_ich crc32c_intel i2c_i801 i2c_smbus usbcore ptp pps_core usb_common fan wmi video
 button
[ven mag  6 15:09:05 2022] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.10.0-14-amd64 #1 Debian 5.10.113-1
[ven mag  6 15:09:05 2022] Hardware name: FUJITSU ESPRIMO Q920/D3233-A1, BIOS V4.6.5.4 R1.46.0.SR.1 for D3233-A1x 09/21/2018
[ven mag  6 15:09:05 2022] RIP: 0010:dev_watchdog+0x25c/0x260
[ven mag  6 15:09:05 2022] Code: eb a9 48 8b 1c 24 c6 05 7f 53 10 01 01 48 89 df e8 99 97 fa ff 44 89 e9 48 89 de 48 c7 c7 70 c0 76 b4 48 89 c2 e8 12 3d 14 00 <0f> 0b eb 86 0f 1f 44 00 00 41 57 41 56 49 89 d6 41 55 4d 89 c5 41
[ven mag  6 15:09:05 2022] RSP: 0018:ffffb6fe000e0eb0 EFLAGS: 00010282
[ven mag  6 15:09:05 2022] RAX: 0000000000000000 RBX: ffff8da519f4c000 RCX: 000000000000083f
[ven mag  6 15:09:05 2022] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f
[ven mag  6 15:09:05 2022] RBP: ffff8da519f4c3dc R08: 0000000000000000 R09: ffffb6fe000e0cd0
[ven mag  6 15:09:05 2022] R10: ffffb6fe000e0cc8 R11: ffffffffb4ccb408 R12: ffff8da50648a280
[ven mag  6 15:09:05 2022] R13: 0000000000000000 R14: ffff8da519f4c480 R15: 0000000000000001
[ven mag  6 15:09:05 2022] FS:  0000000000000000(0000) GS:ffff8da616280000(0000) knlGS:0000000000000000
[ven mag  6 15:09:05 2022] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ven mag  6 15:09:05 2022] CR2: 000055e2b8a6d0a0 CR3: 0000000182c0a004 CR4: 00000000001706e0
[ven mag  6 15:09:05 2022] Call Trace:
[ven mag  6 15:09:05 2022]  <IRQ>
[ven mag  6 15:09:05 2022]  ? pfifo_fast_enqueue+0x150/0x150
[ven mag  6 15:09:05 2022]  call_timer_fn+0x29/0xf0
[ven mag  6 15:09:05 2022]  __run_timers.part.0+0x1d5/0x250
[ven mag  6 15:09:05 2022]  ? recalibrate_cpu_khz+0x10/0x10
[ven mag  6 15:09:05 2022]  ? ktime_get+0x38/0xa0
[ven mag  6 15:09:05 2022]  ? lapic_next_deadline+0x28/0x30
[ven mag  6 15:09:05 2022]  ? clockevents_program_event+0x8d/0xf0
[ven mag  6 15:09:05 2022]  run_timer_softirq+0x26/0x50
[ven mag  6 15:09:05 2022]  __do_softirq+0xc5/0x275
[ven mag  6 15:09:05 2022]  asm_call_irq_on_stack+0x12/0x20
[ven mag  6 15:09:05 2022]  </IRQ>
[ven mag  6 15:09:05 2022]  do_softirq_own_stack+0x37/0x40
[ven mag  6 15:09:05 2022]  irq_exit_rcu+0x8e/0xc0
[ven mag  6 15:09:05 2022]  sysvec_apic_timer_interrupt+0x36/0x80
[ven mag  6 15:09:05 2022]  asm_sysvec_apic_timer_interrupt+0x12/0x20
[ven mag  6 15:09:05 2022] RIP: 0010:cpuidle_enter_state+0xc7/0x350
[ven mag  6 15:09:05 2022] Code: 8b 3d ed 17 37 4c e8 f8 cc a1 ff 49 89 c5 0f 1f 44 00 00 31 ff e8 09 d8 a1 ff 45 84 ff 0f 85 fa 00 00 00 fb 66 0f 1f 44 00 00 <45> 85 f6 0f 88 06 01 00 00 49 63 c6 4c 2b 2c 24 48 8d 14 40 48 8d
[ven mag  6 15:09:05 2022] RSP: 0018:ffffb6fe0009bea8 EFLAGS: 00000246
[ven mag  6 15:09:05 2022] RAX: ffff8da6162afcc0 RBX: 0000000000000005 RCX: 000000000000001f
[ven mag  6 15:09:05 2022] RDX: 0000000000000000 RSI: 0000000040260673 RDI: 0000000000000000
[ven mag  6 15:09:05 2022] RBP: ffff8da6162b9500 R08: 000015e3d49b3927 R09: 000015e3bc46d468
[ven mag  6 15:09:05 2022] R10: 00000000000011ac R11: 00000000000015d9 R12: ffffffffb4dae780
[ven mag  6 15:09:05 2022] R13: 000015e3d49b3927 R14: 0000000000000005 R15: 0000000000000000
[ven mag  6 15:09:05 2022]  ? cpuidle_enter_state+0xb7/0x350
[ven mag  6 15:09:05 2022]  cpuidle_enter+0x29/0x40
[ven mag  6 15:09:05 2022]  do_idle+0x1ef/0x2b0
[ven mag  6 15:09:05 2022]  cpu_startup_entry+0x19/0x20
[ven mag  6 15:09:05 2022]  secondary_startup_64_no_verify+0xb0/0xbb
[ven mag  6 15:09:05 2022] ---[ end trace 17d8be5b9f9a838a ]---

I'm available for some debugging session to find out what seems a driver bug.

Cheers.

Comment 5 Francesco Lovergine 2022-05-11 07:53:06 UTC

For completeness, note that when the disconnection happens the status leds turn off too.

Comment 6 yan 2022-06-12 07:47:21 UTC

I experience this issue as well, but there is a nuance in my experience compared to what Ive read above; with kernel 5.4.0-113-generic it happens less frequently than with kernel 5.15.0-33-generic.

with 5.4 I get this in kern.log, the link comes back up by itself a second after :
kernel: [  761.308784] ax88179_178a 4-2:1.0 enx7cc2c635515e: unregister 'ax88179_178a' usb-0000:00:14.0-2, ASIX AX88179 USB 3.0 Gigabit Ethernet
kernel: [  761.308852] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0002: -19
kernel: [  761.308856] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to write reg index 0x0002: -19
kernel: [  761.348397] ax88179_178a 4-2:1.0 enx7cc2c635515e (unregistered): Failed to write reg index 0x0002: -19
kernel: [  761.348399] ax88179_178a 4-2:1.0 enx7cc2c635515e (unregistered): Failed to write reg index 0x0001: -19
kernel: [  761.348399] ax88179_178a 4-2:1.0 enx7cc2c635515e (unregistered): Failed to write reg index 0x0002: -19
kernel: [  761.977682] ax88179_178a 4-2:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-2, ASIX AX88179 USB 3.0 Gigabit Ethernet, 7c:c2:c6:35:51:5e
kernel: [  761.992305] ax88179_178a 4-2:1.0 enx7cc2c635515e: renamed from eth0
kernel: [  762.483439] ax88179_178a 4-2:1.0 enx7cc2c635515e: ax88179 - Link status is: 1
kernel: [  764.915376] ax88179_178a 4-2:1.0 enx7cc2c635515e: ax88179 - Link status is: 1


with 5.15 when I generate some network traffic, it will constantly go down/up with more log entries :
kernel: [14889.794566] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0000: -19
kernel: [14889.794581] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0001: -19
kernel: [14889.794588] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0009: -19
kernel: [14889.794594] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x000a: -19
kernel: [14889.794600] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0004: -19
kernel: [14889.794638] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0000: -19
kernel: [14889.794646] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0001: -19
kernel: [14889.794652] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0009: -19
kernel: [14889.794659] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x000a: -19
kernel: [14889.794664] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0004: -19
kernel: [14889.867328] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0000: -19
kernel: [14889.867335] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0001: -19
kernel: [14889.867336] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0009: -19
kernel: [14889.867338] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x000a: -19
kernel: [14889.867339] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0004: -19
kernel: [14889.867345] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0000: -19
kernel: [14889.867348] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0001: -19
kernel: [14889.867350] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0009: -19
kernel: [14889.867351] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x000a: -19
kernel: [14889.867353] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0004: -19
kernel: [14889.867355] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0000: -19
kernel: [14889.867357] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0001: -19
kernel: [14889.867359] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0009: -19
kernel: [14889.867360] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x000a: -19
kernel: [14889.867362] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0004: -19
kernel: [14889.867365] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0000: -19
kernel: [14889.867366] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0001: -19
kernel: [14889.867368] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0009: -19
kernel: [14889.867369] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x000a: -19
kernel: [14889.867370] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0004: -19
kernel: [14889.931192] usb 4-2: USB disconnect, device number 27
kernel: [14889.931351] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
kernel: [14889.931494] ax88179_178a 4-2:1.0 enx7cc2c635515e: unregister 'ax88179_178a' usb-0000:00:14.0-2, ASIX AX88179 USB 3.0 Gigabit Ethernet
kernel: [14889.931504] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to write reg index 0x0002: -19
kernel: [14889.931508] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to write reg index 0x0001: -19
kernel: [14889.931512] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to write reg index 0x0002: -19
kernel: [14889.931562] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to read reg index 0x0002: -19
kernel: [14889.931565] ax88179_178a 4-2:1.0 enx7cc2c635515e: Failed to write reg index 0x0002: -19
kernel: [14890.231400] usb 4-2: new SuperSpeed USB device number 28 using xhci_hcd
kernel: [14890.254695] usb 4-2: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 1.00
kernel: [14890.254706] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: [14890.254710] usb 4-2: Product: AX88179
kernel: [14890.254712] usb 4-2: Manufacturer: ASIX Elec. Corp.
kernel: [14890.254715] usb 4-2: SerialNumber: 007CC2C635515E
kernel: [14890.597289] ax88179_178a 4-2:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-2, ASIX AX88179 USB 3.0 Gigabit Ethernet, 7c:c2:c6:35:51:5e
kernel: [14890.610171] ax88179_178a 4-2:1.0 enx7cc2c635515e: renamed from eth0
kernel: [14891.024391] ax88179_178a 4-2:1.0 enx7cc2c635515e: ax88179 - Link status is: 1
kernel: [14893.584304] ax88179_178a 4-2:1.0 enx7cc2c635515e: ax88179 - Link status is: 1

kernel: [14893.627579] ax88179_178a 4-2:1.0 enx7cc2c635515e: Error submitting the control message: status=-19
kernel: [14893.627585] ax88179_178a 4-2:1.0 enx7cc2c635515e: Error submitting the control message: status=-19

Comment 7 Jakub 2022-06-24 14:56:59 UTC

It is observable on 5.17.11 and doesn't look related to running a heavy load, it seems to happen in time intervals that vary between devices. I tested 2 adapters, one tended to disconnect every few hours, the other one disconnects once in a day.

Also, device has a problem coming back up after it disconnects and toggles a bit:

[100037.225952] usb 4-1: USB disconnect, device number 2
[100037.226439] ax88179_178a 4-1:1.0 enxf8e43b80d139: unregister 'ax88179_178a' usb-0000:00:14.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet
[100037.226450] ax88179_178a 4-1:1.0 enxf8e43b80d139: Failed to write reg index 0x0002: -19
[100037.226455] ax88179_178a 4-1:1.0 enxf8e43b80d139: Failed to write reg index 0x0001: -19
[100037.226458] ax88179_178a 4-1:1.0 enxf8e43b80d139: Failed to write reg index 0x0002: -19
[100037.226510] ax88179_178a 4-1:1.0 enxf8e43b80d139: Failed to read reg index 0x0002: -19
[100037.226513] ax88179_178a 4-1:1.0 enxf8e43b80d139: Failed to write reg index 0x0002: -19
[100037.531496] usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd
[100037.703722] usb 4-1: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 2.00
[100037.703726] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[100037.703727] usb 4-1: Product: AX88179A
[100037.703728] usb 4-1: Manufacturer: ASIX
[100037.703728] usb 4-1: SerialNumber: 0080D139
[100038.394197] ax88179_178a 4-1:1.0 (unnamed net_device) (uninitialized): Failed to read reg index 0x0040: -32
[100038.704714] ax88179_178a 4-1:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, f8:e4:3b:80:d1:39
[100038.773929] ax88179_178a 4-1:1.0 enxf8e43b80d139: renamed from eth0
[100039.396235] ax88179_178a 4-1:1.0 enxf8e43b80d139: Failed to read reg index 0x0040: -32
[100042.822300] ax88179_178a 4-1:1.0 enxf8e43b80d139: ax88179 - Link status is: 1
[100043.023352] IPv6: ADDRCONF(NETDEV_CHANGE): enxf8e43b80d139: link becomes ready
[100043.462257] ax88179_178a 4-1:1.0 enxf8e43b80d139: ax88179 - Link status is: 0
[100047.174276] ax88179_178a 4-1:1.0 enxf8e43b80d139: ax88179 - Link status is: 1
[100047.814228] ax88179_178a 4-1:1.0 enxf8e43b80d139: ax88179 - Link status is: 0
[100051.722093] usb 4-1: USB disconnect, device number 3
[100051.722398] ax88179_178a 4-1:1.0 enxf8e43b80d139: unregister 'ax88179_178a' usb-0000:00:14.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet
[100051.722411] ax88179_178a 4-1:1.0 enxf8e43b80d139: Failed to write reg index 0x0002: -19
[100051.722416] ax88179_178a 4-1:1.0 enxf8e43b80d139: Failed to write reg index 0x0001: -19
[100051.722419] ax88179_178a 4-1:1.0 enxf8e43b80d139: Failed to write reg index 0x0002: -19
[100051.722474] ax88179_178a 4-1:1.0 enxf8e43b80d139: Failed to read reg index 0x0002: -19
[100051.722478] ax88179_178a 4-1:1.0 enxf8e43b80d139: Failed to write reg index 0x0002: -19
[100052.039253] usb 4-1: new SuperSpeed USB device number 4 using xhci_hcd
[100052.212508] usb 4-1: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 2.00
[100052.212520] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[100052.212524] usb 4-1: Product: AX88179A
[100052.212527] usb 4-1: Manufacturer: ASIX
[100052.212530] usb 4-1: SerialNumber: 0080D139
[100052.900188] ax88179_178a 4-1:1.0 (unnamed net_device) (uninitialized): Failed to read reg index 0x0040: -32
[100053.212308] ax88179_178a 4-1:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, f8:e4:3b:80:d1:39
[100053.262050] ax88179_178a 4-1:1.0 enxf8e43b80d139: renamed from eth0
[100053.911274] ax88179_178a 4-1:1.0 enxf8e43b80d139: Failed to read reg index 0x0040: -32
[100057.286499] ax88179_178a 4-1:1.0 enxf8e43b80d139: ax88179 - Link status is: 1
[100057.485854] IPv6: ADDRCONF(NETDEV_CHANGE): enxf8e43b80d139: link becomes ready
[100057.926160] ax88179_178a 4-1:1.0 enxf8e43b80d139: ax88179 - Link status is: 0
[100061.638255] ax88179_178a 4-1:1.0 enxf8e43b80d139: ax88179 - Link status is: 1
[100062.278259] ax88179_178a 4-1:1.0 enxf8e43b80d139: ax88179 - Link status is: 0
[100065.990274] ax88179_178a 4-1:1.0 enxf8e43b80d139: ax88179 - Link status is: 1
[100066.502252] ax88179_178a 4-1:1.0 enxf8e43b80d139: ax88179 - Link status is: 0
[100069.958248] ax88179_178a 4-1:1.0 enxf8e43b80d139: ax88179 - Link status is: 1

Comment 8 Ger 2022-08-10 07:01:23 UTC

I too have the exact same issue on kernel 5.18.16-arch1-1. It seems loosely related to network load as it craps out even when lightly browsing, but consistently when I put some load on it. The same device on Windows 11 keeps chugging along even under load, so it is likely the driver at fault. 

Since I can get the device to stop working pretty consistently and within seconds, I might be able to debug this and hack on it a bit. But I could use some pointers as to how to go about this.

Comment 9 christian.rohmann 2022-08-10 09:58:12 UTC

Yes Ger, I observe the same issue (also running Arch).

I found https://github.com/nothingstopsme/AX88179_178A_Linux_Driver which seems to contains quite a few fixes for the instabilities. Unfortunately it does not compile against 5.16 or even 5.18 kernels and the the author did not yet respond to my issue about getting his fixes upstream into the kernel - see https://github.com/nothingstopsme/AX88179_178A_Linux_Driver/issues/1

Comment 10 Huan Zhang 2022-09-19 22:54:07 UTC

The latest ax_usb_nic driver seems to solve the stability issue for me. I was able to run the adapter a few days without disconnections, and it also does not crash under heavy load (iperf3 bidirectional test).

The new driver can be downloaded at https://www.asix.com.tw/en/support/download 
Choose AX88179A (not AX88179) when you download the driver, and the version I downloaded was v1.0.0 release on 2022-07-26 (ASIX_USB_NIC_Linux_Driver_Source_v1.0.0_20220726.tar.bz2). The driver is intended for the newer AX88179A chip but it also works for the older AX88179 chip. I can directly compile it on kernel 5.15 (Ubuntu 22.04) without any additional modification. The compiled driver ax_usb_nic.ko works much better in terms of stability compared to the older ax88179_178a driver.

One minor issue with the newer ax_usb_nic driver is that it does not support jumbo frames due to a minor bug. It can be easily fixed by adding a line "axdev->netdev->max_mtu = 4088;" to ax88179_bind() in ax88179_178a.c and then you can use MTU up to 4088.

Comment 11 Alex Kampas 2022-10-03 17:48:24 UTC

I can confirm this problem is still present.

I'm on Fedora 5.19.11-300.fc37.x86_64 but the issue persists on the same kernel in F36 and the 5.19 version of Pop_OS. 

I have previously tried all kernels from 5.15 and up of these two distributions, as well as the current 5.15 on Ubuntu.

The problem persists:

~~~
Oct 03 10:51:19 kepler kernel: ax88179_178a 2-2.2:2.0 (unnamed net_device) (uninitialized): Failed to write reg index 0x0002: -32
.
.
.
Oct 03 10:51:22 kepler kernel: ax88179_178a 2-2.2:2.0 enp0s20f0u2u2c2: Failed to write reg index 0x001f: -32
.
.
.
Oct 03 10:51:23 kepler kernel: ax88179_178a 2-2.2:2.0 enp0s20f0u2u2c2: unregister 'ax88179_178a' usb-0000:00:14.0-2.2, ASIX AX88179 USB 3.0 Gigabit Ethernet
Oct 03 10:51:23 kepler kernel: ax88179_178a 2-2.2:2.0 enp0s20f0u2u2c2: Failed to read reg index 0x0002: -19
Oct 03 10:51:23 kepler kernel: ax88179_178a 2-2.2:2.0 enp0s20f0u2u2c2: Failed to write reg index 0x0002: -19
Oct 03 10:51:23 kepler kernel: ax88179_178a 2-2.2:2.0 enp0s20f0u2u2c2 (unregistered): Failed to write reg index 0x0002: -19
.
.
.
~~~

I tried to compile the driver linked by Huan Zhang [here](https://bugzilla.kernel.org/show_bug.cgi?id=212731#c10), but it wouldn't compile and I looked elsewhere.

I came across this: https://github.com/nothingstopsme/AX88179_178A_Linux_Driver

This compiles perfectly, (make, sudo makeinstall) and after a reboot, the ethernet works fine.

Can't we just have that driver in the kernel?

Thanks.

Comment 12 Marco 2023-01-16 09:30:44 UTC

Can confirm that this issue is still present on Arch Linux 5.15.87-1-lts to this day. 


[  596.602123] ax88179_178a 2-2.2:1.0 enp0s20f0u2u2: ax88179 - Link status is: 0
[  602.878181] audit: type=1130 audit(1673860732.636:323): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[  608.122090] ax88179_178a 2-2.2:1.0 enp0s20f0u2u2: ax88179 - Link status is: 1
[  612.945112] audit: type=1131 audit(1673860742.706:324): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Comment 13 Alex Kampas 2023-01-16 21:35:52 UTC

OP here, and I can say that since kernel 5.18 the ASIX chip works fine out of the box.

Comment 14 Alex 2023-01-18 23:11:19 UTC

Hey! It's me the OP! :D
But I didn't check the situation with ASIX for a long time and my adapters lie buried somewhere in cardboard boxes...

Comment 15 Ben Tasker 2023-03-25 17:54:30 UTC

This issue is still present on Ubuntu 5.19.0-35-generic

[Fri Mar 24 10:21:15 2023] ax88179_178a 2-1.4:2.0 (unnamed net_device) (uninitialized): Failed to write reg index 0x0006: -32
[Fri Mar 24 10:21:15 2023] ax88179_178a 2-1.4:2.0 (unnamed net_device) (uninitialized): Failed to write reg index 0x0005: -32


Switching to the driver at https://github.com/nothingstopsme/AX88179_178A_Linux_Driver resolved the issue for me

Comment 16 Kevin Buckley 2023-06-26 02:29:35 UTC

I saw this on a system with an Ubuntu 5.19.0-45-generic kernel.

As well as finding this thread, I have also seen that there is 
a fix for this issue mentioned here:

   https://github.com/FreddyXin/ax88179_178a/issues/6

which suggests a module loading order being the cause.

The "running" fix there is

rmmod ax88179_178a
modprobe cdc_mbim

and that, and a replug of the adaptor worked for me.

A "permanent" fix given there was

echo "softdep ax88179_178a pre: cdc_mbim" > \
  /etc/modprobe.d/ax88179_178a-fix.conf

Comment 17 Francesco Lovergine 2023-06-26 07:10:19 UTC

Note that this is issue appears fixed in 6.0+, I'm successfully using it without issues under Debian 11 with 6.0 and Debian 12 with 6.1.

Comment 18 bjorn.forsman 2023-06-26 07:38:42 UTC

(In reply to Francesco Lovergine from comment #17)
> Note that this is issue appears fixed in 6.0+, I'm successfully using it
> without issues under Debian 11 with 6.0 and Debian 12 with 6.1.

I'm on Linux 6.1.31 (NixOS 23.05) and still see the disconnects, about once a day for the last week. That's not even with heavy load. Prior to that version I was on 5.15.x and also had similar random disconnects.

Comment 19 Francesco Lovergine 2023-06-26 08:23:31 UTC

For what it's worth, the running module under 6.1 is now cdc_ether and it works at least with an adapter like:

~~~
Bus 004 Device 002: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet

Comment 20 bjorn.forsman 2023-06-26 10:48:15 UTC

(In reply to Francesco Lovergine from comment #19)
> For what it's worth, the running module under 6.1 is now cdc_ether and it
> works at least with an adapter like:
> 
> ~~~
> Bus 004 Device 002: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit
> Ethernet

Weird. I have the same VID:PID but the active driver isn't cdc_ether, its ax88179_178a:

$ ls -l /sys/class/net/enp0s20u2/device/driver/module
lrwxrwxrwx 1 root root 0 Jun 26 12:44 /sys/class/net/enp0s20u2/device/driver/module -> ../../../../module/ax88179_178a

Comment 21 bjorn.forsman 2023-07-01 08:49:02 UTC

(In reply to Kevin Buckley from comment #16)
> A "permanent" fix given there was
> 
> echo "softdep ax88179_178a pre: cdc_mbim" > \
>   /etc/modprobe.d/ax88179_178a-fix.conf

I can confirm that it works: I've been running with it for 5 days without any USB disconnects.

Unless anyone has a better idea for a fix, how about applying this patch to Linux?

diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index aff39bf3161d..20ff733c498a 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1915,3 +1915,4 @@ module_usb_driver(ax88179_178a_driver);
 
 MODULE_DESCRIPTION("ASIX AX88179/178A based USB 3.0/2.0 Gigabit Ethernet Devices");
 MODULE_LICENSE("GPL");
+MODULE_SOFTDEP("pre: cdc_mbim");

Comment 22 bjorn.forsman 2023-07-01 08:52:17 UTC

(In reply to bjorn.forsman from comment #21)
> (In reply to Kevin Buckley from comment #16)
> > A "permanent" fix given there was
> > 
> > echo "softdep ax88179_178a pre: cdc_mbim" > \
> >   /etc/modprobe.d/ax88179_178a-fix.conf
> 
> I can confirm that it works: I've been running with it for 5 days without
> any USB disconnects.

Talk about funny timing: After I send that message, I go back to debug some more and find that I got an "USB disconnect" while I was posting.