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

[Oleksij Rempel <linux@rempel-privat.de>]

Am 19.04.2014 13:49, schrieb Harshal Vora:
> 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.

Hi, suddenly i can't help you here. kmemleak is probably good start in
this case.
Are you sure it is not ARCH realted issue?

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


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140419/a5a73135/attachment.pgp