[ath9k-devel] Wireless stalled after a few minutes with Linux Kernel 3.1

2011-11-19 Thread Haohui Liao
Dear Linux wifi developers,

I am using ArchLinux with Linux kernel 3.0.7.  I find that sometimes
the wifi connection will suddenly just disconnect itself but it will
quickly resume.  Some said on the Internet that this is due to
surrounding interference, is this normal?

When I upgraded to Linux kernel 3.1, I have even worst experience, the
wifi will stall a few minutes after connection and only killing
wpa_supplicant and running it all over again will I be able to
reconnect to the wifi.  The following are my hardware and software
status:

oftware: Linux-3.1-4  wpa_supplicant v0.7.3
Closely related but not the same problem (my system doesn't have have
the bcma as mentioned in the url):
https://bbs.archlinux.org/viewtopic.php?pid=1014217
Observation: No such network stall with linux-3.0.7-1.

I didn't encounter core dump problem with kernel 3.1. However, after
connecting for a few seconds or minutes, the connection with stall and
I can't assess Internet. I check my dmesg, it gave the following info:

[ 45.966602] wlan0: direct probe to f4:3f:61:06:22:21 (try 1/3)
[ 45.969213] wlan0: direct probe responded
[ 45.998789] wlan0: authenticate with f4:3f:61:06:22:21 (try 1)
[ 46.001234] wlan0: authenticated
[ 46.001270] wlan0: associate with f4:3f:61:06:22:21 (try 1)
[ 46.004102] wlan0: RX AssocResp from f4:3f:61:06:22:21 (capab=0x411
status=0 aid=1)
[ 46.004107] wlan0: associated
[ 93.007527] usb 1-1.3: USB disconnect, device number 3
[ 95.654157] NET: Registered protocol family 10
[ 106.263062] wlan0: no IPv6 routers present

Does this mean that the IPv6 in kernel 3.1 is affecting the wifi
connection?  Please advice.


Best Regards,
Liao Haohui
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


Re: [ath9k-devel] [PATCH] ath9k: Improve ath_tx_aggr_stop to avoid TID stuck in cleanup state.

2011-11-19 Thread Mohammed Shafi
Hi Nikolay,

On Sat, Nov 19, 2011 at 12:11 PM, Nikolay Martynov mar.ko...@gmail.com wrote:
 From: kolya mar.ko...@gmail.com

  When tx agg is being stopped TID is flushed using ath_tx_flush_tid. It is 
 possible that ath_tx_flush_tid completelly flushes TID (if all packets in 
 this TID have already been retried). If this happened ath_tx_aggr_stop would 
 leave TID in cleanup state permanently. Fix this by making ath_tx_flush_tid 
 remove AGGR_ADDBA_COMPLETE and AGGR_CLEANUP flags from TID status if TID is 
 empty.
 ---
  drivers/net/wireless/ath/ath9k/xmit.c |   13 ++---
  1 files changed, 6 insertions(+), 7 deletions(-)

 diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
 b/drivers/net/wireless/ath/ath9k/xmit.c
 index 55d077e..3574b0f 100644
 --- a/drivers/net/wireless/ath/ath9k/xmit.c
 +++ b/drivers/net/wireless/ath/ath9k/xmit.c
 @@ -180,6 +180,11 @@ static void ath_tx_flush_tid(struct ath_softc *sc, 
 struct ath_atx_tid *tid)
        }

        spin_unlock_bh(txq-axq_lock);
 +
 +       if (tid-baw_head == tid-baw_tail) {
 +               tid-state = ~AGGR_ADDBA_COMPLETE;
 +               tid-state = ~AGGR_CLEANUP;
 +       }

should this in be protected by axq_lock ?

  }

  static void ath_tx_update_baw(struct ath_softc *sc, struct ath_atx_tid *tid,
 @@ -556,15 +561,9 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, 
 struct ath_txq *txq,
                spin_unlock_bh(txq-axq_lock);
        }

 -       if (tid-state  AGGR_CLEANUP) {
 +       if (tid-state  AGGR_CLEANUP)
                ath_tx_flush_tid(sc, tid);

 -               if (tid-baw_head == tid-baw_tail) {
 -                       tid-state = ~AGGR_ADDBA_COMPLETE;
 -                       tid-state = ~AGGR_CLEANUP;
 -               }
 -       }
 -
        rcu_read_unlock();

        if (needreset) {

based on my understanding if we don't clear this flag, i assume we
might have problem in ath_tx_aggr_start?
but should not this be properly cleared ath_txcomplete_aggr via tasklet path?
please let me know if i had  missed somthing?

 --
 1.7.4.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html




-- 
shafi
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


Re: [ath9k-devel] Wireless stalled after a few minutes with Linux Kernel 3.1

2011-11-19 Thread Arend van Spriel
On 11/19/2011 03:20 PM, Haohui Liao wrote:
 Dear Linux wifi developers,
 
 I didn't encounter core dump problem with kernel 3.1. However, after
 connecting for a few seconds or minutes, the connection with stall and
 I can't assess Internet. I check my dmesg, it gave the following info:
 
 [ 45.966602] wlan0: direct probe to f4:3f:61:06:22:21 (try 1/3)
 [ 45.969213] wlan0: direct probe responded
 [ 45.998789] wlan0: authenticate with f4:3f:61:06:22:21 (try 1)
 [ 46.001234] wlan0: authenticated
 [ 46.001270] wlan0: associate with f4:3f:61:06:22:21 (try 1)
 [ 46.004102] wlan0: RX AssocResp from f4:3f:61:06:22:21 (capab=0x411
 status=0 aid=1)
 [ 46.004107] wlan0: associated
 [ 93.007527] usb 1-1.3: USB disconnect, device number 3
 [ 95.654157] NET: Registered protocol family 10
 [ 106.263062] wlan0: no IPv6 routers present

Actually, this trace looks fine. The last message means that no IPv6
capable network equipment has been detected. Did you do unplug a USB device?

 Does this mean that the IPv6 in kernel 3.1 is affecting the wifi
 connection?  Please advice.

Provide hardware info.

Gr. AvS

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


Re: [ath9k-devel] [PATCH] ath9k: Improve ath_tx_aggr_stop to avoid TID stuck in cleanup state.

2011-11-19 Thread Nikolay Martynov
Hi,

2011/11/19 Mohammed Shafi shafi.wirel...@gmail.com:

        }

        spin_unlock_bh(txq-axq_lock);
 +
 +       if (tid-baw_head == tid-baw_tail) {
 +               tid-state = ~AGGR_ADDBA_COMPLETE;
 +               tid-state = ~AGGR_CLEANUP;
 +       }

 should this in be protected by axq_lock ?

   In ath_tx_aggr_stop update of tid-state are protected by axq_lock.
In ath_tx_complete_aggr the updates of these flags were (before this
patch) not protected by axq_lock (unless I miss something here). So I
quess you are right - this actually should be protected by lock, I'll
send new version of this patch.


  }

  static void ath_tx_update_baw(struct ath_softc *sc, struct ath_atx_tid *tid,
 @@ -556,15 +561,9 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, 
 struct ath_txq *txq,
                spin_unlock_bh(txq-axq_lock);
        }

 -       if (tid-state  AGGR_CLEANUP) {
 +       if (tid-state  AGGR_CLEANUP)
                ath_tx_flush_tid(sc, tid);

 -               if (tid-baw_head == tid-baw_tail) {
 -                       tid-state = ~AGGR_ADDBA_COMPLETE;
 -                       tid-state = ~AGGR_CLEANUP;
 -               }
 -       }
 -
        rcu_read_unlock();

        if (needreset) {

 based on my understanding if we don't clear this flag, i assume we
 might have problem in ath_tx_aggr_start?
 but should not this be properly cleared ath_txcomplete_aggr via tasklet path?
 please let me know if i had  missed somthing?

  If AGGR_CLEANUP is not cleared up TID permanently stays in 'paused'
state and is never reused. To the best of my understanding this flag
is cleared in two places: ath_tx_aggr_stop and ath_tx_complete_aggr.
The flag should be removed when TID is empty.
  ath_tx_aggr_stop had (before patch) a problem in which it didn't
clear the flag when TID was empty in some cases. Basically what
happened is that ath_tx_aggr_stop called ath_tx_flush_tid.
ath_tx_flush_tid tries to send packets that were not sent before and
if packet was already tried it removes it from TID. So under certain
conditions execution of ath_tx_flush_tid can result in empty TID.
ath_tx_aggr_stop didn't expect this and didn't clear the flag. When
TID is empty the ath_txcomplete_aggr is never called, so it doesn't
get a chance to cleanup the flag.
  All I did is to move flag cleanup from ath_tx_complete_aggr to
ath_tx_flush_tid. ath_tx_flush_tid actually flushes TID and if TID is
empty after it was executed the flag should be removed. So, After my
patch both ath_tx_aggr_stop and ath_tx_complete_aggr clean up the flag
when appropriate.
  I actually observed this problem (i.e. forever paused TID with no
packets and CLENUP flag up) and I think it can be recreated if one
tries to disable TID many times via debugfs when link is loaded with
traffic.

  Please let me know if you have any more questions or suggestions.
  Thanks!

-- 
Truthfully yours,
Martynov Nikolay.
Email: mar.ko...@gmail.com
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


[ath9k-devel] netif_rx or NAPI

2011-11-19 Thread abhinav narain
hi,
 Can someone tell me if ath9k uses NAPI or netif_rx() interface ?
If it uses NAPI , can I still use netif_rx() and will that push the packets
to the upper layers or is it deprecated?

Abhinav
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel