linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wojciech Dubowik <Wojciech.Dubowik@neratec.com>
To: Felix Fietkau <nbd@openwrt.org>
Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com,
	mcgrof@qca.qualcomm.com
Subject: Re: [PATCH 3.8 1/3] ath9k_hw: fix calibration issues on chainmask that don't include chain 0
Date: Mon, 11 Mar 2013 07:25:12 +0100	[thread overview]
Message-ID: <513D78C8.5020708@neratec.com> (raw)
In-Reply-To: <5139DCAA.8050003@openwrt.org>

On 03/08/2013 01:42 PM, Felix Fietkau wrote:
> On 2013-03-08 10:46 AM, Wojciech Dubowik wrote:
>> On 03/08/2013 08:44 AM, Wojciech Dubowik wrote:
>>> On 03/07/2013 04:46 PM, Wojciech Dubowik wrote:
>>>> On 03/07/2013 03:59 PM, Felix Fietkau wrote:
>>>>> On 2013-03-07 3:31 PM, Wojciech Dubowik wrote:
>>>>>> There is a regression introduced by this patch when power save is
>>>>>> off on
>>>>>> the station for idle checks.
>>>>>> I have AR9590 station with rx and tx chain set to 0x1 connected
>>>>>> to legacy AP (based on Ar9390) with RF cable and 40dB attenuator.
>>>>>>
>>>>>> Before this patch in connection polling the station was properly
>>>>>> sending
>>>>>> null function to check whether AP is still there. After this patch
>>>>>> it sends
>>>>>> broadcast probe request which is anyway wrong or some 16 or so packets
>>>>>> of random data (rarely). It manifests itself in lost connection
>>>>>> because
>>>>>> there
>>>>>> is no ack from AP which is expected for null function.
>>>>>>
>>>>>> I have been following skb's up to the descriptor setting in ath9k
>>>>>> and it was
>>>>>> all ok i.e. proper null function with valid addresses.
>>>>>>
>>>>>> I have been bisecting it twice because it doesn't make much sense
>>>>>> but maybe
>>>>>> it's a HW issue?
>>>>> You're right, it does not make much sense. I can't figure out how this
>>>>> patch could possibly change the runtime behavior with tx chainmask set
>>>>> to 0x1. Have you tried reverting this patch in a current build to
>>>>> see if
>>>>> that fixes the issue?
>>>> It does fix it. I will check tomorrow whether it's only AR9590 or also
>>>> previous revisions. I will also try with different chainmasks. I will
>>>> have
>>>> to rescrew my setup...
>>>>
>>> I have been doing some tests and it seems to affect both AR9390 and
>>> AR9590.
>>> To summarize: sta doesn't send null function but broadcast probe
>>> request or
>>> corrupted frames in idle checking routine when power save is off and
>>> only some
>>> antennas are selected for transmission.
>>> So for example when I set antenna mask 7 i.e. all available it works
>>> ok but with
>>> mask 1, 3 or 6 not. When I swith power save it's all ok no matter what
>>> mask I use.
>>>
>>> Thing with power save on is that before it goes to idle check it will
>>> go to sleep since
>>> there is no traffic anyway, then we get beacon miss, it wakes up and
>>> it sends null
>>> function. I guess waking up is reinitializing sth in a chip which
>>> doesn't occur in my
>>> scenario.
>>> HW issue?
>> It will also work if I set user specified antenna masks instead of hw
>> capabilities.
> What do you mean with that? How do you set the rx and tx chainmasks if
> not via antenna masks? debugfs?
I do it with iw set antenna.
Wojtek

  reply	other threads:[~2013-03-11  6:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-20 20:55 [PATCH 3.8 1/3] ath9k_hw: fix calibration issues on chainmask that don't include chain 0 Felix Fietkau
2013-01-20 20:55 ` [PATCH 3.8 2/3] ath9k_hw: fix chain swap setting when setting rx chainmask to 5 Felix Fietkau
2013-01-20 20:55   ` [PATCH 3.8 3/3] ath9k: allow setting arbitrary antenna masks on AR9003+ Felix Fietkau
2013-01-20 22:05   ` [PATCH 3.8 2/3] ath9k_hw: fix chain swap setting when setting rx chainmask to 5 Adrian Chadd
2013-01-20 22:31     ` Felix Fietkau
2013-03-07 14:31 ` [PATCH 3.8 1/3] ath9k_hw: fix calibration issues on chainmask that don't include chain 0 Wojciech Dubowik
2013-03-07 14:59   ` Felix Fietkau
2013-03-07 15:46     ` Wojciech Dubowik
2013-03-08  7:44       ` Wojciech Dubowik
2013-03-08  9:46         ` Wojciech Dubowik
2013-03-08 12:42           ` Felix Fietkau
2013-03-11  6:25             ` Wojciech Dubowik [this message]
2013-03-11  9:43               ` Wojciech Dubowik
2013-03-15  0:01                 ` Felix Fietkau
2013-03-15  1:32                   ` Felix Fietkau
2013-03-15  7:06                     ` Wojciech Dubowik
2013-03-08 20:34       ` John W. Linville
2013-03-11  6:29         ` Wojciech Dubowik

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=513D78C8.5020708@neratec.com \
    --to=wojciech.dubowik@neratec.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mcgrof@qca.qualcomm.com \
    --cc=nbd@openwrt.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).