Hi Oleksij, We have upgraded to kernel 3.14.0 Looks like the kernel upgrade has solved the chip reset issue, but we are facing a new issue. We get a stack trace as shown below and after that the RAM in the raspberry pi goes down gradually from 300MB to 2-3MB At this stage the OOM killer kills a few processes to get some free RAM, but then again the memory keeps going down and eventually the machine crashes. If required we can show you a graph of free memory on how it keeps decreasing. We are noticing this same behaviour in different raspberry pi's (both model A and model B) and all running identical kernel and same processes.
Apr 19 08:04:08 localhost kernel: [ 3720.478285] device wlan0-mon0 entered promiscuous mode Apr 19 08:04:15 localhost kernel: [ 3726.966336] net_ratelimit: 2 callbacks suppressed Apr 19 08:04:18 localhost ntpdate[4269]: adjust time server 120.88.47.10 offset 0.000133 sec Apr 19 08:04:25 localhost kernel: [ 3737.399383] wlan0: failed to move IBSS STA a0:f3:c1:2f:d4:34 to state 3 (-105) - keeping it anyway Apr 19 08:04:27 localhost kernel: [ 3738.510453] ------------[ cut here ]------------ Apr 19 08:04:27 localhost kernel: [ 3738.516737] WARNING: CPU: 0 PID: 2188 at kernel/workqueue.c:1393 __queue_work+0x21c/0x294() Apr 19 08:04:27 localhost kernel: [ 3738.528121] Modules linked in: nfnetlink_log nfnetlink ipv6 batman_adv arc4 ath9k_htc mac80211 ath9k_common ath9k_hw ath cfg80211 rfkill leds_gpio led_class spi_bcm2708 i2c_bcm2708 Apr 19 08:04:27 localhost kernel: [ 3738.549312] CPU: 0 PID: 2188 Comm: kworker/u2:0 Tainted: G W 3.14.0 #3 Apr 19 08:04:27 localhost kernel: [ 3738.560481] Workqueue: phy0 ieee80211_iface_work [mac80211] Apr 19 08:04:27 localhost kernel: [ 3738.567903] [<c0013f48>] (unwind_backtrace) from [<c001124c>] (show_stack+0x10/0x14) Apr 19 08:04:27 localhost kernel: [ 3738.579231] [<c001124c>] (show_stack) from [<c001f460>] (warn_slowpath_common+0x68/0x88) Apr 19 08:04:27 localhost kernel: [ 3738.590995] [<c001f460>] (warn_slowpath_common) from [<c001f49c>] (warn_slowpath_null+0x1c/0x24) Apr 19 08:04:27 localhost kernel: [ 3738.603597] [<c001f49c>] (warn_slowpath_null) from [<c0032e6c>] (__queue_work+0x21c/0x294) Apr 19 08:04:27 localhost kernel: [ 3738.615814] [<c0032e6c>] (__queue_work) from [<c0032f54>] (queue_work_on+0x5c/0x64) Apr 19 08:04:27 localhost kernel: [ 3738.627891] [<c0032f54>] (queue_work_on) from [<bf108660>] (ieee80211_rx_mgmt_probe_beacon+0x48c/0x648 [mac80211]) Apr 19 08:04:27 localhost kernel: [ 3738.643050] [<bf108660>] (ieee80211_rx_mgmt_probe_beacon [mac80211]) from [<bf108ca0>] (ieee80211_ibss_rx_queued_mgmt+0xf4/0x33c [mac80211]) Apr 19 08:04:27 localhost kernel: [ 3738.660660] [<bf108ca0>] (ieee80211_ibss_rx_queued_mgmt [mac80211]) from [<bf10a8c0>] (ieee80211_iface_work+0x1bc/0x2c4 [mac80211]) Apr 19 08:04:27 localhost kernel: [ 3738.677324] [<bf10a8c0>] (ieee80211_iface_work [mac80211]) from [<c00343c8>] (process_one_work+0x12c/0x36c) Apr 19 08:04:27 localhost kernel: [ 3738.691710] [<c00343c8>] (process_one_work) from [<c0034a50>] (worker_thread+0x118/0x3c4) Apr 19 08:04:27 localhost kernel: [ 3738.704512] [<c0034a50>] (worker_thread) from [<c003a248>] (kthread+0xbc/0xd8) Apr 19 08:04:27 localhost kernel: [ 3738.714114] [<c003a248>] (kthread) from [<c000e1f8>] (ret_from_fork+0x14/0x3c) Apr 19 08:04:27 localhost kernel: [ 3738.723646] ---[ end trace 73244bee8b3d23b5 ]--- Thanks, Regards, On 04/04/2014 06:29 PM, Oleksij Rempel wrote: > Am 04.04.2014 14:37, schrieb Harshal Vora: >> Hi Oleksij, >> >> When the chipset goes into sleep mode and cannot come back due to errors >> like "Chip reset failed", >> we do not get any traffic inflow or outflow on that interface. >> >> Is it safe to assume that when no traffic is visible on that interface, >> we can restart that interface. >> Is there any way to check that the device is in that particular failed >> state? > Only getting error log directly form FW will tell what exactly happens. > You will need solder TX and GND on the chip. > See https://wikidevi.com/wiki/AR9271 > >> ip link, ip addr, ifconfig all show that the link is UP, but tcpdump >> does not show any traffic. >> >> Regards, >> >> On 03/31/2014 02:40 PM, Harshal Vora wrote: >>> Hi Oleksij, >>> >>> I compared the initial few commits from wireless-testing repo with >>> 3.13.y branch of raspberry linux git repo. Seems like all of those >>> have been merged. >>> >>> I also specifically checked commits only for >>> /drivers/net/wireless/ath/ath9k folder and seems like they are also >>> present in the raspberry linux repo. >>> >>> So I assume all the changes should be there. >>> >>> If issues persist, then I will test with the wireless-testing repo as >>> well. >>> >>> Thanks, >>> Regards, >>> >>> On 03/31/2014 01:52 PM, Oleksij Rempel wrote: >>>> Am 31.03.2014 10:06, schrieb Harshal Vora: >>>>> Hi Oleksij, >>>>> >>>>> We will test with kernel version 3.13.7 and also the latest firmware. >>>> I assume we misunderstand each other. FW will work with older kernel >>>> versions and some bugs are fixed in 3.13. But only wireless-testing.git >>>> can detect some FW oopses, and has changes which may affect AdHock >>>> mode. >>>> I recommend you to use wireless-testing.git or at least try to >>>> cherry-peak this changes. >>>> > _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
