[ath9k-devel] Adhoc mode and chip reset issue with tp link wn721n/ath9k_htc drivers

[Harshal Vora <harshal@amideeptech.com>]

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.
>>>>
>