Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#873 - problems of mt7628 wifi driver on miwifi nano #6661

Closed
openwrt-bot opened this issue Jun 28, 2017 · 7 comments
Closed

FS#873 - problems of mt7628 wifi driver on miwifi nano #6661

openwrt-bot opened this issue Jun 28, 2017 · 7 comments
Labels

Comments

@openwrt-bot
Copy link

nqsnqs:

I started using lede on my miwifi nano since the release of version 17.01.1. All function works well except its wireless function.

What makes it a problem is its stability. After a random period of time(ranging from a quarter of an hour to half of a day), it suddenly disconnected. If you try to reconnect, my device shows something like "setting the network address"(varing from devices to devices). After reboot, I found something like "deauthenticated due to inactivity (timer DEAUTH/REMOVE)". Unfortunately, I haven't found a way to reproduce the problem till now.

I thought there might be bugs on its wireless driver because on another firmware(http://downloads.pandorabox.com.cn/pandorabox/Xiaomi-Mini-R1CL/firmware/PandoraBox-ralink-mt7628-xiaomi-r1cl-squashfs-sysupgrade-r1752-20151201.bin) which is a variant of Openwrt, it works well.

There are many other problems like the inability to set channel to auto and the txpower option is of no use. But for my daily use, they may not so important compared to the connectivity problem.

Sorry for my bad English and thank you for fixing it.

@openwrt-bot
Copy link
Author

nbd:

Please test the latest snapshot build to see if stabiliy is improved now.

@openwrt-bot
Copy link
Author

w_to_d:

I am on latest snapshot:
Powered by LuCI Master (git-17.194.28316-2224714) / LEDE Reboot SNAPSHOT r4610-97eb8ab

Try stable version earlier, the snapshot last longer before wifi down. But still, after few random hours wifi still down. I have not dig too deep into the sysem log, but what is clear to me is that I got plenty of:

Mon Jul 24 00:31:40 2017 daemon.notice hostapd: wlan0-2: STA 00:25:9c:c9:1a:b6 IEEE 802.11: did not acknowledge authentication response
Mon Jul 24 00:31:43 2017 daemon.notice hostapd: wlan0-2: STA 00:25:9c:c9:1a:b6 IEEE 802.11: did not acknowledge authentication response
Mon Jul 24 00:31:46 2017 daemon.notice hostapd: wlan0-2: STA 00:25:9c:c9:1a:b6 IEEE 802.11: did not acknowledge authentication response

And..

Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.218220] ------------[ cut here ]------------
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.222974] WARNING: CPU: 0 PID: 6 at /home/buildbot/slave-lede-local/ramips_mt7628/build/build_dir/target-mipsel_24kc_musl/linux-ramips_mt7628/mt76-2017-07-17-3c4c9a64/mt7603_mac.c:1279 mt7603_mac_work+0x12c/0x248 [mt7603e]
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.243172] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crMon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.309494] CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W 4.9.37 #0
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.317007] Workqueue: phy0 mt7603_mac_work [mt7603e]
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.322139] Stack : 83803414 8383ab98 00000088 8004d510 8382dc4c 803ff307 803b0d10 00000006
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.330658] 803b0c7c 8384bd64 80400000 8007c58c 00000088 8004d510 803b64d4 80400000
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.339172] 00000003 8384bd64 80400000 80038d64 00000088 8384bd9c 000000d9 00000000
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.347665] 80411110 00000000 831054f8 83b77300 83b77400 30796870 00000000 00000000
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.356177] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.364687] ...
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.367172] Call Trace:
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.369689] [<8000e3e8>] show_stack+0x54/0x88
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.374129] [<80023f30>] __warn+0xe4/0x118
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.378307] [<80023ff8>] warn_slowpath_null+0x1c/0x34
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.383457] [<83105624>] mt7603_mac_work+0x12c/0x248 [mt7603e]
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.389412] [<80036dc8>] process_one_work+0x1ec/0x32c
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.394539] [<80037b74>] worker_thread+0x2ac/0x420
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.399412] [<8003c374>] kthread+0xd8/0xec
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.403570] [<80009338>] ret_from_kernel_thread+0x14/0x1c
Mon Jul 24 01:07:33 2017 kern.warn kernel: [ 2858.409056] ---[ end trace 452233866cce43ff ]---

