From: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
To: ath9k-devel@lists.ath9k.org
Subject: [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.
WARNING: multiple messages have this Message-ID (diff)
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: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-18 8:12 [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS Nicolas Cavallari
2012-09-18 13:13 ` Nicolas Cavallari
2012-09-18 13:46 ` Sujith Manoharan
2012-09-18 13:46 ` Sujith Manoharan
2012-09-18 14:47 ` Nicolas Cavallari [this message]
2012-09-18 14:47 ` Nicolas Cavallari
2012-09-18 22:03 ` Sujith Manoharan
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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.