All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
To: Bob Copeland <me@bobcopeland.com>
Cc: Arnd Hannemann <Arnd.Hannemann@nets.rwth-aachen.de>,
	"ath5k-devel@lists.ath5k.org" <ath5k-devel@lists.ath5k.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: ath5k IBSS mode high latency
Date: Thu, 04 Mar 2010 14:57:30 +0100	[thread overview]
Message-ID: <4B8FBC4A.6010904@nets.rwth-aachen.de> (raw)
In-Reply-To: <b6c5339f1003030906jaa47f8dld615865b52bf19a1@mail.gmail.com>

Am 03.03.2010 18:06, schrieb Bob Copeland:
> On Tue, Mar 2, 2010 at 11:07 AM, Arnd Hannemann
> <hannemann@nets.rwth-aachen.de> wrote:
>> Hi,
>>
>> I'm currently experimenting with ath5k of kernel 2.6.33 in our
>> mesh network. We, were previously using madwifi in "ahdemo" mode,
>> which worked reasonably well.
>>
>> At the same time there is no reasonable traffic that justifies this high backlog.
>> I'm not yet sure, but it may be related to this message in dmesg:
>>
>> [ 3681.006797] ath5k phy0: no further txbuf available, dropping packet
> 
> It's likely.
> 
> When this happens, we tell mac80211 to stop all of the
> tx queues -- regardless of which queue stopped -- until
> the hardware interrupts begin processing tx status
> descriptors.  We re-enable them when there is a certain
> amount of headroom.
> 
>> Any idea how to debug this problem further?
> 
> I would add a printk to where the queues are stopped
> and re-enabled, and when packets are queued, to determine
> which queue is using up all of the descriptors.  I can put
> together a patch with the appropriate debug for you if you
> like, but in a day or two when I'm a bit less busy.

That would be nice.
However, I have to wait until saturday to get access
to the testbed again...

> 
> By the way, I did notice that if we fail to map DMA
> buffers we can leak tx descriptors, but this is unlikely
> to be the cause.
> 

Best regards,
Arnd

  reply	other threads:[~2010-03-04 13:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-02 16:07 ath5k IBSS mode high latency Arnd Hannemann
2010-03-03 17:06 ` Bob Copeland
2010-03-04 13:57   ` Arnd Hannemann [this message]
2010-03-05  0:32   ` [ath5k-devel] " Bruno Randolf

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=4B8FBC4A.6010904@nets.rwth-aachen.de \
    --to=hannemann@nets.rwth-aachen.de \
    --cc=Arnd.Hannemann@nets.rwth-aachen.de \
    --cc=ath5k-devel@lists.ath5k.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=me@bobcopeland.com \
    /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.