like few hundreds line of it, got nothing wrong on kernel log.

This might be off topic, if i install luci-app-sqm wifi, wifi downs in several mins. From what i dig around, its also happened on mt76xx other than 7628.

@openwrt-bot
Copy link
Author

w_to_d:

Testing LEDE Reboot SNAPSHOT r4619-d72371e / LuCI Master (git-17.194.28316-2224714)

Wifi down when i am away less than an hour, no log.

@openwrt-bot
Copy link
Author

nbd:

Please try the latest version

@openwrt-bot
Copy link
Author

dibg:

I love the freedom i have by using Lede. I bought the lovely xiaomi nano couple of years ago and even i had problem with openwrt i refused to give up on them. I had some older openwrt snapshot from 2016, i tried the stable 17.01.4 and then the last snapshot from couple days (OpenWrt SNAPSHOT r6074-267873a / LuCI Master (git-18.039.58622-76f9f5e) and the problem persists. The wifi hangs after some gigabytes of transfer. It seems this mt7603_mac.c is always responsible for everything. Global warming, traffic, crashing my router. I not have the super power to decipher and act upon this information but you may posses this gift.

here is the confusing message:

Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.762771] ------------[ cut here ]------------
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.767513] WARNING: CPU: 0 PID: 38 at /build/lede-17.01/slaves/phase1/ramips_mt7628/build/build_dir/target-mipsel_24kc_musl-1.1.16/linux-ramips_mt7628/mt76-2017-10-12-1be430fc/mt7603_mac.c:1279 0x830cd510 mt7603e@830c8000+0x6c60
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.788500] Modules linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crTue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.854825] CPU: 0 PID: 38 Comm: kworker/u2:2 Tainted: G W 4.4.92 #0
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.862427] Workqueue: phy0 0x830cd420 [mt7603e@830c8000+0x6c60]
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.868529] Stack : 83803410 83907898 00000088 8004aba4 00000000 00000000 00000000 00000000
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.868529] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.868529] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.868529] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.868529] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.868529] ...
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.904670] Call Trace:[<8004aba4>] 0x8004aba4
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.909204] [<800144e0>] 0x800144e0
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.912741] [<800144e0>] 0x800144e0
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.916288] [<80025054>] 0x80025054
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.919839] [<830cd510>] 0x830cd510 [mt7603e@830c8000+0x6c60]
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.925696] [<8002510c>] 0x8002510c
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.929232] [<80042e6c>] 0x80042e6c
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.932777] [<80043338>] 0x80043338
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.936328] [<830cd510>] 0x830cd510 [mt7603e@830c8000+0x6c60]
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.942169] [<80036a28>] 0x80036a28
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.945754] [<80037850>] 0x80037850
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.949297] [<800375a0>] 0x800375a0
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.952856] [<800375a0>] 0x800375a0
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.956398] [<8003bc30>] 0x8003bc30
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.959967] [<8003bb58>] 0x8003bb58
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.963523] [<80004478>] 0x80004478
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.967063]
Tue Feb 13 06:32:39 2018 kern.warn kernel: [ 4370.968574] ---[ end trace fa7bf67cdbe8584c ]---

@openwrt-bot
Copy link
Author

stephendt:

Years have passed and this device still has issues with Wi-Fi - transfer 1-2GB and it will completely crash the Wi-Fi connection. It's pretty clear that it will not receive a fix at this stage. I'm currently looking at reverting the firmware to stock.

@aparcar
Copy link
Member

aparcar commented Dec 2, 2022

This issue is for a EOL release, please comment if this bug still affects you in currently supported releases.

@aparcar aparcar closed this as not planned Won't fix, can't repro, duplicate, stale Dec 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants