Hello everybody. Currently I'm running Openwrt on Raspberry and have tried a lot of different Openwrt builds. Constant problem with USB lan Asix 88179. I need your advice. thank you very much...
- Raspberry Pi 4B- MicroSD Kingston 32GB Class 10
- Power 3A for Raspberry and Power 3A for Hub USB 3.0
- 2 Ugreen 50922 USB 3.0 Gigalan Asix AX88179 10/100/1000
- OpenWrt SNAPSHOT r18269-c47e82d255 Linux 5.10.82
- I have tested from Linux version 5.4 to 5.10 all get the USB WAN error Asix AX88179. (Tested on 2 USB Lan Realtek r8152 runs relatively well, no problem)
- When used for a period of 2.3 hours, the 2 usb Asix AX88179 automatically failed to connect to the wan and had problems. If I restart Openwrt, the connection is normal. (If tested with App Speedtest or website Speedtest, tested about 2.3 times, these 2 USBs suddenly died for no reason)
Does anyone know how to fix this on Openwrt? I suspect due to Asix AX88179 USB. Thank you!
(Power supply is excluded because I have tested various 3A power sources)
[ 186.063289] ------------[ cut here ]------------
[ 186.070262] NETDEV WATCHDOG: eth2 (ax88179_178a): transmit queue 0 timed out
[ 186.079744] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:467 dev_watchdo g+0x2b0/0x2c0
[ 186.090477] Modules linked in: pppoe ppp_async iptable_nat brcmfmac xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_gen eric nf_nat nf_flow_table nf_conntrack ipt_REJECT cfg80211 ax88179_178a xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG usbne t usbhid slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_m angle iptable_filter ip_tables hid_generic crc_ccitt compat brcmutil snd_bcm2835 (C) hid evdev nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tabl es ip6t_REJECT x_tables nf_reject_ipv6 snd_rawmidi snd_seq_device snd_pcm_oss sn d_pcm_dmaengine snd_mixer_oss snd_hwdep snd_compress snd_pcm snd_timer snd sound core nls_utf8 vfat fat nls_iso8859_1 nls_cp437
[ 186.172815] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C 5.10.82 #0
[ 186.182825] Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
[ 186.191200] pstate: 40400005 (nZcv daif +PAN -UAO -TCO BTYPE=--)
[ 186.199756] pc : dev_watchdog+0x2b0/0x2c0
[ 186.206241] lr : dev_watchdog+0x2b0/0x2c0
[ 186.212676] sp : ffffffc010b8bd70
[ 186.218341] x29: ffffffc010b8bd70 x28: ffffffc010b2a000
[ 186.225950] x27: 0000000000000140 x26: 00000000ffffffff
[ 186.233505] x25: 0000000000000000 x24: 0000000000000000
[ 186.240976] x23: ffffff8041d90480 x22: 0000000000000001
[ 186.248433] x21: ffffffc010a16000 x20: ffffff8041d90000
[ 186.255834] x19: 0000000000000000 x18: 000000000000013e
[ 186.263209] x17: ffffffc0126d0598 x16: ffffffc0126d059c
[ 186.270543] x15: ffffffc010a278d0 x14: 00000000000003ba
[ 186.277835] x13: 000000000000013e x12: ffffffc010b8ba48
[ 186.285092] x11: ffffffc010a7f8d0 x10: 00000000fffff000
[ 186.292300] x9 : ffffffc010a7f8d0 x8 : 0000000000000000
[ 186.299456] x7 : ffffffc010a278d0 x6 : 0000000000000001
[ 186.306538] x5 : 0000000000000000 x4 : 0000000000000000
[ 186.313585] x3 : 0000000000000000 x2 : ffffff807fb95028
[ 186.320584] x1 : ffffffc06f18e000 x0 : 0000000000000040
[ 186.327539] Call trace:
[ 186.331566] dev_watchdog+0x2b0/0x2c0
[ 186.336774] call_timer_fn.constprop.0+0x24/0x80
[ 186.342900] __run_timers.part.0+0x240/0x280
[ 186.348659] run_timer_softirq+0x3c/0x74
[ 186.354030] _stext+0x124/0x290
[ 186.358592] irq_exit+0xa0/0xf0
[ 186.363077] __handle_domain_irq+0x80/0xe0
[ 186.368451] gic_handle_irq+0x78/0xa0
[ 186.373304] el1_irq+0xcc/0x180
[ 186.377563] arch_cpu_idle+0x18/0x30
[ 186.382186] default_idle_call+0x20/0x70
[ 186.387078] do_idle+0x21c/0x280
[ 186.391247] cpu_startup_entry+0x28/0x60
[ 186.396092] rest_init+0xbc/0xcc
[ 186.400221] arch_call_rest_init+0x10/0x1c
[ 186.405198] start_kernel+0x438/0x454
[ 186.409766] ---[ end trace b9f206aa7400cbc2 ]---
crashlog+conditions suggest nic hardware / load induced lockup... even more probable considering 5.4 and 5.10 manifest similar behavior...
i'd not exclude some arch + driver specific complications given the maturity of said chipsets, nor power circuitry as a factor
a little more info on how much data exactly you were pumping through each nic is just as relavent as time frames to crash... ( as is temperature I suppose... but not everyone has a thermal camera )
i think the first point of call would be to also reproduce with only a single usb nic inserted / used ...
(or save the trouble and use alternate nic/s?)
what id you skip the hub, and connect the NICs directly to the RPi ?
The temperature or power is definitely not because I use 3A and the fan is cool. machine temperature is very cool. My per wan speed is 250mb/wan and I use mwan3 to make 2 wan bandwidth into 1 Lan. Lan is equivalent to 400 ~ 450mb (After a few tests using the app or Speedtest website, 2 usb asix ax88178 is enabled and it is disabled. It seems that Asix ax88179 really has a problem. restart Raspberry .
I tested not using a usb 3.0 hub. Or just use 1 Usb Asix ax88179 but the problem is still the same. Check with the Speedtest application 3.4 times that the usb has a problem. Or leave it for 1.2 hours, the problem still occurs...
yeah... if there is an issue... I was sort of implying it's lower down in the power delivery layers... in the regulator ic's or components themselves...
rpi4 is known to interact in a non predictable way with hubs and power bleed also...
given the above... i'd go with another chipset / nic...
Can you give me advice on this? I really want to run 2 wan on raspberry.
ue300 / rtl8153? is popular and has generally proved reliable for many users here...
at those speeds... vlans via a smart switch are also a reliable option... ( and bypass the hassle of having to handle boot usb -> nic interface reassignments )
I also consulted a lot of articles about Ax88179. and last response is This device should not be used for Raspberry + Openwrt to avoid problems. Thank you so much my friend!
Out of curiosity why are/were you using the hub? Given the RPi4 has two USB 3.0 ports and as far as I am aware ethernet adapters aren't that power hungry.
not sure about the OP, but I'd lean towards using a hub here...
mostly for the space/wear and tear factor... but the onboard power regulator is the achilles heel of the pi4... so if in doubt use a (powered) hub... but some hubs cause more issues than they solve...
a single usb->ethernet + a single usb3 thumb drive would probably be ok... and as you say 2 nics would probably be ok too...
but when hardware starts acting funny... it's definately one of the first things to try on these boards...
I replaced the Hub using a better one for the Asix ax88179a. But the problem is still the same. (The problem of lack of power can be ignored)
And I also tried 1 usb ax88179 to the Raspberry board, the problem is still the same, combining a lot of linux 5.4 > 5.10
Asix ax88179 tried on both PfSense and same error. It seems that Asix ax88179 is really problematic on Linux systems.
All 3 tests give the same result: Asix automatically dies after some time, you have to restart Openwrt, pfsense... Test App Speedtest or website 3,4 times Asix88179 will die on its own.
I firmly believe that the problem is related to the Driver that all Asix ax88179 currently on the market drive when running on Lunux. And I'm still waiting for a fix from someone in the community.
I want to use 2 Wan Asix ax88179 in combination with Mwan3 for load balancing.
I had the same issue with the ax88179 adapter. Seemed to be triggered not by high throughput, but by a high packet per second rate. I disabled QoS (qdisc set to none) on the ax88179 adapter interface and that appears to have resolved the issue.
The same issue.
Bus 003 Device 003: ID 0b95:1790 ASIX Elec. Corp. AX88179
dmesg | grep asix
[ 608.073560] usbcore: registered new interface driver asix
dmesg | grep ax88
[ 11.232362] ax88179_178a 3-1.1:1.0 eth1: register 'ax88179_178a' at usb-d0058000.usb-1.1, ASIX AX88179 USB 3.0 Gigabit Ethernet, XX:XX:XX:XX.....
[ 11.246326] usbcore: registered new interface driver ax88179_178a
root@Espresso1:~# dmesg | grep usb
[ 0.223957] usbcore: registered new interface driver usbfs
[ 0.229601] usbcore: registered new interface driver hub
[ 0.235139] usbcore: registered new device driver usb
[ 0.676942] orion-ehci d005e000.usb: EHCI Host Controller
[ 0.682470] orion-ehci d005e000.usb: new USB bus registered, assigned bus number 1
[ 0.690340] orion-ehci d005e000.usb: irq 21, io mem 0xd005e000
[ 0.721702] orion-ehci d005e000.usb: USB 2.0 started, EHCI 1.00
[ 0.737146] usbcore: registered new interface driver usb-storage
[ 2.761808] xhci-hcd d0058000.usb: xHCI Host Controller
[ 2.767237] xhci-hcd d0058000.usb: new USB bus registered, assigned bus number 2
[ 2.775010] xhci-hcd d0058000.usb: hcc params 0x0a000998 hci version 0x100 quirks 0x0000000000010090
[ 2.784491] xhci-hcd d0058000.usb: irq 20, io mem 0xd0058000
[ 2.799195] xhci-hcd d0058000.usb: xHCI Host Controller
[ 2.804629] xhci-hcd d0058000.usb: new USB bus registered, assigned bus number 3
[ 2.812280] xhci-hcd d0058000.usb: Host supports USB 3.0 SuperSpeed
[ 2.818846] usb usb3: We don't know the algorithms for LPM for this host, disabling LPM.
[ 3.081782] usb 2-1: new high-speed USB device number 2 using xhci-hcd
[ 3.567030] usb 3-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[ 4.573250] usb 3-1.1: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[ 11.010796] usbcore: registered new interface driver asix
[ 11.371047] ax88179_178a 3-1.1:1.0 eth1: register 'ax88179_178a' at usb-d0058000.usb-1.1, ASIX AX88179 USB 3.0 Gigabit Ethernet, XX:XX:XX:XX:.....
[ 11.385028] usbcore: registered new interface driver ax88179_178a
@hiendd @diego Same issue with my 4 different AX88179
1 is by StarTech and I have 2 by D-Link and 1 by cheap company
After a boot, they come up with issues after a few minutes with all 4
I tried my AX88772C USB 2.0 to ethernet adapter and it works fine
I have a RealTek USB 3.0 adapter that I just tested and works fine also - RTL8153 but the RTL8152 driver in OpenWrt works fine with it.
This is with RPi3 , 22.03 rc6
This is ax88179 issue.
Hope this helps somebody
Thanks to this thread because I was going a bit crazy trying to figure out what was happening