From: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
To: Sujith Manoharan <c_manoha@qualcomm.com>
Cc: ath9k-devel@lists.ath9k.org, linux-wireless@vger.kernel.org
Subject: Re: [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS.
Date: Tue, 18 Sep 2012 16:47:59 +0200 [thread overview]
Message-ID: <5058899F.1090906@lri.fr> (raw)
In-Reply-To: <20568.31520.887555.183389@gargle.gargle.HOWL>
On 18/09/2012 15:46, Sujith Manoharan wrote:
> Nicolas Cavallari wrote:
>> With an AR9382 (well, i think, its PCI-id is 168c:0030 rev 1/168c:3116),
>> each time I join an IBSS network, the driver repeatedly
>> resets the queue for a while, because of too many missed beacons. After
>> some time, this stops and the card behave normally. But many packets
>> are lost in the process.
>>
>> The problem seems to aggravate when the number of IBSS nodes is higher :
>> When joining a IBSS network with only one node, Only a few (e.g. 4)
>> beacons are lost, and no reset takes places. When joining an IBSS
>> network with two nodes, the queues can be reset up to 224 times in 20
>> seconds. When joining large IBSS networks, it sometimes never stop
>> resetting. Occasionally, when resetting, the driver fails to reset TX DMA
>>
>> If i hack the driver to not reset when the beacon is stuck, the beacon
>> tx resumes quickly by itself after 80-200 misses and the network seems
>> to work normally (if not better). On large&clogged ad-hoc networks, the
>> card sometimes miss between 1 and 80 beacons, but it might be due to
>> background scanning i think.
>>
>> What could be the problem here ? is ad-hoc beaconing kind of broken ?
>> I do not have the problem with AR9285.
>
> I think the problem is that we are programming the beacon timers based on
> the beacon interval right after joining, but we base it on the HW TSF which
> has just been reset. We should be updating the timers based on the TSF after a
> HW sync has been done with a received beacon. This is being done for station
> mode, but IBSS mode is missing this.
>
> Here is a very rough patch, it abuses STA-mode flags and doesn't differentiate
> between creator/joiner mode, but can you check if it makes any difference ?
With this patch, i see no beacon miss in the logs when joining a large
ad-hoc network. So yes, it does make a difference! haven't tested what
happens when creating an IBSS with or without this patch yet.
Thanks.
next prev parent reply other threads:[~2012-09-18 14:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <50582CF8.4020608@lri.fr>
[not found] ` <5058737E.4090601@lri.fr>
2012-09-18 13:46 ` [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS Sujith Manoharan
2012-09-18 14:47 ` Nicolas Cavallari [this message]
2012-09-18 22:03 ` Sujith Manoharan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5058899F.1090906@lri.fr \
--to=nicolas.cavallari@lri.fr \
--cc=ath9k-devel@lists.ath9k.org \
--cc=c_manoha@qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).