kaloz / mwlwifi

mac80211 driver for the Marvell 88W8864 802.11ac chip
395 stars 119 forks source link

Failed to reallocate TX buffer and DLNA steaming issue with latest 10.3.0.14 #52

Closed tangsoft closed 8 years ago

tangsoft commented 8 years ago

My box is wrt1900ac v1, complied with trunk version r47680.

BusyBox v1.24.1 (2015-11-30 21:05:54 CST) built-in shell (ash)


| |.-----.-----.-----.| | | |.----.| | | - || | -| || | | || || | |_____|| |___||||____||| |__| |__| W I R E L E S S F R E E D O M


DESIGNATED DRIVER (Bleeding Edge, r47680)


tangsoft commented 8 years ago

Here again. CPU stall?

BusyBox v1.24.1 (2015-11-30 21:05:54 CST) built-in shell (ash)


| |.-----.-----.-----.| | | |.----.| | | - || | -| || | | || || | |_____|| |___||||____||| |__| |__| W I R E L E S S F R E E D O M


DESIGNATED DRIVER (Bleeding Edge, r47680)


davidc502 commented 8 years ago

I believe this is related to #44

yuhhaurlin commented 8 years ago

I did not get any reports related to stall or memory leaking except for you. Can you let me know your test environment?

yuhhaurlin commented 8 years ago

I check in version 10.3.0.5-20151208. Please use this version to do test. You can check version information via "cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/info". This version is almost the same as previous latest commit except for changing spinlock to mutex for firmware command. I mark a formal release version, so you can make sure which version of driver is tested by you. Thanks.

tangsoft commented 8 years ago

Well, thank you, @yuhhaurlin, a 2T USB 2.5' hard disk attached to my wrt1900ac v1, /dev/sda1 10G mounted as extroot, /dev/sda2 as swap, the rest as /dev/sda3 for storage of transmissionbt downloading; firmware self compiled from trunk version with mod fs-ext4,block mount, bridge, tun and udp tunnel. Movie streaming on both my iPhone6 and Ipad4 by app named INFUSE over wireless 5G. 2.4G is terriblely slow and can not offer 1080P streaming. I experienced random jitters and sometimes wrt1900ac crashed and rebooted. The 5G performance via my late 2013 MacBook Pro is about 30mbytes per second. But stability is a big concern. Let me know if you need any else information.

yuhhaurlin commented 8 years ago

Can you test the latest one I commit, so you can check driver version?

tangsoft commented 8 years ago

Here is the mwlwifi version currently used, give me some time to test the one you mentioned.

~# cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/info

driver name: mwlwifi chip type: 88W8864 hw version: 7 driver version: 10.3.0.14 firmware version: 0x07020806 mac address: 00:25:9c:13:28:f5 2g: enable 5g: disable antenna: 4 4 irq number: 87 iobase0: d1000000 iobase1: d1200000 tx limit: 768 rx limit: 64 ap macid support: 0000ffff sta macid support: 00010000 macid used: 00000001 qe trigger number: 2515366 mfg mode: false

johnnysl commented 8 years ago

@yuhhaurlin, build 47680'is a build that contains the kernel panic fix, as uploaded by Kaloz to trunk. @tangsoft puzzle is that the version number didn't change the last few fixes. Just this morning yuhhaurlin uploaded some new fixes though and upgraded the driver to .15, with a date included. That should make each iteration of the .15 driver unique and aide in troubleshooting. As he mentioned above, might want to use the that latest driver, before doing any new testing.

BTW: if I understand above info correctly you've disabled the 5ghz interface completely? Not many here would do that. Maybe that houses a clue?

tangsoft commented 8 years ago

Ok, I am compiling the firmware with new .15 driver.

Just realized the 5G died itself over night. It is not disabled by me. PS: Just double checked, it is so weird, even the info shows 5G is disabled, but I am still able to connect to it.

johnnysl commented 8 years ago

@tangsoft: sorry my fault. This is just the info for interface phy0. Check phy1 and it should show it just the other way around. I wasn't fully awake yet :-)

tangsoft commented 8 years ago

@johnnysl, np, thanks for you guys hard work. my box got updated with .15 drive and same trunk version 47680. i will update with the test progress.

~# cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/info

