[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