[FS#13] Ath9k AP stays up for connected clients but doesn't show in scan on new ones
LEDE Bugs
lede-bugs at lists.infradead.org
Sat Jan 28 06:18:28 PST 2017
The following task has a new comment added:
FS#13 - Ath9k AP stays up for connected clients but doesn't show in scan on new ones
User who did this - Johan van Zoomeren (amain)
----------
Thanks for the patches. But I don't think we're just there yet. I downloaded and tested snapshot r3189-12db207. Bidirectional iperf test shows stable throughput (40 mbit/s each direction), but after a while the kernel crashes. This is reproducible. Serial console output:
[ 1294.022551] ------------[ cut here ]------------
[ 1294.027247] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:306 dev_watchdog+0x1dc/0x260()
[ 1294.035754] NETDEV WATCHDOG: eth0 (ag71xx): transmit queue 0 timed out
[ 1294.042319] Modules linked in: ath9k ath9k_common pppoe ppp_async ath9k_hw ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nn
[ 1294.106287] CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.45 #0
[ 1294.112066] Stack : 803e4844 00000000 00000001 80440000 8042f1dc 8042ee63 803c5e64 00000000
804a378c 8042d4fc 00000200 00100000 0000000a 800a7618 803cb554 80430000
00000003 8042d4fc 803c9960 81809e34 0000000a 800a5594 00000006 00000000
00000000 801f5400 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
...
[ 1294.148122] Call Trace:
[ 1294.150617] [] vprintk_default+0x24/0x30
[ 1294.155474] [] printk+0x2c/0x38
[ 1294.159515] [] wait_for_xmitr+0x84/0xcc
[ 1294.164289] [] warn_slowpath_common+0xa0/0xd0
[ 1294.169564] [] dump_stack+0x14/0x28
[ 1294.173975] [] show_stack+0x50/0x84
[ 1294.178376] [] warn_slowpath_common+0xa0/0xd0
[ 1294.183661] [] dev_watchdog+0x1dc/0x260
[ 1294.188408] [] warn_slowpath_fmt+0x2c/0x38
[ 1294.193450] [] dev_watchdog+0x1dc/0x260
[ 1294.198191] [] dev_watchdog+0x0/0x260
[ 1294.202782] [] call_timer_fn.isra.5+0x24/0x80
[ 1294.208051] [] run_timer_softirq+0x1b4/0x1fc
[ 1294.213248] [] handle_irq_event_percpu+0x154/0x188
[ 1294.218960] [] __do_softirq+0x250/0x298
[ 1294.223721] [] handle_percpu_irq+0x50/0x80
[ 1294.228746] [] plat_irq_dispatch+0xd4/0x10c
[ 1294.233848] [] handle_int+0x134/0x140
[ 1294.238400]
[ 1294.239904] ---[ end trace 17bad011a41ccba7 ]---
[ 1294.244567] eth0: tx timeout
[ 1299.022570] eth0: tx timeout
[ 1304.022581] eth0: tx timeout
[ 1309.022588] eth0: tx timeout
And from there on the eth0: tx timeout line is repeated every 5 seconds. The fixes seem to have improved things a bit. But maybe the actual problem wasn't fixed and surfaces now in a different part? Or this is a new issue? Laptop still shows it is connected to the wifi, so the situation still seems to reflect current bug description.
----------
More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=13#comment1467
More information about the lede-bugs
mailing list