Comments (204)
yuhhaurlin
commented on August 16, 2024
Did the client have problem with 10.3.0.3?
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
Sorry. It is all right for 10.3.0.3. Please wait for next release to see if you still have this kind of problem.
from mwlwifi.
damianyang
commented on August 16, 2024
I am having same issues with MacBook Pro (Mid 2012 Retina) client on WRT1200AC with this driver. I am currently running in legacy mode (11g) to avoid this issue.
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin any eta on the next release?
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
10.3.0.9 is under development. Except for this fix, it will enhance Tx throughput of mwlwifi driver to be as good as proprietary driver. Debugfs will also be added to this version of code. Once if done, I will synchronize it to here.
Note: With support of AMSDU, Rx throughput of mwlwifi driver is almost the same as proprietary driver, but Tx throughput is still not as good as proprietary driver.
from mwlwifi.
tusc
commented on August 16, 2024
will 10.3.0.9 address issue #21? This is the biggest issue right now with the wireless driver and I would categorize performance as secondary over stability.
from mwlwifi.
kaloz
commented on August 16, 2024
@yuhhaurlin : could you add support for mac80211's chainmask get/set functions, too? It would allow custom configs as well as valid info in "iw phy phy0 info".
from mwlwifi.
thagabe
commented on August 16, 2024
@yuhhaurlin I agree with @tusc. My router heats up quite a bit (mainly because it is summer here) and I have noticed stability and performance issues. If i recall correctly the wireless chip was the one that caused the halt in the system. I have tried to keep my system cooler by rewriting the default fan control but i have found limited success. Stability should take center stage however performance is always a welcomed change. I think it's too late to refocus the attention to stability on 10.3.0.9 but for the next release stability should be taken more into consideration as well as stomping out the problem with weird performance inconsistencies. Thank you for the update.
from mwlwifi.
TireMeat
commented on August 16, 2024
Ran the latest 10.3.0.8 build and was able to stabilize somewhat. I'm agreeing with the folks saying there are IRQ and memory pressure problems. Also agree that unless we stabilize, there's no point in increasing performance.
At any rate, decided to dig further and test, but wanted to share with you guys. Curious to hear what you experience.
Using LAN_SpeedTest.exe, (set to test with a 512MB file), I was able to reliably cause a hang at ~431MB without the sysctl & IRQ settings below. (The smb.conf settings below just improved my samba overall performance)
In sysctl.conf, added these ...
vm.swappiness=10
vm.dirty_ratio=15
vm.dirty_background_ratio=4
I let the script below run in rc.local to set IRQs at boot ...
root@WRT1900:~# cat SetIRQs.sh
#!/bin/ash
SET IRQS TO BALANCE ON BOTH CORES OF WRT1900
watch -n 1 cat /proc/interrupts
echo 2 > /proc/irq/18/smp_affinity
echo 2 > /proc/irq/29/smp_affinity
echo 2 > /proc/irq/88/smp_affinity
echo "SetIRQs ran" > /root/SetIRQs.date +%Y.%m.%d
Here is how the IRQs balanced, after 6 hours and a few test file copy runs ...# cat /proc/interrupts
root@WRT1900:
CPU0 CPU1
16: 2245375 2265117 armada_370_xp_irq 5 armada_370_xp_per_cpu_tick
18: 118 40214 armada_370_xp_irq 31 mv64xxx_i2c
19: 23 0 armada_370_xp_irq 41 serial
25: 0 0 armada_370_xp_irq 45 ehci_hcd:usb1
26: 658 0 armada_370_xp_irq 8 mvneta
27: 11150 0 armada_370_xp_irq 10 mvneta
28: 0 0 armada_370_xp_irq 55 f10a0000.sata
29: 17289 1822 armada_370_xp_irq 113 f10d0000.nand
69: 0 0 f1018140.gpio 0 gpio_keys
70: 0 0 f1018140.gpio 1 gpio_keys
87: 35903440 0 armada_370_xp_irq 59 mwlwifi
88: 0 35886117 armada_370_xp_irq 60 mwlwifi
89: 2 0 armada_370_xp_irq 51 f1060900.xor
90: 2 0 armada_370_xp_irq 52 f1060900.xor
91: 2 0 armada_370_xp_irq 94 f10f0900.xor
92: 2 0 armada_370_xp_irq 95 f10f0900.xor
93: 51479 0 armada_370_xp_msi_irq 0 xhci_hcd
IPI0: 0 0 CPU wakeup interrupts
IPI1: 0 0 Timer broadcast interrupts
IPI2: 16685 56446 Rescheduling interrupts
IPI3: 0 0 Function call interrupts
IPI4: 16814 4185 Single function call interrupts
IPI5: 0 0 CPU stop interrupts
IPI6: 0 0 IRQ work interrupts
IPI7: 0 0 completion interrupts
Err: 0
Added the buffers and last 3 lines to smb.conf (to /tmp/etc/smb.conf, and the template in case i need to recover) ...
smb.conf
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
strict allocate = yes
read raw = yes
write raw = yes
from mwlwifi.
TireMeat
commented on August 16, 2024
(sorry for the "set IRQ" bold thing ... unintentional)
from mwlwifi.
tusc
commented on August 16, 2024
when you say hang did you see the message "INFO: rcu_sched self-detected stall on CPU...." in your syslog? This is the issue that is reported in #21
from mwlwifi.
TireMeat
commented on August 16, 2024
The hang was the same as described in #21 except that wireless did not connect/disconnect while my file transfer tests were running. I'll confirm tonight and let you know.
from mwlwifi.
TireMeat
commented on August 16, 2024
I tried (and succeeded) in hanging the router in various ways, but have not seen the #21 message in my syslog. I'm having it syslog remotely to a server wired directly into the 1900's switch using static IPs on both 1900 and the server, which works fine -- though I'm thinking to make the serial header to see any console logs instead of relying on syslog.
Incidentally, while LAN_SpeedTest utility didn't lock up the router all day while I was at work, downloading a torrent on my PC through the 1900 via 5G ac WiFi did so in maybe less than a minute.
from mwlwifi.
rpallai
commented on August 16, 2024
IMHO "error code: -22" is not just a performance trouble but even stability. My WRT1200AC dropped the connection of a client after 1-2 hours downloading with this error.
I've 42MB of 512MB RAM used and seen much higher data rates on this router than this download, it's not IRQ balance or memory pressure problem.
mwlwifi 10.3.0.8 in CHAOS CALMER (Bleeding Edge, r46760)
The only connected station was the downloading client with AR9287 PCI-E WIFI, HT40. Nothing on AC radio.
Related radio config:
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.channel='11'
wireless.radio1.path='soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
wireless.radio1.country='HU'
wireless.radio1.hwmode='11ng'
wireless.radio1.htmode='HT40-'
wireless.radio1.disabled='0'
wireless.radio1.ht_capab='SHORT-GI-40' 'DSSS_CCK-40'
wireless.radio1.noscan='1'
wireless.@wifi-iface[1]=wifi-iface
wireless.@wifi-iface[1].device='radio1'
wireless.@wifi-iface[1].network='lan'
wireless.@wifi-iface[1].mode='ap'
wireless.@wifi-iface[1].key='***'
wireless.@wifi-iface[1].encryption='psk2'
wireless.@wifi-iface[1].ssid='OpenWrt2'
Log messages:
Wed Sep 2 19:38:24 2015 kern.err kernel: [22476.624445] ieee80211 phy1: check ba result error
Wed Sep 2 19:38:25 2015 kern.err kernel: [22477.649258] ieee80211 phy1: check ba result error
Wed Sep 2 19:38:26 2015 kern.err kernel: [22478.671713] ieee80211 phy1: check ba result error
Wed Sep 2 19:38:27 2015 kern.err kernel: [22479.694064] ieee80211 phy1: check ba result error
Wed Sep 2 19:38:28 2015 kern.err kernel: [22480.716321] ieee80211 phy1: check ba result error
Wed Sep 2 19:38:29 2015 kern.err kernel: [22481.733487] ieee80211 phy1: error code: -22
Wed Sep 2 19:38:29 2015 daemon.info hostapd: wlan1: STA a0:f3:c1:f8:9b:e0 IEEE 802.11: authenticated
Wed Sep 2 19:38:29 2015 daemon.info hostapd: wlan1: STA a0:f3:c1:f8:9b:e0 IEEE 802.11: authenticated
Wed Sep 2 19:38:30 2015 daemon.info hostapd: wlan1: STA a0:f3:c1:f8:9b:e0 IEEE 802.11: authenticated
Wed Sep 2 19:38:30 2015 daemon.info hostapd: wlan1: STA a0:f3:c1:f8:9b:e0 IEEE 802.11: authenticated
Wed Sep 2 19:38:31 2015 daemon.info hostapd: wlan1: STA a0:f3:c1:f8:9b:e0 IEEE 802.11: authenticated
Sep 02 19:38:25 dh.darknet NetworkManager[1273]: <warn> Connection disconnected (reason -4)
Sep 02 19:38:25 dh.darknet NetworkManager[1273]: <info> (wlp2s0): supplicant interface state: completed -> disconnected
Sep 02 19:38:25 dh.darknet NetworkManager[1273]: <info> (wlp2s0): supplicant interface state: disconnected -> scanning
Sep 02 19:38:26 dh.darknet kernel: wlp2s0: authenticate with 00:25:9c:13:b0:8b
Sep 02 19:38:26 dh.darknet kernel: wlp2s0: send auth to 00:25:9c:13:b0:8b (try 1/3)
Sep 02 19:38:26 dh.darknet NetworkManager[1273]: <info> (wlp2s0): supplicant interface state: scanning -> authenticating
Sep 02 19:38:26 dh.darknet kernel: wlp2s0: send auth to 00:25:9c:13:b0:8b (try 2/3)
Sep 02 19:38:26 dh.darknet kernel: wlp2s0: send auth to 00:25:9c:13:b0:8b (try 3/3)
Sep 02 19:38:27 dh.darknet kernel: wlp2s0: authentication with 00:25:9c:13:b0:8b timed out
Sep 02 19:38:27 dh.darknet NetworkManager[1273]: <info> (wlp2s0): supplicant interface state: authenticating -> disconnected
Sep 02 19:38:27 dh.darknet NetworkManager[1273]: <info> (wlp2s0): supplicant interface state: disconnected -> scanning
Sep 02 19:38:28 dh.darknet kernel: wlp2s0: authenticate with 00:25:9c:13:b0:8b
Sep 02 19:38:28 dh.darknet kernel: wlp2s0: direct probe to 00:25:9c:13:b0:8b (try 1/3)
Sep 02 19:38:28 dh.darknet NetworkManager[1273]: <info> (wlp2s0): supplicant interface state: scanning -> authenticating
Sep 02 19:38:28 dh.darknet kernel: wlp2s0: direct probe to 00:25:9c:13:b0:8b (try 2/3)
Sep 02 19:38:28 dh.darknet kernel: wlp2s0: direct probe to 00:25:9c:13:b0:8b (try 3/3)
Sep 02 19:38:28 dh.darknet kernel: wlp2s0: authentication with 00:25:9c:13:b0:8b timed out
Sep 02 19:38:28 dh.darknet NetworkManager[1273]: <info> (wlp2s0): supplicant interface state: authenticating -> disconnected
Sep 02 19:38:29 dh.darknet NetworkManager[1273]: <info> (wlp2s0): supplicant interface state: disconnected -> scanning
Sep 02 19:38:30 dh.darknet kernel: wlp2s0: authenticate with 00:25:9c:13:b0:8b
Sep 02 19:38:30 dh.darknet kernel: wlp2s0: direct probe to 00:25:9c:13:b0:8b (try 1/3)
Sep 02 19:38:30 dh.darknet NetworkManager[1273]: <info> (wlp2s0): supplicant interface state: scanning -> authenticating
Sep 02 19:38:30 dh.darknet kernel: wlp2s0: 00:25:9c:13:b0:8b unexpected authentication state: alg 0 (expected 0) transact 2 (expected 0)
Sep 02 19:38:30 dh.darknet kernel: wlp2s0: 00:25:9c:13:b0:8b unexpected authentication state: alg 0 (expected 0) transact 2 (expected 0)
Sep 02 19:38:30 dh.darknet kernel: wlp2s0: 00:25:9c:13:b0:8b unexpected authentication state: alg 0 (expected 0) transact 2 (expected 0)
Sep 02 19:38:30 dh.darknet kernel: wlp2s0: send auth to 00:25:9c:13:b0:8b (try 2/3)
Sep 02 19:38:31 dh.darknet kernel: wlp2s0: send auth to 00:25:9c:13:b0:8b (try 3/3)
Sep 02 19:38:31 dh.darknet kernel: wlp2s0: authentication with 00:25:9c:13:b0:8b timed out
Sep 02 19:38:31 dh.darknet NetworkManager[1273]: <info> (wlp2s0): supplicant interface state: authenticating -> disconnected
Sep 02 19:38:31 dh.darknet NetworkManager[1273]: <info> Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Peer failed to perform TLS handshake'.
Sep 02 19:38:36 dh.darknet NetworkManager[1273]: <info> (wlp2s0): supplicant interface state: disconnected -> scanning
Sep 02 19:38:41 dh.darknet NetworkManager[1273]: <warn> (wlp2s0): link timed out.
Sep 02 19:38:41 dh.darknet NetworkManager[1273]: <info> (wlp2s0): device state change: activated -> failed (reason 'ssid-not-found') [100 120 53]
Sep 02 19:38:41 dh.darknet NetworkManager[1273]: <warn> (wlp2s0): Activation: failed for connection 'OpenWrt2 (test)'
Sep 02 19:38:41 dh.darknet NetworkManager[1273]: <info> (wlp2s0): device state change: failed -> disconnected (reason 'none') [120 30 0]
Sep 02 19:38:41 dh.darknet NetworkManager[1273]: <info> (wlp2s0): deactivating device (reason 'none') [0]
Sep 02 19:38:41 dh.darknet kernel: IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
Sep 02 19:38:41 dh.darknet NetworkManager[1273]: <warn> Couldn't disconnect supplicant interface: This interface is not connected.
Sep 02 19:38:41 dh.darknet NetworkManager[1273]: <info> (wlp2s0): supplicant interface state: scanning -> inactive
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@ rpallai
Did you encounter the same problem on 10.3.0.3?
from mwlwifi.
notnyt
commented on August 16, 2024
I get a bunch of error code: -22 on 10.3.0.3
[289503.844760] ieee80211 phy1: result error
[289504.865325] ieee80211 phy1: result error
[289505.880306] ieee80211 phy1: result error
[289506.896666] ieee80211 phy1: result error
[289507.911764] ieee80211 phy1: result error
[289508.927153] ieee80211 phy1: error code: -22
[289509.954501] ieee80211 phy1: result error
[289510.963250] ieee80211 phy1: result error
[289511.971403] ieee80211 phy1: result error
[289512.979514] ieee80211 phy1: result error
[289513.987828] ieee80211 phy1: result error
[289514.993881] ieee80211 phy1: error code: -22
[289559.213291] ieee80211 phy1: result error
[289560.234195] ieee80211 phy1: result error
[289561.248002] ieee80211 phy1: result error
[289562.269722] ieee80211 phy1: result error
[289563.294217] ieee80211 phy1: result error
[289564.377248] ieee80211 phy1: error code: -22
[289564.523108] ieee80211 phy1: result error
[289565.578803] ieee80211 phy1: result error
[289566.651762] ieee80211 phy1: result error
[289567.749378] ieee80211 phy1: result error
[289568.865748] ieee80211 phy1: result error
[289569.916856] ieee80211 phy1: error code: -22
[289570.472904] ieee80211 phy1: result error
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@ notnyt
What client did you use?
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@ notnyt
The problem also happened after running for a while?
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
Tx throughput is enhanced to be as good as proprietary driver now. One problem of 10.3.0.8 is that all packets in AMSDU should be acknowledged to mac80211.
About issue #21 and check ba error, we will try to fix it. Thanks.
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin Problem can happen right away, doesn't seem to be time dependent. It might be a 2008 unibody macbook running osx triggering that, but not sure.
Mon Aug 31 11:09:16 2015 daemon.info hostapd: wlan0: STA 00:23:12:54:04:63 IEEE 802.11: disassociated
Mon Aug 31 11:09:17 2015 daemon.info hostapd: wlan1: STA 00:23:12:54:04:63 IEEE 802.11: authenticated
Mon Aug 31 11:09:17 2015 daemon.info hostapd: wlan1: STA 00:23:12:54:04:63 IEEE 802.11: associated (aid 1)
Mon Aug 31 11:09:17 2015 daemon.info hostapd: wlan1: STA 00:23:12:54:04:63 WPA: pairwise key handshake completed (RSN)
Mon Aug 31 11:09:17 2015 daemon.info hostapd: wlan0: STA 00:23:12:54:04:63 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Aug 31 11:09:57 2015 kern.err kernel: [289503.844760] ieee80211 phy1: result error
Mon Aug 31 11:09:58 2015 kern.err kernel: [289504.865325] ieee80211 phy1: result error
Mon Aug 31 11:09:59 2015 kern.err kernel: [289505.880306] ieee80211 phy1: result error
Mon Aug 31 11:10:00 2015 kern.err kernel: [289506.896666] ieee80211 phy1: result error
Mon Aug 31 11:10:01 2015 kern.err kernel: [289507.911764] ieee80211 phy1: result error
Mon Aug 31 11:10:02 2015 kern.err kernel: [289508.927153] ieee80211 phy1: error code: -22
Mon Aug 31 11:10:03 2015 kern.err kernel: [289509.954501] ieee80211 phy1: result error
Mon Aug 31 11:10:04 2015 kern.err kernel: [289510.963250] ieee80211 phy1: result error
Mon Aug 31 11:10:05 2015 kern.err kernel: [289511.971403] ieee80211 phy1: result error
Mon Aug 31 11:10:06 2015 kern.err kernel: [289512.979514] ieee80211 phy1: result error
Mon Aug 31 11:10:07 2015 kern.err kernel: [289513.987828] ieee80211 phy1: result error
Mon Aug 31 11:10:08 2015 kern.err kernel: [289514.993881] ieee80211 phy1: error code: -22
Mon Aug 31 11:10:52 2015 kern.err kernel: [289559.213291] ieee80211 phy1: result error
Mon Aug 31 11:10:54 2015 kern.err kernel: [289560.234195] ieee80211 phy1: result error
Mon Aug 31 11:10:55 2015 kern.err kernel: [289561.248002] ieee80211 phy1: result error
Mon Aug 31 11:10:56 2015 kern.err kernel: [289562.269722] ieee80211 phy1: result error
Mon Aug 31 11:10:57 2015 kern.err kernel: [289563.294217] ieee80211 phy1: result error
Mon Aug 31 11:10:58 2015 kern.err kernel: [289564.377248] ieee80211 phy1: error code: -22
Mon Aug 31 11:10:58 2015 kern.err kernel: [289564.523108] ieee80211 phy1: result error
Mon Aug 31 11:10:59 2015 kern.err kernel: [289565.578803] ieee80211 phy1: result error
Mon Aug 31 11:11:00 2015 kern.err kernel: [289566.651762] ieee80211 phy1: result error
Mon Aug 31 11:11:01 2015 kern.err kernel: [289567.749378] ieee80211 phy1: result error
Mon Aug 31 11:11:02 2015 kern.err kernel: [289568.865748] ieee80211 phy1: result error
Mon Aug 31 11:11:03 2015 kern.err kernel: [289569.916856] ieee80211 phy1: error code: -22
Mon Aug 31 11:11:04 2015 kern.err kernel: [289570.472904] ieee80211 phy1: result error
from mwlwifi.
damianyang
commented on August 16, 2024
I had same error messages (running trunk on WRT1200AC) with MacBook pro
2012 Retina. It initially started with just result error back with 10.3.0.3
then it changed to check ba result error when using 10.3.0.8.
@yuhhaurlin https://github.com/yuhhaurlin Problem can happen right away,
doesn't seem to be time dependent. It might be a 2008 unibody macbook
running osx triggering that, but not sure.
Mon Aug 31 11:09:16 2015 daemon.info hostapd: wlan0: STA
00:23:12:54:04:63 IEEE 802.11: disassociated
Mon Aug 31 11:09:17 2015 daemon.info hostapd: wlan1: STA
00:23:12:54:04:63 IEEE 802.11: authenticated
Mon Aug 31 11:09:17 2015 daemon.info hostapd: wlan1: STA
00:23:12:54:04:63 IEEE 802.11: associated (aid 1)
Mon Aug 31 11:09:17 2015 daemon.info hostapd: wlan1: STA
00:23:12:54:04:63 WPA: pairwise key handshake completed (RSN)
Mon Aug 31 11:09:17 2015 daemon.info hostapd: wlan0: STA
00:23:12:54:04:63 IEEE 802.11: deauthenticated due to inactivity
(timer DEAUTH/REMOVE)
Mon Aug 31 11:09:57 2015 kern.err kernel: [289503.844760] ieee80211
phy1: result error
Mon Aug 31 11:09:58 2015 kern.err kernel: [289504.865325] ieee80211
phy1: result error
Mon Aug 31 11:09:59 2015 kern.err kernel: [289505.880306] ieee80211
phy1: result error
Mon Aug 31 11:10:00 2015 kern.err kernel: [289506.896666] ieee80211
phy1: result error
Mon Aug 31 11:10:01 2015 kern.err kernel: [289507.911764] ieee80211
phy1: result error
Mon Aug 31 11:10:02 2015 kern.err kernel: [289508.927153] ieee80211
phy1: error code: -22
Mon Aug 31 11:10:03 2015 kern.err kernel: [289509.954501] ieee80211
phy1: result error
Mon Aug 31 11:10:04 2015 kern.err kernel: [289510.963250] ieee80211
phy1: result error
Mon Aug 31 11:10:05 2015 kern.err kernel: [289511.971403] ieee80211
phy1: result error
Mon Aug 31 11:10:06 2015 kern.err kernel: [289512.979514] ieee80211
phy1: result error
Mon Aug 31 11:10:07 2015 kern.err kernel: [289513.987828] ieee80211
phy1: result error
Mon Aug 31 11:10:08 2015 kern.err kernel: [289514.993881] ieee80211
phy1: error code: -22
Mon Aug 31 11:10:52 2015 kern.err kernel: [289559.213291] ieee80211
phy1: result error
Mon Aug 31 11:10:54 2015 kern.err kernel: [289560.234195] ieee80211
phy1: result error
Mon Aug 31 11:10:55 2015 kern.err kernel: [289561.248002] ieee80211
phy1: result error
Mon Aug 31 11:10:56 2015 kern.err kernel: [289562.269722] ieee80211
phy1: result error
Mon Aug 31 11:10:57 2015 kern.err kernel: [289563.294217] ieee80211
phy1: result error
Mon Aug 31 11:10:58 2015 kern.err kernel: [289564.377248] ieee80211
phy1: error code: -22
Mon Aug 31 11:10:58 2015 kern.err kernel: [289564.523108] ieee80211
phy1: result error
Mon Aug 31 11:10:59 2015 kern.err kernel: [289565.578803] ieee80211
phy1: result error
Mon Aug 31 11:11:00 2015 kern.err kernel: [289566.651762] ieee80211
phy1: result error
Mon Aug 31 11:11:01 2015 kern.err kernel: [289567.749378] ieee80211
phy1: result error
Mon Aug 31 11:11:02 2015 kern.err kernel: [289568.865748] ieee80211
phy1: result error
Mon Aug 31 11:11:03 2015 kern.err kernel: [289569.916856] ieee80211
phy1: error code: -22
Mon Aug 31 11:11:04 2015 kern.err kernel: [289570.472904] ieee80211
phy1: result error
—
Reply to this email directly or view it on GitHub
#34 (comment).
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
Thanks. 10.3.0.8 will give more clear ba related error messages.
from mwlwifi.
rpallai
commented on August 16, 2024
@ yuhhaurlin
10.3.0.3 has another issue that prevents longer stress testing: each tcp stream begins dying after the initial burst after 40-50 minutes of downloading.
Connection stability of the client is not better on 10.3.0.3, reconnection happens in every 5-10 minutes as with 10.3.0.8. Most disconnections has no related error log entry in the AP log, happens for unknown reasons.
On the other hand connection of this client to my WRT160NL AP is very stable.
10.3.0.8 is free from the tcp dying issue so I can stress it longer, I think this is why I don't encounter exactly the same problem on 10.3.0.3.
Sep 03 03:58:04 dh.darknet NetworkManager[17950]: <warn> Connection disconnected (reason -4)
Sep 03 03:58:04 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: completed -> disconnected
Sep 03 03:58:04 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: disconnected -> scanning
Sep 03 03:58:05 dh.darknet kernel: wlp2s0: authenticate with 00:25:9c:13:b0:8b
Sep 03 03:58:05 dh.darknet kernel: wlp2s0: send auth to 00:25:9c:13:b0:8b (try 1/3)
Sep 03 03:58:05 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: scanning -> authenticating
Sep 03 03:58:05 dh.darknet kernel: wlp2s0: authenticated
Sep 03 03:58:05 dh.darknet kernel: wlp2s0: associate with 00:25:9c:13:b0:8b (try 1/3)
Sep 03 03:58:05 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: authenticating -> associating
Sep 03 03:58:05 dh.darknet kernel: wlp2s0: RX AssocResp from 00:25:9c:13:b0:8b (capab=0x431 status=0 aid=1)
Sep 03 03:58:05 dh.darknet kernel: wlp2s0: associated
Sep 03 03:58:05 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: associating -> associated
Sep 03 03:58:05 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: associated -> completed
Sep 03 03:58:53 dh.darknet kernel: ath: phy0: Failed to stop TX DMA, queues=0x008!
Sep 03 03:59:16 dh.darknet NetworkManager[17950]: <warn> Connection disconnected (reason -4)
Sep 03 03:59:16 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: completed -> disconnected
Sep 03 03:59:16 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: disconnected -> scanning
Sep 03 03:59:17 dh.darknet kernel: wlp2s0: authenticate with 00:25:9c:13:b0:8b
Sep 03 03:59:17 dh.darknet kernel: wlp2s0: send auth to 00:25:9c:13:b0:8b (try 1/3)
Sep 03 03:59:17 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: scanning -> authenticating
Sep 03 03:59:17 dh.darknet kernel: wlp2s0: authenticated
Sep 03 03:59:17 dh.darknet kernel: wlp2s0: associate with 00:25:9c:13:b0:8b (try 1/3)
Sep 03 03:59:17 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: authenticating -> associating
Sep 03 03:59:17 dh.darknet kernel: wlp2s0: RX AssocResp from 00:25:9c:13:b0:8b (capab=0x431 status=0 aid=1)
Sep 03 03:59:17 dh.darknet kernel: wlp2s0: associated
Sep 03 03:59:17 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: associating -> associated
Sep 03 03:59:17 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: associated -> completed
Sep 03 04:00:08 dh.darknet kernel: audit_printk_skb: 9 callbacks suppressed
Sep 03 04:02:09 dh.darknet NetworkManager[17950]: <warn> Connection disconnected (reason -4)
Sep 03 04:02:09 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: completed -> disconnected
Sep 03 04:02:09 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: disconnected -> scanning
Sep 03 04:02:10 dh.darknet kernel: wlp2s0: authenticate with 00:25:9c:13:b0:8b
Sep 03 04:02:10 dh.darknet kernel: wlp2s0: send auth to 00:25:9c:13:b0:8b (try 1/3)
Sep 03 04:02:10 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: scanning -> authenticating
Sep 03 04:02:10 dh.darknet kernel: wlp2s0: authenticated
Sep 03 04:02:10 dh.darknet kernel: wlp2s0: associate with 00:25:9c:13:b0:8b (try 1/3)
Sep 03 04:02:10 dh.darknet kernel: wlp2s0: RX AssocResp from 00:25:9c:13:b0:8b (capab=0x431 status=0 aid=1)
Sep 03 04:02:10 dh.darknet kernel: wlp2s0: associated
Sep 03 04:02:10 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: authenticating -> associated
Sep 03 04:02:10 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: associated -> completed
Sep 03 04:08:15 dh.darknet NetworkManager[17950]: <warn> Connection disconnected (reason -4)
Sep 03 04:08:15 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: completed -> disconnected
Sep 03 04:08:15 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: disconnected -> scanning
Sep 03 04:08:16 dh.darknet kernel: wlp2s0: authenticate with 00:25:9c:13:b0:8b
Sep 03 04:08:16 dh.darknet kernel: wlp2s0: send auth to 00:25:9c:13:b0:8b (try 1/3)
Sep 03 04:08:16 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: scanning -> authenticating
Sep 03 04:08:16 dh.darknet kernel: wlp2s0: authenticated
Sep 03 04:08:16 dh.darknet kernel: wlp2s0: associate with 00:25:9c:13:b0:8b (try 1/3)
Sep 03 04:08:16 dh.darknet kernel: wlp2s0: RX AssocResp from 00:25:9c:13:b0:8b (capab=0x431 status=0 aid=1)
Sep 03 04:08:16 dh.darknet kernel: wlp2s0: associated
Sep 03 04:08:16 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: authenticating -> associated
Sep 03 04:08:16 dh.darknet NetworkManager[17950]: <info> (wlp2s0): supplicant interface state: associated -> completed
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
Yes, driver needs to ack every packets in AMSDU to mac80211.
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin any eta on fixes?
from mwlwifi.
rpallai
commented on August 16, 2024
Looking further I have 2 independent issues here:
- "check ba result error" causes long traffic stalling lasts even for a half of a minute. It is likely prevent even authentication on the AP.
- client getting disconnected every 5-10 minutes without error message at the AP side.
If both problems strikes at once then client gets disconnected permanently. Resolving one of them resolves the permanent client disconnection what is my first problem.
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
If 10.3.0.3 has this problem, I need to check what the problem is. 10.3.0.3 already acked every packets. Does anyone have this kind of problem with 10.3.0.3?
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
Please use "iw event -f" to get event log. From our test here, we did not find this kind of problem on 10.3.0.3.
from mwlwifi.
rpallai
commented on August 16, 2024
@yuhhaurlin: The message was slightly different with 10.3.0.3 but appears at same rate here. Should I run "iw event -f" with RC3 and post the results?
phy1: result error
phy1: error code: -22
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
Sorry. From our test here, 10.3.0.3 will come out check ba error sometimes. I will try to fix it. But we did not find connect/disconnect problem on 10.3.0.3. "iw event -f" will show connecton related events. I wonder if connect/disconnect problem only happened for specific clients?
from mwlwifi.
rpallai
commented on August 16, 2024
@yuhhaurlin: the connect/disconnect problem related to this ticket?
"check ba result error" can happen without disconnection and disconnection can happen without "check ba result error". They are not joined together, just happens at once sometimes.
Anyway, I definitely have the connection stability problem with 10.3.0.3 too, but I'm on the latest currently. I'll downgrade to RC3 and show the results of "iw event -f".
Should I connect more clients for the test?
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
You can offer information to me. I will focus on check ba error and issue #21 first. Thanks.
from mwlwifi.
rpallai
commented on August 16, 2024
@yuhhaurlin Logs posted about connect/disconnect problem with 10.3.0.3 in #26. I'd leave this ticket for the traffic stalling issue followed by message "result error".
from mwlwifi.
TireMeat
commented on August 16, 2024
With 10.3.0.8 "iw event -f" reports this right before wifi dies and the 1900 reboots:
root@WRT1900:~# iw event -f
wlan1 (phy #1): mgmt TX status (cookie e): acked
wlan1 (phy #1): mgmt TX status (cookie f): acked
from mwlwifi.
TireMeat
commented on August 16, 2024
I made the modification below to tx.c in my build environment, (note, lines 363-372 are commented out, and if statement added after). Performance is on-par with my D825 and no panics/halts --- would you guys check on your end?
Also, in /etc/config/wireless, I explicitly set the below, (just snipped the rest of the config lines for clarity):
config wifi-device 'radio0'
option hwmode '11n'
option htmode 'HT20'
config wifi-device 'radio1'
option hwmode '11ac'
option htmode 'VHT80'
(BTW, looking at some other 802.11ac drivers, I don't think this is how ampdu streams are supposed to be set up)
/* reset the packet count after each second elapses. If the number of
* packets ever exceeds the ampdu_min_traffic threshold, we will allow
* an ampdu stream to be started.
*
if (jiffies - tx_stats->start_time > HZ) {
tx_stats->pkts = 0;
tx_stats->start_time = 0;
} else {
tx_stats->pkts++;
}*/
if (jiffies - tx_stats->start_time < HZ)
tx_stats->pkts++;
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin any comments on previous post?
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
No.
from mwlwifi.
rpallai
commented on August 16, 2024
Seems like this issue depends on device used on the client side.
I've not seen this error after I connected with a RTL8812AE or Intel-7260 PCI-E WIFI at 2.4 Ghz/HT40 driven by Fedora. My previous device triggered this issue was an AR9287 PCI-E WIFI.
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin any chance of seeing 10.3.0.9 soon?
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin this is still broken in 10.3.0.10. I thought this was supposed to be fixed?
When I connect my macbook it gets awful speeds and the kernel generates these errors.
[ 1333.191803] ieee80211 phy1: ampdu start error code: -22
[ 1333.238473] ieee80211 phy1: check ba result error 1
[ 1333.243536] ieee80211 phy1: ampdu start error code: -22
[ 1333.277240] ieee80211 phy1: check ba result error 1
[ 1333.282259] ieee80211 phy1: ampdu start error code: -22
[ 1333.346929] ieee80211 phy1: check ba result error 1
[ 1333.351911] ieee80211 phy1: ampdu start error code: -22
[ 1333.386907] ieee80211 phy1: check ba result error 1
[ 1333.391905] ieee80211 phy1: ampdu start error code: -22
[ 1333.447593] ieee80211 phy1: check ba result error 1
[ 1333.452599] ieee80211 phy1: ampdu start error code: -22
[ 1333.496957] ieee80211 phy1: check ba result error 1
[ 1333.502156] ieee80211 phy1: ampdu start error code: -22
[ 1333.557225] ieee80211 phy1: check ba result error 1
[ 1333.562226] ieee80211 phy1: ampdu start error code: -22
[ 1333.694616] ieee80211 phy1: check ba result error 1
[ 1333.699549] ieee80211 phy1: ampdu start error code: -22
[ 1333.754431] ieee80211 phy1: check ba result error 1
[ 1333.759513] ieee80211 phy1: ampdu start error code: -22
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
Thanks, I will check this one.
from mwlwifi.
Gazoo
commented on August 16, 2024
It seems that 10.3.0.10 has introduced some more trouble. Quote: Now one CPU is averaging 54% busy with just a few wireless clients connected. Watching /proc/interrupts, it looks like each mwlwifi is generating nearly 2K interrupts per second.
@yuhhaurlin for more info:
https://forum.openwrt.org/viewtopic.php?pid=296347#p296347
I appreciate all the time you are putting into getting this solved!
from mwlwifi.
TireMeat
commented on August 16, 2024
@yuhhaurlin - great clean-up in 10.3.0.10. I'm looking at the rx.c changes you made -- so cool, I think those were badly needed.
@rob - i'm working on the performance. Would love to hear what you're doing to measure performance and what you're working against (i.e. LAN downloads, wifi to wifi, torrents, etc.). For me, it seems like if I run a torrent (I use the three Debian ISOs because they're huge), and wait a couple of minute for the seeds to pick up, performance hits around 13-14MB/s (that's Bytes not bits). Then, if I do a LAN file copy (put one of the ISOs on my shared disk conncted to eSATA port on the Linksys, or to a Windows 7 laptop using 1Gbps port wired into Linksys) I sometimes get that same performance. Power cycle or reboot, and performance drops to ~2MB/s.
At any rate, I wanted to share my progress and some cleanup code (patch below) that's worked well for my custom build -- I'm working with branch, since I see the direction the DD guys are going is good but pretty steep to adjust my setup to that right now. I figure to give the transmit side (tx, mac80211) a little more work and then see how that works in trunk before adapting to DD.
Anyway, below are the latest I have on the tx side of things, (below the highlights listed is my patch):
- fwcmd.c - removed the threshold condition to start ampdu. This yielded the biggest performance increase I've seen yet.
- fwdl.c - increased the time the firmware has to load. On my v1 Linksys, 1 ms was too fast and it would lock up or reset - (am using a small prime number because it's a cheap way to prevent race conditions and such with whatever else going on that's time bound).
- mac80211.c - simplified the ampdu action logic. My thinking is that this is a full MAC - let mac80211 tell it what needs to be done instead of doing it (i.e. sequencing). I don't have any Apple stacks besides my and my wife's iPhone 6s, but I did see that those are sensitive to sequencing - this clean-up helped to stabilize Apple access for me.
- tx.c - removed the packet counting function altogether and also the calls in xmit. I took out the fwcmd condition as mentioned in #1 above. I also noticed in xmit that some variables were defined and used without (immediate) explicit initialization (like mwl_priv) -- this is sometimes problematic because the variables (pointers) could reference structures like buffers, streams, hw, etc. in-memory that shouldn't be there or start acting on these in an unknown state. For the same reason, I also cleaned-out the ampdu action logic belonging in mac80211, and limited tx to just handle the QoS'ness of the packets. From a stability standpoint, depending on the conditions underlying an IRQ, the kernel could enter mac80211.ko or mwlwifi.ko ... the two could be acting on ampdu streams and relying on stream->state is not enough to prevent lockups, resets, etc. For me this improved the stability a great deal -- also, looking at data transfer patterns (i.e. the traffic graph in Luci for instance or a the traffic pattern in uTorrent or similar), the streams are much tighter and fewer gaps (i.e. less context switching and IRQ handling).
I am actively looking at the performance problem - good news, is under certain circumstances I can get within ~1MB/s of the stock Linksys firmware. Bad news is that I have narrowed down the circumstances, but not yet nailed the root cause preventing faster speed. I believe the issue lies somewhere in the receive side (hence the reason I dug into your rx.c so quickly when I saw you posted :-)). Any info you have that you can share on how rx behaves in this firmware, I'd love to hear about.
On the IRQ affinity - I found it helps quite a bit to put both mwlwifi (phy0 & phy1) and the mvneta (eth0 & eth1) on the second CPU core. My guess is that the whole network stack caches nicely in CC and makes prevents expensive memory access when handling IRQs, and the cores don't seem to share cache ? I purposely left the USB and other (much) slower stuff on the first core.
Last, there's some really good stuff in rx in 10.3.0.10 like I said, and I'll try to integrate those changes in my build and let you know how I do.
Here is my wireless =
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
option htmode 'HT20'
option country 'US'
option channel '4'
option txpower '30'
config wifi-iface
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'O5'
option encryption 'psk2+ccmp'
option key 'sljfs;dfjas'
option hidden '1'
config wifi-device 'radio1'
option type 'mac80211'
option hwmode '11a'
option path 'soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0'
option htmode 'VHT80'
option country 'US'
option channel '149'
option txpower '30'
config wifi-iface
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'O5'
option encryption 'psk2+ccmp'
option key 'sljfs;dfjas'
option hidden '1'
Patch =
diff original_CC_branch/fwcmd.c updated_CC_branch/fwcmd.c
2955,2956c2955
< return (sta_info->is_ampdu_allowed &&
< tx_stats->pkts > SYSADPT_AMPDU_PACKET_THRESHOLD);
return (sta_info->is_ampdu_allowed);
diff original_CC_branch/fwdl.c updated_CC_branch/fwdl.c
20c20< #define FW_CHECK_MSECS 1
#define FW_CHECK_MSECS 3
diff original_CC_branch/mac80211.c updated_CC_branch/mac80211.c
598c598< int i, rc = 0;
int rc = 0;
606,609d605
< spin_lock(&priv->stream_lock);
<
< stream = mwl_fwcmd_lookup_stream(hw, addr, tid);
<
611,613c607,609
< case IEEE80211_AMPDU_RX_START:
< case IEEE80211_AMPDU_RX_STOP:< break;
case IEEE80211_AMPDU_RX_START:
case IEEE80211_AMPDU_RX_STOP:
break;
615,648c611,612
< /* By the time we get here the hw queues may contain outgoing
< * packets for this RA/TID that are not part of this BA
< * session. The hw will assign sequence numbers to these
< * packets as they go out. So if we query the hw for its next
< * sequence number and use that for the SSN here, it may end up
< * being wrong, which will lead to sequence number mismatch at
< * the recipient. To avoid this, we reset the sequence number
< * to O for the first MPDU in this BA stream.
< /
< *ssn = 0;
<
< if (!stream) {
< / This means that somebody outside this driver called
< * ieee80211_start_tx_ba_session. This is unexpected
< * because we do our own rate control. Just warn and
< * move on.
< /
< stream = mwl_fwcmd_add_stream(hw, sta, tid);
< }
<
< if (!stream) {
< wiphy_warn(hw->wiphy, "no stream found");
< rc = -EBUSY;
< break;
< }
<
< stream->state = AMPDU_STREAM_IN_PROGRESS;
<
< / Release the lock before we do the time consuming stuff /
< spin_unlock(&priv->stream_lock);
<
< for (i = 0; i < MAX_AMPDU_ATTEMPTS; i++) {
< / Check if link is still valid */< if (!sta_info->is_ampdu_allowed) {
if (hw != NULL && sta != NULL) { if (mwl_fwcmd_ampdu_allowed(sta, tid)) {650c614,619
< mwl_fwcmd_remove_stream(hw, stream);
stream = mwl_fwcmd_add_stream(hw, sta, tid); if (stream != NULL) { mwl_fwcmd_start_stream(hw, stream); stream->state = AMPDU_STREAM_IN_PROGRESS; ieee80211_start_tx_ba_cb_irqsafe(vif, sta->addr, tid); }652,654d620
< wiphy_warn(hw->wiphy,
< "link is no valid now");
< return -EBUSY;
656,671d621
<
< rc = mwl_fwcmd_check_ba(hw, stream, vif);
<
< if (!rc)
< break;
<
< mdelay(1000);
< }
<
< spin_lock(&priv->stream_lock);
<
< if (rc) {
< mwl_fwcmd_remove_stream(hw, stream);
< wiphy_err(hw->wiphy, "error code: %d", rc);
< rc = -EBUSY;
< break;
673,674d622
<
< ieee80211_start_tx_ba_cb_irqsafe(vif, addr, tid);
675a624679,680c628,631
< if (stream) {< if (stream->state == AMPDU_STREAM_ACTIVE) {
if (hw != NULL && addr != NULL) { spin_lock(&priv->stream_lock); stream = mwl_fwcmd_lookup_stream(hw, addr, tid); if (stream != NULL && stream->state == AMPDU_STREAM_ACTIVE) {682d632
< spin_unlock(&priv->stream_lock);
684c634,636< spin_lock(&priv->stream_lock);
mwl_fwcmd_remove_stream(hw, stream); stream = NULL; ieee80211_stop_tx_ba_cb_irqsafe(vif, sta->addr, tid);686,687c638
<< mwl_fwcmd_remove_stream(hw, stream);
spin_unlock(&priv->stream_lock);689,690d639
<
< ieee80211_stop_tx_ba_cb_irqsafe(vif, addr, tid);
692,696d640
< case IEEE80211_AMPDU_TX_OPERATIONAL:
< BUG_ON(stream->state != AMPDU_STREAM_IN_PROGRESS);
< spin_unlock(&priv->stream_lock);
< rc = mwl_fwcmd_create_ba(hw, stream, buf_size, vif);
< spin_lock(&priv->stream_lock);
698,703c642,643
< if (!rc) {
< stream->state = AMPDU_STREAM_ACTIVE;
< } else {
< idx = stream->idx;
< spin_unlock(&priv->stream_lock);< mwl_fwcmd_destroy_ba(hw, idx);
case IEEE80211_AMPDU_TX_OPERATIONAL:
if (hw != NULL && addr != NULL) {
705c645,655< mwl_fwcmd_remove_stream(hw, stream);
stream = mwl_fwcmd_lookup_stream(hw, addr, tid); if (stream != NULL) { if (mwl_fwcmd_create_ba(hw, stream, buf_size, vif) != NULL) { stream->state = AMPDU_STREAM_ACTIVE; } else { idx = stream->idx; mwl_fwcmd_destroy_ba(hw, idx); stream = NULL; } } spin_unlock(&priv->stream_lock);707a658
711,712d661
<
< spin_unlock(&priv->stream_lock);
diff original_CC_branch/tx.c updated_CC_branch/tx.c
301,326d300
< static inline void mwl_tx_count_packet(struct ieee80211_sta sta, u8 tid)
< {
< struct mwl_sta *sta_info;
< struct mwl_tx_info *tx_stats;
<
< BUG_ON(tid >= SYSADPT_MAX_TID);
<
< sta_info = mwl_dev_get_sta(sta);
<
< tx_stats = &sta_info->tx_stats[tid];
<
< if (tx_stats->start_time == 0)
< tx_stats->start_time = jiffies;
<
< / reset the packet count after each second elapses. If the number of
< * packets ever exceeds the ampdu_min_traffic threshold, we will allow
< * an ampdu stream to be started.
< */
< if (jiffies - tx_stats->start_time > HZ) {
< tx_stats->pkts = 0;
< tx_stats->start_time = 0;
< } else {
< tx_stats->pkts++;
< }
< }
<
489c463< struct mwl_priv *priv;
struct mwl_priv priv = hw->priv;
507d480
< priv = hw->priv;
559,567d531
< / Queue ADDBA request in the respective data queue. While setting up
< * the ampdu stream, mac80211 queues further packets for that
< * particular ra/tid pair. However, packets piled up in the hardware
< * for that ra/tid pair will still go out. ADDBA request and the
< * related data packets going out from different queues asynchronously
< * will cause a shift in the receiver window which might result in
< * ampdu packets getting dropped at the receiver after the stream has
< * been setup.
< */
568a533,534
u16 capab;573,574c539
< u16 capab =< le16_to_cpu(mgmt->u.action.u.addba_req.capab);
capab = le16_to_cpu(mgmt->u.action.u.addba_req.capab);577a543,551
if (unlikely(ieee80211_is_action(wh->frame_control) && mgmt->u.action.category == WLAN_CATEGORY_BACK && mgmt->u.action.u.addba_resp.action_code == WLAN_ACTION_ADDBA_RESP)) { capab = le16_to_cpu(mgmt->u.action.u.addba_resp.capab); capab |= 1; mgmt->u.action.u.addba_resp.capab = cpu_to_le16(capab); }586d559
< mwl_tx_count_packet(sta, tid);
590,592c563
<
< if (stream) {< if (stream->state == AMPDU_STREAM_ACTIVE) {
if (stream != NULL && stream->state == AMPDU_STREAM_ACTIVE) {594,596c565
<
< txpriority =< (SYSADPT_TX_WMM_QUEUES + stream->idx) %
txpriority = (SYSADPT_TX_WMM_QUEUES + stream->idx) %598,636d566
< } else if (stream->state == AMPDU_STREAM_NEW) {
< /* We get here if the driver sends us packets
< * after we've initiated a stream, but before
< * our ampdu_action routine has been called
< * with IEEE80211_AMPDU_TX_START to get the SSN
< * for the ADDBA request. So this packet can
< * go out with no risk of sequence number
< * mismatch. No special handling is required.
< /
< } else {
< / Drop packets that would go out after the
< * ADDBA request was sent but before the ADDBA
< * response is received. If we don't do this,
< * the recipient would probably receive it
< * after the ADDBA request with SSN 0. This
< * will cause the recipient's BA receive window
< * to shift, which would cause the subsequent
< * packets in the BA stream to be discarded.
< * mac80211 queues our packets for us in this
< * case, so this is really just a safety check.
< /
< wiphy_warn(hw->wiphy,
< "can't send packet during ADDBA");
< spin_unlock(&priv->stream_lock);
< dev_kfree_skb_any(skb);
< return;
< }
< } else {
< / Defer calling mwl8k_start_stream so that the current
< * skb can go out before the ADDBA request. This
< * prevents sequence number mismatch at the recipient
< * as described above.
< /
< if (mwl_fwcmd_ampdu_allowed(sta, tid)) {
< stream = mwl_fwcmd_add_stream(hw, sta, tid);
<
< if (stream)
< start_ba_session = true;
< }
638d567
<
660,667d588
<
< / Initiate the ampdu session here */
< if (start_ba_session) {
< spin_lock(&priv->stream_lock);
< if (mwl_fwcmd_start_stream(hw, stream))
< mwl_fwcmd_remove_stream(hw, stream);
< spin_unlock(&priv->stream_lock);
< }
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
Thanks a lot. I will check it.
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
BTW, can you share me what iperf number you got for UDP and TCP after the modificaion you done?
10.3.0.10 has enhancement of Tx. Can you add your modificaion based on 10.3.0.10, and let me know what throughput number you got before and after your modification? Thanks.
I will check your modification on AMPDU.
from mwlwifi.
notnyt
commented on August 16, 2024
@TireMeat was getting about 20mbps with the original change you listed, vs 100+mbps with 10.3.0.3. Please use 4 back ticks to surround code so it doesn't get processed by markdown.
from mwlwifi.
TireMeat
commented on August 16, 2024
@notnyt -- thanks for the formatting heads-up.
@yuhhaurlin -- I did an overall patch from original 10.3.0.10 you posted Friday with the mods I'd done for 10.3.0.3. Also ran iperf before & after (posted below after the patch) -- again, I'm using CC branch with default .config build.
From what I can tell, 10.3.0.10 is tighter than 10.3.0.3 (and 10.3.0.8 as I recall). By "tighter" I'm mean that it seems to do fewer IRQs.
I kept an eye out for CPU load like Gazoo mentioned, but haven't seen that at all. At peak sustained transfer, CPU got to 3% maybe.
I found and got another v1 box yesterday, installed this driver with CC-branch on it, and replaced my D825 for long(er) term use/observation -- (our household is a heavy streaming and mobile-over-WiFi & VoIP environment, with lots of interference from ~12+ other APs within read-distance).
Looking forward to your feedback.
(Meanwhile, I'm going to take a look at the channel, power & cap part of the code ... am curious why initialization seems to go astray.)
diff -r original_CC_branch/fwcmd.c updated_CC_branch/fwcmd.c
2294,2297c2294
< tx_stats = &sta_info->tx_stats[tid];
<
< return (sta_info->is_ampdu_allowed &&
< tx_stats->pkts > SYSADPT_AMPDU_PACKET_THRESHOLD);
---
> return (sta_info->is_ampdu_allowed);
diff -r original_CC_branch/fwdl.c updated_CC_branch/fwdl.c
28c28
< #define FW_CHECK_MSECS 1
---
> #define FW_CHECK_MSECS 3
diff -r original_CC_branch/mac80211.c updated_CC_branch/mac80211.c
580,583d579
< spin_lock_bh(&priv->stream_lock);
<
< stream = mwl_fwcmd_lookup_stream(hw, addr, tid);
<
589,638c585,595
< /* By the time we get here the hw queues may contain outgoing
< * packets for this RA/TID that are not part of this BA
< * session. The hw will assign sequence numbers to these
< * packets as they go out. So if we query the hw for its next
< * sequence number and use that for the SSN here, it may end up
< * being wrong, which will lead to sequence number mismatch at
< * the recipient. To avoid this, we reset the sequence number
< * to O for the first MPDU in this BA stream.
< */
< *ssn = 0;
<
< if (!stream) {
< /* This means that somebody outside this driver called
< * ieee80211_start_tx_ba_session. This is unexpected
< * because we do our own rate control. Just warn and
< * move on.
< */
< stream = mwl_fwcmd_add_stream(hw, sta, tid);
< }
<
< if (!stream) {
< wiphy_warn(hw->wiphy, "no stream found\n");
< rc = -EBUSY;
< break;
< }
<
< stream->state = AMPDU_STREAM_IN_PROGRESS;
<
< /* Release the lock before we do the time consuming stuff */
< spin_unlock_bh(&priv->stream_lock);
<
< /* Check if link is still valid */
< if (!sta_info->is_ampdu_allowed) {
< spin_lock_bh(&priv->stream_lock);
< mwl_fwcmd_remove_stream(hw, stream);
< spin_unlock_bh(&priv->stream_lock);
< wiphy_warn(hw->wiphy,
< "link is not valid now\n");
< return -EBUSY;
< }
< rc = mwl_fwcmd_check_ba(hw, stream, vif);
<
< spin_lock_bh(&priv->stream_lock);
<
< if (rc) {
< mwl_fwcmd_remove_stream(hw, stream);
< wiphy_err(hw->wiphy,
< "ampdu start error code: %d\n", rc);
< rc = -EBUSY;
< break;
---
> if (hw != NULL && sta != NULL) {
> if (mwl_fwcmd_ampdu_allowed(sta, tid)) {
> spin_lock(&priv->stream_lock);
> stream = mwl_fwcmd_add_stream(hw, sta, tid);
> if (stream != NULL) {
> mwl_fwcmd_start_stream(hw, stream);
> stream->state = AMPDU_STREAM_IN_PROGRESS;
> ieee80211_start_tx_ba_cb_irqsafe(vif, sta->addr, tid);
> }
> spin_unlock(&priv->stream_lock);
> }
640,641d596
<
< ieee80211_start_tx_ba_cb_irqsafe(vif, addr, tid);
642a598
>
646,648c602,605
< if (stream) {
< if (stream->state == AMPDU_STREAM_ACTIVE) {
< mwl_tx_del_ampdu_pkts(hw, sta, tid);
---
> if (hw != NULL && addr != NULL) {
> spin_lock(&priv->stream_lock);
> stream = mwl_fwcmd_lookup_stream(hw, addr, tid);
> if (stream != NULL && stream->state == AMPDU_STREAM_ACTIVE) {
650d606
< spin_unlock_bh(&priv->stream_lock);
652c608,610
< spin_lock_bh(&priv->stream_lock);
---
> mwl_fwcmd_remove_stream(hw, stream);
> stream = NULL;
> ieee80211_stop_tx_ba_cb_irqsafe(vif, sta->addr, tid);
654,655c612
<
< mwl_fwcmd_remove_stream(hw, stream);
---
> spin_unlock(&priv->stream_lock);
657,658d613
<
< ieee80211_stop_tx_ba_cb_irqsafe(vif, addr, tid);
660,667d614
< case IEEE80211_AMPDU_TX_OPERATIONAL:
< if (WARN_ON(stream->state != AMPDU_STREAM_IN_PROGRESS)) {
< rc = -EPERM;
< break;
< }
< spin_unlock_bh(&priv->stream_lock);
< rc = mwl_fwcmd_create_ba(hw, stream, buf_size, vif);
< spin_lock_bh(&priv->stream_lock);
669,678c616,629
< if (!rc) {
< stream->state = AMPDU_STREAM_ACTIVE;
< } else {
< idx = stream->idx;
< spin_unlock_bh(&priv->stream_lock);
< mwl_fwcmd_destroy_ba(hw, idx);
< spin_lock_bh(&priv->stream_lock);
< mwl_fwcmd_remove_stream(hw, stream);
< wiphy_err(hw->wiphy,
< "ampdu operation error code: %d\n", rc);
---
> case IEEE80211_AMPDU_TX_OPERATIONAL:
> if (hw != NULL && addr != NULL) {
> spin_lock(&priv->stream_lock);
> stream = mwl_fwcmd_lookup_stream(hw, addr, tid);
> if (stream != NULL) {
> if (mwl_fwcmd_create_ba(hw, stream, buf_size, vif) != NULL) {
> stream->state = AMPDU_STREAM_ACTIVE;
> } else {
> idx = stream->idx;
> mwl_fwcmd_destroy_ba(hw, idx);
> stream = NULL;
> }
> }
> spin_unlock(&priv->stream_lock);
680a632
>
683d634
< break;
685,686d635
<
< spin_unlock_bh(&priv->stream_lock);
diff -r original_CC_branch/tx.c updated_CC_branch/tx.c
347,373d346
< static inline void mwl_tx_count_packet(struct ieee80211_sta *sta, u8 tid)
< {
< struct mwl_sta *sta_info;
< struct mwl_tx_info *tx_stats;
<
< if (WARN_ON(tid >= SYSADPT_MAX_TID))
< return;
<
< sta_info = mwl_dev_get_sta(sta);
<
< tx_stats = &sta_info->tx_stats[tid];
<
< if (tx_stats->start_time == 0)
< tx_stats->start_time = jiffies;
<
< /* reset the packet count after each second elapses. If the number of
< * packets ever exceeds the ampdu_min_traffic threshold, we will allow
< * an ampdu stream to be started.
< */
< if (jiffies - tx_stats->start_time > HZ) {
< tx_stats->pkts = 0;
< tx_stats->start_time = 0;
< } else {
< tx_stats->pkts++;
< }
< }
<
836,844d808
< /* Queue ADDBA request in the respective data queue. While setting up
< * the ampdu stream, mac80211 queues further packets for that
< * particular ra/tid pair. However, packets piled up in the hardware
< * for that ra/tid pair will still go out. ADDBA request and the
< * related data packets going out from different queues asynchronously
< * will cause a shift in the receiver window which might result in
< * ampdu packets getting dropped at the receiver after the stream has
< * been setup.
< */
847c811
<
---
>
873d836
< mwl_tx_count_packet(sta, tid);
875c838
< spin_lock_bh(&priv->stream_lock);
---
> spin_lock(&priv->stream_lock);
877,888c840,842
<
< if (stream) {
< if (stream->state == AMPDU_STREAM_ACTIVE) {
< if (WARN_ON(!(qos &
< MWL_QOS_ACK_POLICY_BLOCKACK))) {
< spin_unlock_bh(&priv->stream_lock);
< dev_kfree_skb_any(skb);
< return;
< }
<
< txpriority =
< (SYSADPT_TX_WMM_QUEUES + stream->idx) %
---
> if (stream != NULL && stream->state == AMPDU_STREAM_ACTIVE) {
> WARN_ON(!(qos & MWL_QOS_ACK_POLICY_BLOCKACK));
> txpriority = (SYSADPT_TX_WMM_QUEUES + stream->idx) %
890,923d843
< } else if (stream->state == AMPDU_STREAM_NEW) {
< /* We get here if the driver sends us packets
< * after we've initiated a stream, but before
< * our ampdu_action routine has been called
< * with IEEE80211_AMPDU_TX_START to get the SSN
< * for the ADDBA request. So this packet can
< * go out with no risk of sequence number
< * mismatch. No special handling is required.
< */
< } else {
< /* Drop packets that would go out after the
< * ADDBA request was sent but before the ADDBA
< * response is received. If we don't do this,
< * the recipient would probably receive it
< * after the ADDBA request with SSN 0. This
< * will cause the recipient's BA receive window
< * to shift, which would cause the subsequent
< * packets in the BA stream to be discarded.
< * mac80211 queues our packets for us in this
< * case, so this is really just a safety check.
< */
< wiphy_warn(hw->wiphy,
< "can't send packet during ADDBA\n");
< spin_unlock_bh(&priv->stream_lock);
< dev_kfree_skb_any(skb);
< return;
< }
< } else {
< if (mwl_fwcmd_ampdu_allowed(sta, tid)) {
< stream = mwl_fwcmd_add_stream(hw, sta, tid);
<
< if (stream)
< start_ba_session = true;
< }
925,926c845
<
< spin_unlock_bh(&priv->stream_lock);
---
> spin_unlock(&priv->stream_lock);
933,936d851
< tx_ctrl->vif = (void *)tx_info->control.vif;
< tx_ctrl->sta = (void *)sta;
< tx_ctrl->k_conf = (void *)k_conf;
< tx_ctrl->amsdu_pkts = NULL;
938d852
< tx_ctrl->type = (mgmtframe ? IEEE_TYPE_MANAGEMENT : IEEE_TYPE_DATA);
939a854
> tx_ctrl->type = (mgmtframe ? IEEE_TYPE_MANAGEMENT : IEEE_TYPE_DATA);
940a856,858
> tx_ctrl->sta = (void *)sta;
> tx_ctrl->vif = (void *)mwl_vif;
> tx_ctrl->k_conf = (void *)k_conf;
943,945c861,863
< ieee80211_stop_queue(hw, SYSADPT_TX_WMM_QUEUES - index - 1);
<
< skb_queue_tail(&priv->txq[index], skb);
---
> dev_kfree_skb_any(skb);
> else
> skb_queue_tail(&priv->txq[index], skb);
948,955d865
<
< /* Initiate the ampdu session here */
< if (start_ba_session) {
< spin_lock_bh(&priv->stream_lock);
< if (mwl_fwcmd_start_stream(hw, stream))
< mwl_fwcmd_remove_stream(hw, stream);
< spin_unlock_bh(&priv->stream_lock);
< }
Here is the iperf without the patch, (top is TCP, bottom is UDP):
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.2.227, port 4387
[ 5] local 192.168.2.1 port 5201 connected to 192.168.2.227 port 4388
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 9.78 MBytes 82.0 Mbits/sec
[ 5] 1.00-2.00 sec 2.84 MBytes 23.8 Mbits/sec
[ 5] 2.00-3.00 sec 5.79 MBytes 48.6 Mbits/sec
[ 5] 3.00-4.00 sec 13.1 MBytes 110 Mbits/sec
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 5.00-6.00 sec 8.70 MBytes 72.9 Mbits/sec
[ 5] 6.00-7.00 sec 12.2 MBytes 102 Mbits/sec
[ 5] 7.00-8.01 sec 14.0 MBytes 117 Mbits/sec
[ 5] 8.01-9.00 sec 15.1 MBytes 127 Mbits/sec
[ 5] 9.00-10.02 sec 15.0 MBytes 123 Mbits/sec
[ 5] 10.02-10.17 sec 2.50 MBytes 137 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-10.17 sec 99.1 MBytes 81.8 Mbits/sec sender
[ 5] 0.00-10.17 sec 98.9 MBytes 81.6 Mbits/sec receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.2.227, port 4390
[ 5] local 192.168.2.1 port 5201 connected to 192.168.2.227 port 54852
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 488 KBytes 3.99 Mbits/sec 8.585 ms 55/116 (47%)
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 8.585 ms 0/0 (nan%)
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 8.585 ms 0/0 (nan%)
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 8.585 ms 0/0 (nan%)
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 8.585 ms 0/0 (nan%)
[ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 8.585 ms 0/0 (nan%)
[ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 8.585 ms 0/0 (nan%)
[ 5] 7.00-8.00 sec 72.0 KBytes 590 Kbits/sec 11.928 ms 0/9 (0%)
[ 5] 8.00-9.00 sec 120 KBytes 983 Kbits/sec 4.793 ms 0/15 (0%)
[ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 1.961 ms 0/16 (0%)
[ 5] 10.00-10.21 sec 24.0 KBytes 943 Kbits/sec 1.685 ms 0/3 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.21 sec 1.24 MBytes 1.02 Mbits/sec 1.685 ms 55/159 (35%)
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Here is the iperf with the patch, (top is TCP, bottom is UDP):
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.2.227, port 3821
[ 5] local 192.168.2.1 port 5201 connected to 192.168.2.227 port 3822
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 8.82 MBytes 73.9 Mbits/sec
[ 5] 1.00-2.00 sec 12.3 MBytes 103 Mbits/sec
[ 5] 2.00-3.00 sec 13.1 MBytes 110 Mbits/sec
[ 5] 3.00-4.00 sec 13.8 MBytes 116 Mbits/sec
[ 5] 4.00-5.00 sec 9.27 MBytes 77.7 Mbits/sec
[ 5] 5.00-6.00 sec 11.1 MBytes 92.8 Mbits/sec
[ 5] 6.00-7.00 sec 10.8 MBytes 90.3 Mbits/sec
[ 5] 7.00-8.00 sec 15.1 MBytes 127 Mbits/sec
[ 5] 8.00-9.00 sec 15.2 MBytes 127 Mbits/sec
[ 5] 9.00-10.00 sec 13.5 MBytes 114 Mbits/sec
[ 5] 10.00-10.16 sec 2.03 MBytes 108 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-10.16 sec 125 MBytes 103 Mbits/sec sender
[ 5] 0.00-10.16 sec 125 MBytes 103 Mbits/sec receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.2.227, port 3824
[ 5] local 192.168.2.1 port 5201 connected to 192.168.2.227 port 61645
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 312 KBytes 2.55 Mbits/sec 3.385 ms 0/39 (0%)
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 3.385 ms 0/0 (nan%)
[ 5] 2.00-3.00 sec 48.0 KBytes 394 Kbits/sec 3.913 ms 0/6 (0%)
[ 5] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 1.531 ms 0/16 (0%)
[ 5] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 0.718 ms 0/16 (0%)
[ 5] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 0.596 ms 0/16 (0%)
[ 5] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 0.401 ms 0/16 (0%)
[ 5] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 0.384 ms 0/16 (0%)
[ 5] 8.00-9.00 sec 120 KBytes 983 Kbits/sec 0.342 ms 0/15 (0%)
[ 5] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 0.396 ms 0/16 (0%)
[ 5] 10.00-10.20 sec 24.0 KBytes 968 Kbits/sec 0.359 ms 0/3 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.20 sec 1.24 MBytes 1.02 Mbits/sec 0.359 ms 0/159 (0%)
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
Can you let me know what client and configuration (setting on WRT1900AC or WRT1200AC) you use?
For WRT1200AC (2x2) and Macbook Air (2x2), 10.3.0.10 can get 4xx to 5xx Mbps for UDP/TCP (5 pairs) tests on 5g (channel 149 80 MHz).
BTW, can you cat "/sys/kernel/debug/ieee80211/phy0/mwlwifi/ampdu" and "/sys/kernel/debug/ieee80211/phy1/mwlwifi/ampdu" for me?
Thanks.
from mwlwifi.
notnyt
commented on August 16, 2024
A 2008 unibody macbook generates the errors listed. This information was provided in the original bug report. I cannot even run a speed test properly the performance is so poor. Other devices, my LG G4 for example, do not seem to have that issue. It seems to be related to ampdu and the macbook. As @TireMeat suggested, the code may need some improvement in that area.
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
I think it could be IOT problem. I will check it later. Thanks.
from mwlwifi.
johnnysl
commented on August 16, 2024
i have a V2 in a 90% apple household (Ipad2, mac mini, macbook air 2011, iphone 5, iphone 5s, HP folio 9470m). seeing the same errors as notnyt sees, but not the huge performance impact. After a certain amount of data transferred the errors start to appear and performance drops to about 10mbit per client (regardless of client type).
If i have to say, the HP (with a centrino advanced-n 6235) is causing more grief. especially when used at the edges of the reception range.
@TireMeat: would it be possible to supply a compiled driver that is compatible the the 15.05 final release? i could then test the influence of the changes on my situation with the V2.
from mwlwifi.
TireMeat
commented on August 16, 2024
A few weeks back I had my two iPhones (with Apple network stacks) disconnect and generally misbehave, and came across Adrian's post here (http://adrianchadd.blogspot.com/2012/10/power-save-cabq-multicast-frames-eapol.html) ... this is what made me think the packet sequencing logic in mwlwifi (specifically in the tx xmit and mac80211 ampdu action functions) may be (or come to be) at odds in certain scenarios (like power save and beam shape) with the logic within the (full-mac) firmware. Remember, these mwlwifi drivers were based off of an early Marvell product, and it could well be that product may not have been as full-featured as this one (88W8864) -- meaning, there may be driver code that's redundant. I've looked for tech docs, SDK (usually these contain code samples or at least calls), etc. for the 88W8864 but these aren't available without contacting product sales folks or something.
@johnnysl -- will put one together.
from mwlwifi.
TireMeat
commented on August 16, 2024
@johnnysl --- sorry mate, just saw you had a v2. I don't have that version, just a couple of v1s. The binary I have won't work for you.
from mwlwifi.
TireMeat
commented on August 16, 2024
@yuhhaurlin --- you're seeing 4-5Mbps UDP? (1Mbps I got does seem low indeed)
Also, not sure if you were addressing Rob or me in wanting to see the configs -- just in case me, I don't have an ampdu in my ieee80211 path - my path looks like this:
root@WRT1900:/sys/kernel/debug/ieee80211/phy1# pwd
/sys/kernel/debug/ieee80211/phy1
root@WRT1900:/sys/kernel/debug/ieee80211/phy1# ls
fragmentation_threshold netdev:wlan1 statistics
ht40allow_map power total_ps_buffered
hwflags queues user_power
keys rts_threshold wep_iv
long_retry_limit short_retry_limit
root@WRT1900:/sys/kernel/debug/ieee80211/phy1#
Here's my config:
root@WRT1900:/etc/config# cat wireless
config wifi-device 'radio0'
option type 'mac80211'
option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
option htmode 'HT20'
option country 'US'
option channel '4'
option txpower '30'
option hwmode '11n'
config wifi-iface
option device 'radio0'
option network 'lan'
option mode 'ap'
option encryption 'psk2+ccmp'
option key '{edited out}'
option ssid 'O2'
config wifi-device 'radio1'
option type 'mac80211'
option path 'soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0'
option htmode 'VHT80'
option country 'US'
option hwmode '11ac'
option txpower '17'
option channel '36'
config wifi-iface
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'O5'
option encryption 'psk2+ccmp'
option key '{edited out}'
from mwlwifi.
johnnysl
commented on August 16, 2024
@TireMeat , shouldn't the V1 and V2 use the same wifi driver?
from mwlwifi.
TireMeat
commented on August 16, 2024
@johnnysl -- the code is the same, as is the wifi's firmware, but the resulting ko binaries are different -- v1 is mamba, the v2 is cobra. At best the wifi won't work on initialize, in which case you'll be able to restore with a wired-in connection. Likely, the kernel will panic so fast on boot that you won't be able to recover without restoring the firmware using the TFTP method or something like that. It's really not worth the risk.
I could cross-build it for v2, but have no way to test it -- you'd be right back to running unknown kernel code.
Maybe one of the guys has a v2 setup and can patch the 10.3.0.10 code, build & test.
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@johnnysl : Did you try 10.3.0.10? We find 10.3.0.10 has IOT problem with few clients.
- Maybe you need to specify -b for UDP test.
- The speed depends on band, antenna and bandwidth. If you use 3x3, the speed will be higher. But if your client is 1x1, the speed is lower (except that the client had IOT problem with 10.3.0.10).
BTW, does anyone still see lock up or crash problem on 10.3.0.10?
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@TireMeat: debugfs is supported on 10.3.0.10.
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin can't test for lockups since I can't get a number of my clients online. Can you describe the IOT problem?
iperf in udp mode is default 1mbps, that said he was showing loss at this speed. You can specify a rate with -b 100M for 100mbps.
from mwlwifi.
TireMeat
commented on August 16, 2024
I reran iperf with "-u -b 0" options on my client against the patched 10.3.0.10, and results vary between 400-500Mbps. This is the same client connected to the 5Ghz phy as I'd submitted earlier, (much better than 1Mbps -- thanks for the tip on iperf !!!) Is it consistent with what you guys are seeing/supposed to see?
Lockup-wise, I've not seen any with the stock 10.3.0.10 yet.
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.2.227, port 1100
[ 5] local 192.168.2.1 port 5201 connected to 192.168.2.227 port 63389
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 12.8 MBytes 107 Mbits/sec 0.159 ms 219/1851 (12%)
[ 5] 1.00-2.00 sec 23.9 MBytes 201 Mbits/sec 0.157 ms 4112/7173 (57%)
[ 5] 2.00-3.00 sec 52.7 MBytes 442 Mbits/sec 0.443 ms 578/7320 (7.9%)
[ 5] 3.00-4.00 sec 52.0 MBytes 436 Mbits/sec 0.977 ms 407/7057 (5.8%)
[ 5] 4.00-5.00 sec 52.6 MBytes 441 Mbits/sec 0.704 ms 378/7113 (5.3%)
[ 5] 5.00-6.00 sec 52.9 MBytes 444 Mbits/sec 0.335 ms 341/7111 (4.8%)
[ 5] 6.00-7.00 sec 52.6 MBytes 441 Mbits/sec 0.206 ms 507/7240 (7%)
[ 5] 7.00-8.00 sec 48.0 MBytes 403 Mbits/sec 0.207 ms 534/6683 (8%)
[ 5] 8.00-9.00 sec 45.7 MBytes 384 Mbits/sec 0.259 ms 1390/7244 (19%)
[ 5] 9.00-10.00 sec 53.7 MBytes 451 Mbits/sec 0.176 ms 409/7287 (5.6%)
[ 5] 10.00-10.52 sec 12.1 MBytes 197 Mbits/sec 6.851 ms 72/1619 (4.4%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.52 sec 529 MBytes 422 Mbits/sec 6.851 ms 8947/67698 (13%)
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
from mwlwifi.
notnyt
commented on August 16, 2024
UDP mode is not useful for measuring throughput, only packet loss really. You can specify a given throughput, then observe packet loss.
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@TireMeat : I think 10.3.0.10 has no problem with your client. For TCP, you can use -w to change window size and -P to specify more sessions.
from mwlwifi.
TireMeat
commented on August 16, 2024
@yuhhaurlin -- agreed. Same client against D825 and WNDR4300, both running stock BB, the iperf tool reports (that 10.3.0.10 driver with CC branch is) roughly 2x performance increase in TCP, 3-4x in UDP (similar packet loss). I'm happy. :-)
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin so what exactly is the IOT issue?
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@notnyt Like what you described here.
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin what is IOT?
from mwlwifi.
johnnysl
commented on August 16, 2024
@yuhhaurlin I simply haven't had time to setup a compile system and figure out how to compile this driver for OpenWRT. With me a lot of others i guess. I'll see what i can do to compile this driver next weekend. Big scale testing would in my opinion massivly increase if binaries could be provided for all openwrt hw platforms (caiman, mamba, cobra, or shelby)
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
Sorry. Interoperability problem.
from mwlwifi.
kristrev
commented on August 16, 2024
@yuhhaurlin I saw one lockup of 5GHz. The router is used in production, so it was rebooted before I managed to copy/paste the error message. But it was something like "Could not add key to hardware". Result was that no clients could connect to 5GHz and I had to reboot router to get it working again.
I will make sure router is not rebooted before I can capture the message if I see it again.
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@kristrev It happened on 10.3.0.10?
from mwlwifi.
kristrev
commented on August 16, 2024
@yuhhaurlin Yes. However, I don't know if the issue was present in the older drivers or not, as I experienced a lockup/crash pretty fast. It happened after an uptime of about a day or so.
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@kristrev Please get log for me if possible. We had done 5 clients test here for about 5 days and can't find this kind of problem. BTW, can you let me know what clients you used?
from mwlwifi.
kristrev
commented on August 16, 2024
@yuhhaurlin Ok, will do. I have got my own 1200AC now, so I can do some testing. It was an iPhone6s and a Lenovo X1 Carbon. I have connected both of them to the 5GHz to try to provoke this problem.
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@kristrev Thanks.
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin if you want to add any debugging for the interop issues, let me know, I can compile and get a build running very quickly.
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@notnyt Thanks. We will fix this kind of problem later. If needed, I will ask for your help.
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin thanks, hopefully this can be done soon as not working properly with Apple clients is a large fault.
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
Macbook Pro (updated version) and Macbook Air are working all right.
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin other apple clients are also affected, and non apple clients. It seems it may be broadcom chipset related.
"I am having same issues with MacBook Pro (Mid 2012 Retina)" from an earlier post, as well as other uses reporting the same issue here.
In my case, it's a BCM43XX, even in windows the problem exists, so is likely related to the broadcom chips.
PCI\VEN_14E4&DEV_432B&SUBSYS_008D106B&REV_01
from mwlwifi.
notnyt
commented on August 16, 2024
Another user with the same issue using an android phone:
https://forum.openwrt.org/viewtopic.php?pid=296797#p296797
from mwlwifi.
bmork
commented on August 16, 2024
@notnyt yup, that looks like the same issue. I have now reverted to 10.3.0.3 as I need a working access point, so I won't have more debug data. Just one observation: I did not have any problems with my laptop as a client. It has an Intel 802.11ac wlan card. The phone is an older Samsung Galaxy S3 with 802.11n only. Might be relevant?
And a request for the developers: Fixing 10 separate issues, many which probably are made up of long series of small changes, in one commit is not taking advantage of the full power of git. If you break this up in its logical small changes, then the rest of us would stand a chance trying to review it. At least we could bisect the result when it goes bananas, and you would have much better chances identifying the problem.
As it is now, the git log is pretty useless. We get a new driver version replacing the old one every second month and that's that....
Just my .2 €
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@notnyt Thanks for your information
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
@notnyt I am busy for some jobs. Once if this problem is fixed, I will update patch here and inform you to check it. Thanks for your help.
from mwlwifi.
notnyt
commented on August 16, 2024
@yuhhaurlin this bug needs addressing so that other users can begin testing the new driver. It seems to affect the majority of users.
from mwlwifi.
kristrev
commented on August 16, 2024
@yuhhaurlin The router has been stable for almost a week now, but today the earlier mentioned key error happened. What I see in dmesg is:
[476322.762953] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
[476322.769166] ieee80211 phy0: return code: 0x1122
[476322.773811] ieee80211 phy0: timeout: 0x1122
[476322.778472] ieee80211 phy0: failed execution
[476322.782891] wlan0: failed to set key (2, ff:ff:ff:ff:ff:ff) to hardware (-5)
Repeated over and over. 2.4 GHz works fine and the only way to get out of this state seems to be through a reboot. This problem is not limited to Apple devices, the client that caused the error this time was a Lenovo X1 Carbon 2. gen with an Intel Wireless-card (7260). I have also seen it with an iPhone 6s. If it matters, this error seems to happen right after the devices wake up. Of course that is when they try to connect to wifi again, but maybe there are some power-saving stuff in router or something.
from mwlwifi.
yuhhaurlin
commented on August 16, 2024
Thanks for your information.
from mwlwifi.
gufus
commented on August 16, 2024
It's in driver 10.3.0.10 too also.
:
from mwlwifi.
notnyt
commented on August 16, 2024
title updated
from mwlwifi.
gufus
commented on August 16, 2024
'k
from mwlwifi.
gufus
commented on August 16, 2024
I hope this is not causing the error
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=988402#988402
from mwlwifi.
notnyt
commented on August 16, 2024
@gufus has nothing to do with it.
from mwlwifi.
gufus
commented on August 16, 2024
'k
from mwlwifi.
TireMeat
commented on August 16, 2024
@gufus -- interrupt handling could have something to do with the stability of this driver. having looked through the code, i've seen a few areas where there could be re-entrant problems -- moving code fragments (like these mwlwifi kernel modules representing the different radios) to different cores with the SMP affinity stuff, and giving the the kernel a larger address space to work with, sometimes has the effect of masking these kinds of problems.
One thing I noticed from some of the folks on the forum, is they're copying the *.ko binary files into lib as if these were windows DLLs -- this code has compile time macros that could generate slightly different object files depending on which menuconfig items chosen (like debug stuff, or if these were built against the same kernel source). This method of trying out drivers is not a good idea -- my suspicion is that the reason the stock 10.3.0.3 is more "stable" is because it was built from branch, and that's what most folks are running.
The tweaks you mentioned help, but are not the root cause -- they won't hurt.
@yuhhaurlin -- 10.3.0.10 is still stable and performing well for me, having run it in a heavy VoIP, streaming and file transfers all week. I got just a dozen or so of the "ieee80211 phy1: check ba result error 1" and "ieee80211 phy1: ampdu start error code: -22" without any negative side effects. One question I have, where should I look to see how UDP packets (WMM et al) are received? (I heard some strange (minor) distortion during the week)
I'm still coming up to speed with the stack and understanding the standard, but making progress -- (it's been 20 years since I looked at device driver code, and first time at network driver code :-))
from mwlwifi.
notnyt
commented on August 16, 2024
@TireMeat I've built the driver along with openwrt, the driver is broken because it has interoperability issues with some hardware. It has the same issues as 10.3.0.8, and a number of people are experiencing this trouble. The clients that generate the ampdu errors have awful performance, so you might want to track down which those are and investigate further.
from mwlwifi.
johnnysl
commented on August 16, 2024
@notnyt i even see the same -22 error you are posting in the final CC version, which uses 10.3.0.3.
I've build a trunk release last night with the latest driver. Wil give it a try today.
edit:
Running OpenWrt Designated Driver with driver version 10.3.0.10 now.
immediate findings:
While a laptop with Intel centrino Advanced-n 6235 works flawlessly, a mid 2012 macbook air (which uses a broadcom BCM4322 chip) negotiates terrible slow link speeds (negotiated speed varies between 1 and 6mbit/sec), causing an unusable slow network connection.
Can't find any errors in the kernel log (yet)
Edit 2:
After a while the kernel log is completly floaded with these:
Sat Oct 24 17:21:05 2015 kern.err kernel: [ 5601.602534] ieee80211 phy0: ampdu start error code: -22
Sat Oct 24 17:21:05 2015 kern.err kernel: [ 5601.637635] ieee80211 phy0: check ba result error 1
Sat Oct 24 17:31:26 2015 kern.err kernel: [ 6222.253363] ieee80211 phy1: ampdu start error code: -22
Sat Oct 24 17:31:26 2015 kern.err kernel: [ 6222.298444] ieee80211 phy1: check ba result error 1
Devices currently active:
Workable:
Laptop, Windows 7: Intel centrino advanced-n 6235
IPad air 2, IOS 9.1: Murata 339S02541 (likely Broadcom BCM433X, but not 100% sure)
Unworkable:
Macbook air mid 2012, Osx 10.11.1: broadcom BCM4322
iPhone 5, IOS 9.1: Murata 339S0171 (based on Broadcom BCM4334)
from mwlwifi.
gufus
commented on August 16, 2024
FYI
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=989061&sid=0668c8cf0eb57a5a8930c16f5518b83b#989061
from mwlwifi.
TireMeat
commented on August 16, 2024
@gufus ... if you have a V1 (mamba), can you run this image and post your dmesg / syslog? https://www.dropbox.com/s/c2zygbskixsd4dj/openwrt-mvebu-armada-xp-linksys-mamba-squashfs-sysupgrade.tar?dl=0
(make your log size like 4096 or so)
from mwlwifi.
gufus
commented on August 16, 2024
Yes, I have 2 Mamba's
Well, I could.
But, what's so special with your build?
from mwlwifi.
TireMeat
commented on August 16, 2024
It runs 10.3.0.10 in branch, and adds these to the logs:
[ 3934.620577] ieee80211 phy0: check ba result OK 0
[ 3934.625240] ieee80211 phy0: check ba header cmd 37157
[ 3934.630332] ieee80211 phy0: check ba header len 51
[ 4024.062203] ieee80211 phy1: check ba result OK 0
[ 4024.066863] ieee80211 phy1: check ba header cmd 37157
[ 4024.071956] ieee80211 phy1: check ba header len 51
[ 4450.726338] ieee80211 phy1: check ba result OK 0
[ 4450.731000] ieee80211 phy1: check ba header cmd 37157
[ 4450.736093] ieee80211 phy1: check ba header len 51
from mwlwifi.
gufus
commented on August 16, 2024
@TireMeat
I'll think about it, both my Mamba's are stable right now.
openwrt and dd-wrt fw.
from mwlwifi.
Related Issues (20)
- a2fd00b breaks 802.11r AP roaming HOT 3
- Inconsistent Wi-Fi - WRT3200ACM HOT 2
- WPA3 could crash/hang the router (WRT3200ACM) HOT 43
- Poor performance and poor stability wrt1900acs v2 HOT 19
- Can not initial the firmware(88W8864)
- Embed wifi PCB unable to connect to any AP , openwrt,ddwrt etc. HOT 10
- 2.4G wifi relay very low tx speed HOT 1
- McDebian connection rate so high HOT 20
- anybody having issues since OpenWrt v21-rc1 on Linksys WRT 3200ACM/WRT32X with WIFI HOT 4
- Espressobin ultra wifi hang or bug with OpenWrt 21.02-RC HOT 2
- OpenWrt 21.02 Kernel Panic
- kernel panics with OpenWRT 21.x snapshots HOT 6
- Newer Linux kernel kconfig issue HOT 3
- Strange connection loose on WRT1200ac v1 HOT 12
- Do we support manually setting MCS? HOT 2
- `radio1` gets disabled when there's two enabled SSID on it HOT 2
- Lost Broadcast Traffic with `per_sta_vif`
- mwlwifi: version 10.3.9.0-20230311 disconnection issue HOT 23
- wrt1900acs v2 no wifi access
- About add last driver to custom build HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mwlwifi.