linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Jean-Pierre TOSONI <jp.tosoni@acksys.fr>
Cc: "linux-wireless\@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: mac80211+ath9k AP fails to honour power save mode from client
Date: Fri, 20 Sep 2019 16:16:36 +0300	[thread overview]
Message-ID: <874l17jeff.fsf@tynnyri.adurom.net> (raw)
In-Reply-To: <AM4PR0101MB23055B57EF8BEBA8D478554CE4C80@AM4PR0101MB2305.eurprd01.prod.exchangelabs.com> (Jean-Pierre TOSONI's message of "Thu, 18 Jul 2019 14:52:05 +0000")

Jean-Pierre TOSONI <jp.tosoni@acksys.fr> writes:

> Context:
>
>  I am using one device in AP mode, the other in client mode.
>  The client uses wpa_supplicant to do *background scan to other channels that the data channel*.
>  I am running iperf (UDP) *from the AP* to the client.
>
>  My device is Cavium development board-based (Octeon III CPU), equipped with Compex WLE350NX.
>  It used to work correctly with kernel 3.18 and an old 2015 wireless backport.
>  Now I updated to kernel 4.9 and the wireless backport 4.19.32-1, the
> last one from the OpenWRT trunk. (previously I used
> backport-2017-11-01 with the same failure).
>
>  I am running wireshark with Airpcap to spy the wireless link.
>
> Problem:
>
>  When the client scans offchannel, it correctly sends nullfunc frames around the offchannel period, with the PM bit set then unset.
>
>  However, during this time, the AP continues to send data to the client.
>    
>  This results in a lot of lost frames, though I set the powersave buffers to high values on the AP side.
>
>
> After some research I saw that the same kind of problem was fixed [1]
> and even re-fixed, but since there where so many changes in the queue
> management, I cannot really compare his work and the current state of
> the driver.
>
> Any idea / patch / directions of research ?
>
> J.P. Tosoni - ACKSYS
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5519541d5a5f19893546883547e2f0f2e5934df7 

This an old report from July but sounds a pretty serious problem to me,
and power save problems are difficult to detect by normal users which
makes this even more important. Has anyone else noticed anything
similar?

Something which would help a lot is to bisect when the problem appeared.
For example, if you can connect your ath9k board to an x86 device you
could start testing upstream kernel releases[1] directly from git
(v3.18, v4.9, v4.19 and so on). With an upstream kernel release I mean a
release directly from Linus' tree:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

This way there are no out-of-tree patches applied, and we can also rule
out backports problems, which makes it easier to find the root cause.
Just first make sure you that you can reproduce the problem with the
upstream kernel so that you don't waste time bisecting which is not
there :)

First find what is the last working release ("good") and the first
release which has the bug ("bad"). This way it's a lot easier to find
the culprit and fix it.

You can checkout a specific release like this:

git checkout v4.9

And even better if you can then use git-bisect to find the actual commit
which broke it:

git bisect start
git bisect bad v4.12
git bisect good v4.11

https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html

Please do let me know how it goes, this issue should be fixed. Power
save problems are always tricky and cause bad user experience.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

      reply	other threads:[~2019-09-20 13:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-18 14:52 mac80211+ath9k AP fails to honour power save mode from client Jean-Pierre TOSONI
2019-09-20 13:16 ` Kalle Valo [this message]

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=874l17jeff.fsf@tynnyri.adurom.net \
    --to=kvalo@codeaurora.org \
    --cc=jp.tosoni@acksys.fr \
    --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).