linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@openwrt.org>
To: Ben Greear <greearb@candelatech.com>
Cc: Sujith Manoharan <sujith@msujith.org>,
	ath9k-devel@venema.h4ckr.net, linux-wireless@vger.kernel.org
Subject: Re: [ath9k-devel] [RFC] ath9k: Detect and work-around tx-queue hang.
Date: Fri, 22 Feb 2013 12:36:23 +0100	[thread overview]
Message-ID: <51275837.4020708@openwrt.org> (raw)
In-Reply-To: <51270186.6070003@candelatech.com>

On 2013-02-22 6:26 AM, Ben Greear wrote:
> On 02/21/2013 08:49 PM, Sujith Manoharan wrote:
>> Ben Greear wrote:
>>> I'll be happy to test patches, but I'm not sure how to go about
>>> debugging the real problem on my own.  Maybe some stats could
>>> be added to the xmit debugfs file to help diagnose the problem,
>>> or maybe some other debugfs info will help?
>>>
>>> I can't reproduce the problem with ath9k debugging set at the
>>> previous suggested level, so it would have to be something
>>> less invasive.
>>>
>>> As for just stations going out of range, it remains locked up
>>> even with signal level goes back to -20, so it's not just a simple
>>> station-out-of range issues..
>>
>> Sure, but I think that filtered frames are not handled properly,
>> especially with aggregation, since the debugfs stats from your earlier email
>> showed a large counter (from a private patch ?):
>>
>> TXERR Filtered:            224          0         0         0
> 
> Yeah, guess that patch never made it upstream.  The pertinent bit is:
Please also check if the station(s) that the frames are queued for are
in powersave state for some reason. That would prevent the tx path from
throwing them in the hw queue, yet they'd still take up pending-frame
slots. I was planning on fixing this eventually by expiring frames that
stay in the queue for too long, but haven't decided on the exact
approach yet.

- Felix


  reply	other threads:[~2013-02-22 11:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-22  2:06 [RFC] ath9k: Detect and work-around tx-queue hang greearb
2013-02-22  4:28 ` Sujith Manoharan
2013-02-22  4:42   ` Ben Greear
2013-02-22  4:49     ` Sujith Manoharan
2013-02-22  5:26       ` Ben Greear
2013-02-22 11:36         ` Felix Fietkau [this message]
2013-02-22 12:25           ` [ath9k-devel] " Sujith Manoharan
2013-02-22 12:38             ` Felix Fietkau
2013-02-22 12:55               ` Ben Greear
2013-03-12 18:16                 ` Ben Greear
2013-03-13 14:14                   ` Sujith Manoharan
2013-03-13 14:18                   ` Felix Fietkau

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=51275837.4020708@openwrt.org \
    --to=nbd@openwrt.org \
    --cc=ath9k-devel@venema.h4ckr.net \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=sujith@msujith.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).