driver name: mwlwifi chip type: 88W8864 hw version: 7 driver version: 10.3.0.15-20151208 firmware version: 0x07020806 mac address: 00:25:9c:13:28:f5 2g: enable 5g: disable antenna: 4 4 irq number: 87 iobase0: d1000000 iobase1: d1200000 tx limit: 768 rx limit: 64 ap macid support: 0000ffff sta macid support: 00010000 macid used: 00000001 qe trigger number: 76251 mfg mode: false

~# cat /sys/kernel/debug/ieee80211/phy1/mwlwifi/info

driver name: mwlwifi chip type: 88W8864 hw version: 7 driver version: 10.3.0.15-20151208 firmware version: 0x07020806 mac address: 00:25:9c:13:28:f6 2g: disable 5g: enable antenna: 4 4 irq number: 88 iobase0: d1400000 iobase1: d1600000 tx limit: 768 rx limit: 64 ap macid support: 0000ffff sta macid support: 00010000 macid used: 00000001 qe trigger number: 76461 mfg mode: false

tangsoft commented 8 years ago

@yuhhaurlin @johnnysl So far so good with .15 under trunk version 47680. no dmesg errors any more, DLNA streaming is much more smooth as well. Thanks. I will observe and test for more hours.

wongsyrone commented 8 years ago

Hi, I also have this issue, wrt1900ac v1 dmesg errors:

[201482.696427] ieee80211 phy1: failed to reallocate TX buffer
[201482.696477] ieee80211 phy0: failed to reallocate TX buffer
[201661.212525] ieee80211 phy1: failed to reallocate TX buffer
[201661.212574] ieee80211 phy0: failed to reallocate TX buffer
[251419.025524] ieee80211 phy0: check ba result error 1
[251419.030655] ieee80211 phy0: ampdu start error code: -22
[251419.065606] ieee80211 phy0: check ba result error 1
[251419.070680] ieee80211 phy0: ampdu start error code: -22

It takes about 3 days usage to get these error messages, and it seems to be triggered easily when streaming videos. I am using commit 352efe4bdc34204cc528ac9a979bb0032a6996e0 as kaloz commits before.

Here goes driver info

root@OpenWrt:~# cat /sys/kernel/debug/ieee80211/phy1/mwlwifi/info

driver name: mwlwifi
chip type: 88W8864
hw version: 7
driver version: 10.3.0.14
firmware version: 0x07020806
mac address: xxxxxxxxxxxx
2g: disable
5g: enable
antenna: 4 4
irq number: 88
iobase0: d1800000
iobase1: d1a00000
tx limit: 768
rx limit: 64
ap macid support: 0000ffff
sta macid support: 00010000
macid used: 00000001
qe trigger number: 13613611
mfg mode: false

root@OpenWrt:~# cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/info

driver name: mwlwifi
chip type: 88W8864
hw version: 7
driver version: 10.3.0.14
firmware version: 0x07020806
mac address: xxxxxxxxxxxx
2g: enable
5g: disable
antenna: 4 4
irq number: 87
iobase0: d1400000
iobase1: d1600000
tx limit: 768
rx limit: 64
ap macid support: 0000ffff
sta macid support: 00010000
macid used: 00000001
qe trigger number: 13613853
mfg mode: false

I will try the latest commit and report later.

wongsyrone commented 8 years ago

BTW, I also get these dmesg errors after long time getting failed to reallocate TX buffer and ampdu/ba errors, but I don't know whether it was triggered by mwlwifi or not, only for reference.

