Linux wireless drivers development
 help / color / mirror / Atom feed
From: "Chuck Crisler" <ccrisler@vgocom.com>
To: "linux-wireless Mail List" <linux-wireless@vger.kernel.org>
Subject: AR9170 woes
Date: Thu, 23 Sep 2010 12:20:33 -0400	[thread overview]
Message-ID: <B5CFBEFEE0384AECAF4A5D4FDE63EAE5@ChuckPC> (raw)

I am *STILL* having failures hopping with the AR9170. Here is what happens.

The 9170 sends a NULL function with the power save bit set. I know that the 
APs that we have disregard that and continue sending packets. I have seen 
this in multiple wireshark traces. We then do a scan, select an AP and 
disconnect from the former AP. The disconnect is handled in mac80211/mlme.c. 
The function calls netif_tx_stop_all_queues and netif_carrier_off. I have 
added additional code to flush the local Tx and AR Tx queues, though I do 
check the status before and the queues are always reported to be empty. This 
step seems to fail. We then successfully change the channel. At that point 
in failure cases we resume transmitting data packets to the old AP on the 
new channel. These aren't acked so they are all retransmits. I have a 
wireshark trace that shows this. I stopped the capture 104 seconds (almost 2 
minutes) after the channel change. This seems to prevent the authentication 
messages from being transmitted, as reported by the mac code.

I know that the 9170 Rx handling isn't very good. It seems that the handler 
does *ALL* of it's work with interrupts turned off. What if we called 
netif_tx_stop_all_queues during this time when interrupts are turned off? 
Would that cause the call to silently fail and leave the Tx queues still 
operational? Does the call to netif_tx_stop_all_queues require an interrupt 
to actually stop the queues on the device? If I moved the 
netif_tx_stop_all_queues call to after the channel has been changed (and I 
know that I am not receiving any packets), would this possibly be a 
work-around?

Thank you,
Chuck 


                 reply	other threads:[~2010-09-23 16:20 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=B5CFBEFEE0384AECAF4A5D4FDE63EAE5@ChuckPC \
    --to=ccrisler@vgocom.com \
    --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