[171885.686636] logd: page allocation failure: order:1, mode:0x204020
[171885.692865] CPU: 0 PID: 1179 Comm: logd Not tainted 3.18.23 #1
[171885.698809] Backtrace: 
[171885.701387] [<c001c3ec>] (dump_backtrace) from [<c001c608>] (show_stack+0x18/0x1c)
[171885.709078]  r7:00000001 r6:00000000 r5:c048d9dc r4:00000000
[171885.714932] [<c001c5f0>] (show_stack) from [<c01974a4>] (dump_stack+0x88/0x98)
[171885.722293] [<c019741c>] (dump_stack) from [<c0090364>] (warn_alloc_failed+0x118/0x13c)
[171885.730414]  r5:00204020 r4:c0481008
[171885.734148] [<c0090250>] (warn_alloc_failed) from [<c0092608>] (__alloc_pages_nodemask+0x6dc/0x780)
[171885.743320]  r3:00000000 r2:00000000
[171885.747027]  r9:00000000 r8:00000001 r7:00000000 r6:00000000 r5:c0485400 r4:00000000
[171885.754990] [<c0091f2c>] (__alloc_pages_nodemask) from [<c00c05cc>] (cache_alloc_refill+0x30c/0x578)
[171885.764249]  r10:c0483950 r9:00000000 r8:00000000 r7:cf8b4740 r6:00000240 r5:cfa70ec0
[171885.772291]  r4:00000020
[171885.774958] [<c00c02c0>] (cache_alloc_refill) from [<c00c09a8>] (kmem_cache_alloc+0x78/0xdc)
[171885.783521]  r10:cd2b4bc0 r9:cd2b4bc0 r8:c0481008 r7:ce0fa640 r6:cf8b4740 r5:a0000113
[171885.791543]  r4:00000020
[171885.794219] [<c00c0930>] (kmem_cache_alloc) from [<c0285cf0>] (sk_prot_alloc+0x2c/0xec)
[171885.802346]  r7:ce0fa640 r6:00000020 r5:cf8b4740 r4:c04a08e0
[171885.808191] [<c0285cc4>] (sk_prot_alloc) from [<c02860a0>] (sk_clone_lock+0x20/0x1d0)
[171885.816144]  r7:ce0fa640 r6:cd2b4bc0 r5:cd1b21c0 r4:ce0fa640
[171885.821991] [<c0286080>] (sk_clone_lock) from [<c02d3c24>] (inet_csk_clone_lock+0x18/0x84)
[171885.830380]  r6:cd1b21c0 r5:cd1b21c0 r4:ce0fa640
[171885.835179] [<c02d3c0c>] (inet_csk_clone_lock) from [<c02eb754>] (tcp_create_openreq_child+0x1c/0x3c4)
[171885.844612]  r5:cd1b21c0 r4:ce0fa640
[171885.848337] [<c02eb738>] (tcp_create_openreq_child) from [<c02e8940>] (tcp_v4_syn_recv_sock+0x54/0x284)
[171885.857856]  r7:00000000 r6:cd1b21c0 r5:ce0fa640 r4:ce0fa640
[171885.863710] [<c02e88ec>] (tcp_v4_syn_recv_sock) from [<c02ebddc>] (tcp_check_req+0x2e0/0x5a8)
[171885.872361]  r10:cd2b4bc0 r9:b0401850 r8:cd1b21c0 r7:c0481008 r6:cdc07dec r5:c02e88ec
[171885.880383]  r4:ce0fa640
[171885.883055] [<c02ebafc>] (tcp_check_req) from [<c02e8cec>] (tcp_v4_do_rcv+0x17c/0x384)
[171885.891087]  r10:0000006c r9:cdc07dec r8:cdc07d80 r7:cdc07dd8 r6:cd2b4bc0 r5:c0481008
[171885.899118]  r4:ce0fa640
[171885.901776] [<c02e8b70>] (tcp_v4_do_rcv) from [<c02eadf0>] (tcp_v4_rcv+0x3c4/0x770)
[171885.909554]  r10:00001824 r9:0000c8e2 r8:cd2b4bc0 r7:cdc07dd8 r6:00000000 r5:c049eb80
[171885.917588]  r4:ce0fa640
[171885.920247] [<c02eaa2c>] (tcp_v4_rcv) from [<c02c7380>] (ip_local_deliver_finish+0xcc/0x1d8)
[171885.928809]  r10:00000000 r9:c0482348 r8:cd05c800 r7:00000000 r6:c0483204 r5:ce0fa640
[171885.936844]  r4:c04244bc
[171885.939504] [<c02c72b4>] (ip_local_deliver_finish) from [<c02c7970>] (ip_local_deliver+0x68/0xb4)
[171885.948501]  r7:c049eb80 r6:ce0fa640 r5:cdc07dd8 r4:ce0fa640
[171885.954355] [<c02c7908>] (ip_local_deliver) from [<c02c77ac>] (ip_rcv_finish+0x320/0x374)
[171885.962658]  r4:ce0fa640
[171885.965319] [<c02c748c>] (ip_rcv_finish) from [<c02c7d90>] (ip_rcv+0x3d4/0x4ac)
[171885.972750]  r7:c049eb80 r6:ce0fa640 r5:cdc07d80 r4:00000058
[171885.978597] [<c02c79bc>] (ip_rcv) from [<c02978ec>] (__netif_receive_skb_core+0x4d8/0x640)
[171885.986985]  r8:00000008 r7:c0482358 r6:c0483788 r5:ce0fa640 r4:c02c79bc
[171885.993902] [<c0297414>] (__netif_receive_skb_core) from [<c0299798>] (__netif_receive_skb+0x74/0x88)
[171886.003248]  r10:cfddaab0 r9:cfddaaa4 r8:00000040 r7:00000001 r6:cfddaa54 r5:0000000c
[171886.011270]  r4:cfddaab4
[171886.013940] [<c0299724>] (__netif_receive_skb) from [<c029a27c>] (process_backlog+0x94/0x164)
[171886.022590]  r5:0000000c r4:cfddaab4
[171886.026312] [<c029a1e8>] (process_backlog) from [<c0299ae4>] (net_rx_action+0x88/0x17c)
[171886.034439]  r10:cfddaa48 r9:c0480100 r8:00000040 r7:0000010f r6:cfddaab4 r5:cfddaa40
[171886.042469]  r4:00000001 r3:c029a1e8
[171886.046196] [<c0299a5c>] (net_rx_action) from [<c002b308>] (__do_softirq+0x10c/0x238)
[171886.054149]  r10:cda68000 r9:00000100 r8:40000001 r7:c0480088 r6:c048008c r5:00000003
[171886.062171]  r4:0000000c
[171886.064844] [<c002b1fc>] (__do_softirq) from [<c002b6d0>] (irq_exit+0xa0/0xb0)
[171886.072190]  r10:00000897 r9:00000769 r8:cf805000 r7:00000001 r6:00000000 r5:00000000
[171886.080223]  r4:c047c8f8
[171886.082895] [<c002b630>] (irq_exit) from [<c005be20>] (__handle_domain_irq+0x94/0xa4)
[171886.090840]  r5:00000000 r4:c047c8f8
[171886.094572] [<c005bd8c>] (__handle_domain_irq) from [<c00086d8>] (armada_370_xp_handle_irq+0x58/0xc8)
[171886.103919]  r9:00000769 r8:c0481048 r7:c04c4430 r6:cda69e40 r5:c04c4444 r4:c005ab50
[171886.111867] [<c0008680>] (armada_370_xp_handle_irq) from [<c00097e0>] (__irq_svc+0x40/0x54)
[171886.120345] Exception stack(0xcda69e40 to 0xcda69e88)
[171886.125528] 9e40: 00000bf1 00000000 c04a966c 0000622f 0000006f c04a7790 c04a525c c0489060
[171886.133845] 9e60: c04a9704 00000769 00000897 cda69f04 c04a9710 cda69e88 00293438 c005ab50
[171886.142142] 9e80: 20000013 ffffffff
[171886.145742]  r10:00000897 r9:00000769 r8:c04a9704 r7:cda69e74 r6:ffffffff r5:20000013
[171886.153777]  r4:c005ab50 r3:00293438
[171886.157504] [<c005a810>] (do_syslog) from [<c0115dbc>] (kmsg_read+0x34/0x5c)
[171886.164674]  r10:00000000 r9:cda68000 r8:00001000 r7:cf8b3400 r6:00000000 r5:00001000
[171886.172706]  r4:00a57040
[171886.175375] [<c0115d88>] (kmsg_read) from [<c010abf0>] (proc_reg_read+0x68/0x98)
[171886.182892]  r5:00000000 r4:c0115d88
[171886.186618] [<c010ab88>] (proc_reg_read) from [<c00c4548>] (vfs_read+0x90/0x14c)
[171886.194136]  r7:c010ab88 r6:cda69f70 r5:cf9531c0 r4:00a57040
[171886.199976] [<c00c44b8>] (vfs_read) from [<c00c4b58>] (SyS_read+0x5c/0xb8)
[171886.206972]  r9:cda68000 r8:00001000 r7:00a57040 r6:cf9531c0 r5:c0481008 r4:cf9531c0
[171886.214930] [<c00c4afc>] (SyS_read) from [<c0008ec0>] (ret_fast_syscall+0x0/0x38)
[171886.222536]  r8:c0009064 r7:00000003 r6:00a58050 r5:00000000 r4:00000000
[171886.229423] Mem-info:
[171886.231795] Normal per-cpu:
[171886.234701] CPU    0: hi:   90, btch:  15 usd:  14
[171886.239604] CPU    1: hi:   90, btch:  15 usd:  83
[171886.244527] active_anon:5708 inactive_anon:5789 isolated_anon:0
[171886.244527]  active_file:19248 inactive_file:20678 isolated_file:0
[171886.244527]  unevictable:0 dirty:0 writeback:0 unstable:0
[171886.244527]  free:949 slab_reclaimable:2120 slab_unreclaimable:4510
[171886.244527]  mapped:849 shmem:2917 pagetables:119 bounce:0
[171886.244527]  free_cma:0
[171886.276821] Normal free:3796kB min:2016kB low:2520kB high:3024kB active_anon:22832kB inactive_anon:23156kB active_file:76992kB inactive_file:82712kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:262144kB managed:255024kB mlocked:0kB dirty:0kB writeback:0kB mapped:3396kB shmem:11668kB slab_reclaimable:8480kB slab_unreclaimable:18040kB kernel_stack:552kB pagetables:476kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[171886.319153] lowmem_reserve[]: 0 0 0
[171886.322813] Normal: 865*4kB (UMR) 9*8kB (R) 10*16kB (R) 2*32kB (R) 1*64kB (R) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3820kB
[171886.335540] 42859 total pagecache pages
[171886.339480] 7 pages in swap cache
[171886.342907] Swap cache stats: add 146, delete 139, find 0/1
[171886.348590] Free swap  = 135636kB
[171886.352004] Total swap = 136188kB
[171886.361580] 65536 pages of RAM
[171886.364750] 1202 free pages
[171886.367646] 1780 reserved pages
[171886.370886] 4534 slab pages
[171886.373788] 169828 pages shared
[171886.377032] 7 pages swap cached
tangsoft commented 8 years ago

Being watching the box for a while, I can tell there is still something not right, let me know what I can do for troubleshooting.

Regularly from output of top command, a process named ksoftirqd consumes a large chunk of CPU and the DLNA streaming experiences a jitter.

2K cached Mem: 251280K used, 3848K free, 21408K shrd, 3088K buff, 190648K cached CPU: 0% usr 1% sys 0% nic 74% idle 7% io 0% irq 15% sirq Load average: 0.25 0.27 0.24 2/87 31494 PID PPID USER STAT VSZ %VSZ %CPU COMMAND 3 2 root SW 0 0% 1% [ksoftirqd/0] 402 2 root SW 0 0% 1% [usb-storage] 26375 1345 root S 13236 5% 1% /usr/bin/minidlna -f /tmp/minidlna.co 2053 1 root S 1560 1% 1% /usr/sbin/hostapd -P /var/run/wifi-ph 158 2 root SW 0 0% 0% [kswapd0] 1266 1 root S 1540 1% 0% /sbin/netifd 31442 2 root DW 0 0% 0% [kworker/0:0] 1839 1 root S 1560 1% 0% /usr/sbin/hostapd -P /var/run/wifi-ph 31489 31417 root R 1088 0% 0% top 1695 1266 root S 1060 0% 0% /usr/sbin/pppd nodetach ipparam wan i 7 2 root SW 0 0% 0% [rcu_sched] 11 2 root SW 0 0% 0% [ksoftirqd/1] 1345 1 root S 13272 5% 0% /usr/bin/minidlna -f /tmp/minidlna.co 1698 1 root S 12016 5% 0% /usr/sbin/asterisk 1506 1 root S 3844 2% 0% /usr/sbin/openvpn --syslog openvpn(ov 1507 1 root S 2876 1% 0% /usr/sbin/openvpn --syslog openvpn(ov 1465 1 root S 2676 1% 0% /usr/sbin/nmbd -F 1464 1 root S 2656 1% 0% /usr/sbin/smbd -F 1 0 root S 1364 1% 0% /sbin/procd 1379 1 root S 1348 1% 0% /usr/sbin/uhttpd

tangsoft commented 8 years ago

Overall, as far as I can tell, .15 improves the stability, less crash; but performance issue insists.

And tx buffer reallocate failure still happens but looks like less.

[25868.258656] ieee80211 phy0: failed to reallocate TX buffer [26707.461831] ieee80211 phy1: failed to reallocate TX buffer [27307.159178] ieee80211 phy0: failed to reallocate TX buffer [27307.164762] ieee80211 phy1: failed to reallocate TX buffer [27308.190824] ieee80211 phy0: failed to reallocate TX buffer [27308.196408] ieee80211 phy1: failed to reallocate TX buffer

yuhhaurlin commented 8 years ago

I think memory is gone. Can you try test from ethernet to wifi to see if you still encounter this problem?

johnnysl commented 8 years ago

@tangsoft: can you run a cat /proc/interrupts for me?

tangsoft commented 8 years ago

~# cat /proc/interrupts CPU0 CPU1
16: 7335444 7503802 armada_370_xp_irq 5 armada_370_xp_per_cpu_tick 18: 2739022 0 armada_370_xp_irq 31 mv64xxx_i2c 19: 21 0 armada_370_xp_irq 41 serial 25: 0 0 armada_370_xp_irq 45 ehci_hcd:usb1 26: 233292 0 armada_370_xp_irq 8 mvneta 27: 2388633 0 armada_370_xp_irq 10 mvneta 28: 0 0 armada_370_xp_irq 55 f10a0000.sata 29: 13890 0 armada_370_xp_irq 113 f10d0000.nand 69: 0 0 f1018140.gpio 0 gpio_keys 70: 0 0 f1018140.gpio 1 gpio_keys 87: 97999111 0 armada_370_xp_irq 59 mwlwifi 88: 100925205 0 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: 695048 0 armada_370_xp_msi_irq 0 xhci_hcd IPI0: 0 0 CPU wakeup interrupts IPI1: 0 0 Timer broadcast interrupts IPI2: 249048 1102014 Rescheduling interrupts IPI3: 0 0 Function call interrupts IPI4: 28193 1033613 Single function call interrupts IPI5: 0 0 CPU stop interrupts IPI6: 0 0 IRQ work interrupts IPI7: 0 0 completion interrupts Err: 0

Sent from my iPhone

On Dec 9, 2015, at 00:30, johnnysl notifications@github.com wrote:

@tangsoft: can you run a cat /proc/interrupts for me?

— Reply to this email directly or view it on GitHub.

johnnysl commented 8 years ago

@tangsoft, hmm had a hunch that you might have had mwlwifi and mvneta split across the cores. This actually looks ok. Never mind in this case

johnnysl commented 8 years ago

@yuhhaurlin: what do you mean with "memory is gone" could you explain a bit more?

yuhhaurlin commented 8 years ago

Free memory is gone.

johnnysl commented 8 years ago

So a memory leak? Why would it be gone? Your reply raises a lot of questions with me, in trying to understand why. Sorry for any dumb questions.

  1. Would running this at startup help to give the kernel a bit more memory? echo 16384 > /proc/sys/vm/min_free_kbytes
  2. Would it make sense for Tangsoft to track down what his memory usage is and what would be causing the high usage?
yuhhaurlin commented 8 years ago

From our internal stress test, we did not find this kind of problem. I check issue #44, the same test is done from ethernet to wifi. I check the reporter to do stress test to see if he encounter the same problem.

tangsoft commented 8 years ago

@yuhhaurlin, I don't have a DLNA streaming server on Ethernet. One thing to note, a typical scenario is attaching an USB disk and offer local DLNA service over wireless. And I have a HTPC which can play movies from samba shares of my box over Ethernet without any problem.

kylejvrsa commented 8 years ago

I think what yuhhaurlin is trying to say is that there seems to be an issue with attaching usb drive to the router and then it runs out of memory as one streams over time. So if the test could be done removing that scenario for now that would be great...no point in testing everything at once as it will be very difficult to determine what the problem is...rather test 1 bug at a time in this case being the wifi.

johnnysl commented 8 years ago

agree, i have issues with attaching local drives and running out of memory as well. Seems to be a general issue currently with the OpenWRT image

wongsyrone commented 8 years ago

The current minidlna in openwrt's package repository is 1.1.4, which probably has memory leak issue, I prefer compiling latest 1.1.5 yourself if you are familiar with buildroot. The minidlna project is located on SourceForge.

So far so good on my test with latest mwlwifi commit. On Dec 9, 2015 4:03 PM, "johnnysl" notifications@github.com wrote:

agree, i have issues with attaching local drives and running out of memory as well. Seems to be a general issue currently with the OpenWRT image

— Reply to this email directly or view it on GitHub https://github.com/kaloz/mwlwifi/issues/52#issuecomment-163145337.

yuhhaurlin commented 8 years ago

If this is the case, I think this issue should be closed.

wongsyrone commented 8 years ago

I will test more hours to observe wireless performance. Please be patient. Thanks. On Dec 9, 2015 4:50 PM, "yuhhaurlin" notifications@github.com wrote:

If this is the case, I think this issue should be closed.

— Reply to this email directly or view it on GitHub https://github.com/kaloz/mwlwifi/issues/52#issuecomment-163152903.

wongsyrone commented 8 years ago

I only get these ampdu/ba failure using commit c8165c47910169d6d73983b11743fa75941b5b76 after 21h 23m 45s,

[58339.780105] ieee80211 phy0: check ba result error 1
[58339.785100] ieee80211 phy0: ampdu start error code: -22
[58339.829785] ieee80211 phy0: check ba result error 1
[58339.834779] ieee80211 phy0: ampdu start error code: -22
[58339.869723] ieee80211 phy0: check ba result error 1
[58339.874727] ieee80211 phy0: ampdu start error code: -22

and

root@OpenWrt:~# cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/info

driver name: mwlwifi
chip type: 88W8864
hw version: 7
driver version: 10.3.0.15-20151208
firmware version: 0x07020806
mac address: xxxxxxxxxx
2g: enable
5g: disable
antenna: 4 4
irq number: 87
iobase0: d1400000
iobase1: d1600000
tx limit: 768
rx limit: 64
ap macid support: 0000ffff
sta macid support: 00010000
macid used: 00000001
qe trigger number: 3852270
mfg mode: false

root@OpenWrt:~# cat /sys/kernel/debug/ieee80211/phy1/mwlwifi/info

driver name: mwlwifi
chip type: 88W8864
hw version: 7
driver version: 10.3.0.15-20151208
firmware version: 0x07020806
mac address: xxxxxxxxxx
2g: disable
5g: enable
antenna: 4 4
irq number: 88
iobase0: d1800000
iobase1: d1a00000
tx limit: 768
rx limit: 64
ap macid support: 0000ffff
sta macid support: 00010000
macid used: 00000001
qe trigger number: 3852489
mfg mode: false

root@OpenWrt:~# cat /proc/interrupts
           CPU0       CPU1       
 16:    8570926    9214531  armada_370_xp_irq   5  armada_370_xp_per_cpu_tick
 18:    1952922          0  armada_370_xp_irq  31  mv64xxx_i2c
 19:         35          0  armada_370_xp_irq  41  serial
 25:          0          0  armada_370_xp_irq  45  ehci_hcd:usb1
 26:     779165          0  armada_370_xp_irq   8  mvneta
 27:    4230368          0  armada_370_xp_irq  10  mvneta
 28:          0          0  armada_370_xp_irq  55  f10a0000.sata
 29:      36493          0  armada_370_xp_irq 113  f10d0000.nand
 69:          0          0  f1018140.gpio   0  gpio_keys
 70:          0          0  f1018140.gpio   1  gpio_keys
 87:  108226545          0  armada_370_xp_irq  59  mwlwifi
 88:  108329062          0  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:     497259          0  armada_370_xp_msi_irq   0  xhci_hcd
IPI0:          0          0  CPU wakeup interrupts
IPI1:          0          0  Timer broadcast interrupts
IPI2:     295255     986073  Rescheduling interrupts
IPI3:          0          0  Function call interrupts
IPI4:      13694    1971354  Single function call interrupts
IPI5:          0          0  CPU stop interrupts
IPI6:          0          0  IRQ work interrupts
IPI7:          0          0  completion interrupts
Err:          0

BTW, I am using ffmpeg 2.8.3 and minidlna 1.1.5 compiled by myself.

davidc502 commented 8 years ago

I ran a stress test on 5Ghz and these are the results. The test ran for around 40 minutes.

5Ghz Mbps Input 5ghzmbpsin

Ram% Used ram-used

CPU% cpu-utilized

Core0 core0

Core1 core1

CPU Temperature cpu-temperature

The reason why core1 started getting higher was I added a 2nd device to the load test.

Let me know if there are questions?? Should I also do this for 2.4Ghz?

yuhhaurlin commented 8 years ago

No. It looks like mwlwifi driver is all right. The memory leaking is not happened in this driver. I close this issue.