1. 15 6月, 2010 2 次提交
  2. 04 6月, 2010 1 次提交
    • F
      ath9k: fix queue stop/start based on the number of pending frames · 84642d6b
      Felix Fietkau 提交于
      Because there is a limited number of tx buffers available, once the
      queue has been filled to a certain point, ath9k needs to stop accepting
      new frames from mac80211. In order to prevent a full WMM queue from
      stopping another queue with fewer frames, this patch limits the number
      of queued frames to a quarter of the total available tx buffers, minus
      some reserved frames to be used for other purposes (e.g. beacons).
      
      Because tx buffers are reserved for frames when they're staged in
      software queues as well, the actual queue depth cannot be used for
      this, so this patch stores a reference to the tx queue in the ath_buf
      struct and keeps track of the total number of pending frames.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      84642d6b
  3. 03 6月, 2010 1 次提交
  4. 29 5月, 2010 2 次提交
  5. 28 4月, 2010 1 次提交
  6. 20 4月, 2010 5 次提交
  7. 17 4月, 2010 12 次提交
  8. 07 4月, 2010 1 次提交
  9. 01 4月, 2010 2 次提交
  10. 17 3月, 2010 1 次提交
    • F
      ath9k: fix BUG_ON triggered by PAE frames · 4fdec031
      Felix Fietkau 提交于
      When I initially stumbled upon sequence number problems with PAE frames
      in ath9k, I submitted a patch to remove all special cases for PAE
      frames and let them go through the normal transmit path.
      Out of concern about crypto incompatibility issues, this change was
      merged instead:
      
      commit 6c8afef5
      Author: Sujith <Sujith.Manoharan@atheros.com>
      Date:   Tue Feb 9 10:07:00 2010 +0530
      
          ath9k: Fix sequence numbers for PAE frames
      
      After a lot of testing, I'm able to reliably trigger a driver crash on
      rekeying with current versions with this change in place.
      It seems that the driver does not support sending out regular MPDUs with
      the same TID while an A-MPDU session is active.
      This leads to duplicate entries in the TID Tx buffer, which hits the
      following BUG_ON in ath_tx_addto_baw():
      
          index  = ATH_BA_INDEX(tid->seq_start, bf->bf_seqno);
          cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1);
      
          BUG_ON(tid->tx_buf[cindex] != NULL);
      
      I believe until we actually have a reproducible case of an
      incompatibility with another AP using no PAE special cases, we should
      simply get rid of this mess.
      
      This patch completely fixes my crash issues in STA mode and makes it
      stay connected without throughput drops or connectivity issues even
      when the AP is configured to a very short group rekey interval.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4fdec031
  11. 11 3月, 2010 1 次提交
  12. 03 3月, 2010 1 次提交
    • M
      ath9k: fix lockdep warning when unloading module · a9f042cb
      Ming Lei 提交于
      Since txq->axq_lock may be hold in softirq context, it must be
      acquired with spin_lock_bh() instead of spin_lock() if softieq is
      enabled.
      
      The patch fixes the lockdep warning below when unloading ath9k modules.
      
      =================================
      [ INFO: inconsistent lock state ]
      2.6.33-wl #12
      ---------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      rmmod/3642 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&txq->axq_lock)->rlock){+.?...}, at: [<ffffffffa03568c3>] ath_tx_node_cleanup+0x62/0x180 [ath9k]
      {IN-SOFTIRQ-W} state was registered at:
        [<ffffffff8107577d>] __lock_acquire+0x2f6/0xd35
        [<ffffffff81076289>] lock_acquire+0xcd/0xf1
        [<ffffffff813a7486>] _raw_spin_lock_bh+0x3b/0x6e
        [<ffffffffa0356b49>] spin_lock_bh+0xe/0x10 [ath9k]
        [<ffffffffa0358ec7>] ath_tx_tasklet+0xcd/0x391 [ath9k]
        [<ffffffffa0354f5f>] ath9k_tasklet+0x70/0xc8 [ath9k]
        [<ffffffff8104e601>] tasklet_action+0x8c/0xf4
        [<ffffffff8104f459>] __do_softirq+0xf8/0x1cd
        [<ffffffff8100ab1c>] call_softirq+0x1c/0x30
        [<ffffffff8100c2cf>] do_softirq+0x4b/0xa3
        [<ffffffff8104f045>] irq_exit+0x4a/0x8c
        [<ffffffff813acccc>] do_IRQ+0xac/0xc3
        [<ffffffff813a7d53>] ret_from_intr+0x0/0x16
        [<ffffffff81302d52>] cpuidle_idle_call+0x9e/0xf8
        [<ffffffff81008be7>] cpu_idle+0x62/0x9d
        [<ffffffff81391c1a>] rest_init+0x7e/0x80
        [<ffffffff818bbd38>] start_kernel+0x3e8/0x3f3
        [<ffffffff818bb2bc>] x86_64_start_reservations+0xa7/0xab
        [<ffffffff818bb3b8>] x86_64_start_kernel+0xf8/0x107
      irq event stamp: 42037
      hardirqs last  enabled at (42037): [<ffffffff813a7b21>] _raw_spin_unlock_irqrestore+0x47/0x56
      hardirqs last disabled at (42036): [<ffffffff813a72f4>] _raw_spin_lock_irqsave+0x2b/0x88
      softirqs last  enabled at (42000): [<ffffffffa0353ea6>] spin_unlock_bh+0xe/0x10 [ath9k]
      softirqs last disabled at (41998): [<ffffffff813a7463>] _raw_spin_lock_bh+0x18/0x6e
      
      other info that might help us debug this:
      4 locks held by rmmod/3642:
       #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff8132c10d>] rtnl_lock+0x17/0x19
       #1:  (&wdev->mtx){+.+.+.}, at: [<ffffffffa01e53f2>] cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211]
       #2:  (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0260834>] ieee80211_mgd_deauth+0x3f/0x17e [mac80211]
       #3:  (&local->sta_mtx){+.+.+.}, at: [<ffffffffa025a381>] sta_info_destroy_addr+0x2b/0x5e [mac80211]
      
      stack backtrace:
      Pid: 3642, comm: rmmod Not tainted 2.6.33-wl #12
      Call Trace:
       [<ffffffff81074469>] valid_state+0x178/0x18b
       [<ffffffff81014f94>] ? save_stack_trace+0x2f/0x4c
       [<ffffffff81074e08>] ? check_usage_backwards+0x0/0x88
       [<ffffffff8107458f>] mark_lock+0x113/0x230
       [<ffffffff810757f1>] __lock_acquire+0x36a/0xd35
       [<ffffffff8101018d>] ? native_sched_clock+0x2d/0x5f
       [<ffffffffa03568c3>] ? ath_tx_node_cleanup+0x62/0x180 [ath9k]
       [<ffffffff81076289>] lock_acquire+0xcd/0xf1
       [<ffffffffa03568c3>] ? ath_tx_node_cleanup+0x62/0x180 [ath9k]
       [<ffffffff810732eb>] ? trace_hardirqs_off+0xd/0xf
       [<ffffffff813a7193>] _raw_spin_lock+0x36/0x69
       [<ffffffffa03568c3>] ? ath_tx_node_cleanup+0x62/0x180 [ath9k]
       [<ffffffffa03568c3>] ath_tx_node_cleanup+0x62/0x180 [ath9k]
       [<ffffffff810749ed>] ? trace_hardirqs_on+0xd/0xf
       [<ffffffffa0353950>] ath9k_sta_remove+0x22/0x26 [ath9k]
       [<ffffffffa025a08f>] __sta_info_destroy+0x1ad/0x38c [mac80211]
       [<ffffffffa025a394>] sta_info_destroy_addr+0x3e/0x5e [mac80211]
       [<ffffffffa02605d6>] ieee80211_set_disassoc+0x175/0x180 [mac80211]
       [<ffffffffa026084d>] ieee80211_mgd_deauth+0x58/0x17e [mac80211]
       [<ffffffff813a60c1>] ? __mutex_lock_common+0x37f/0x3a4
       [<ffffffffa01e53f2>] ? cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211]
       [<ffffffffa026786e>] ieee80211_deauth+0x1e/0x20 [mac80211]
       [<ffffffffa01f47f9>] __cfg80211_mlme_deauth+0x130/0x13f [cfg80211]
       [<ffffffffa01e53f2>] ? cfg80211_netdev_notifier_call+0x28d/0x46d [cfg80211]
       [<ffffffff810732eb>] ? trace_hardirqs_off+0xd/0xf
       [<ffffffffa01f7eee>] __cfg80211_disconnect+0x111/0x189 [cfg80211]
       [<ffffffffa01e5433>] cfg80211_netdev_notifier_call+0x2ce/0x46d [cfg80211]
       [<ffffffff813aa9ea>] notifier_call_chain+0x37/0x63
       [<ffffffff81068c98>] raw_notifier_call_chain+0x14/0x16
       [<ffffffff81322e97>] call_netdevice_notifiers+0x1b/0x1d
       [<ffffffff8132386d>] dev_close+0x6a/0xa6
       [<ffffffff8132395f>] rollback_registered_many+0xb6/0x2f4
       [<ffffffff81323bb8>] unregister_netdevice_many+0x1b/0x66
       [<ffffffffa026494f>] ieee80211_remove_interfaces+0xc5/0xd0 [mac80211]
       [<ffffffffa02580a2>] ieee80211_unregister_hw+0x47/0xe8 [mac80211]
       [<ffffffffa035290e>] ath9k_deinit_device+0x7a/0x9b [ath9k]
       [<ffffffffa035bc26>] ath_pci_remove+0x38/0x76 [ath9k]
       [<ffffffff8120940a>] pci_device_remove+0x2d/0x51
       [<ffffffff8129d797>] __device_release_driver+0x7b/0xd1
       [<ffffffff8129d885>] driver_detach+0x98/0xbe
       [<ffffffff8129ca7a>] bus_remove_driver+0x94/0xb7
       [<ffffffff8129ddd6>] driver_unregister+0x6c/0x74
       [<ffffffff812096d2>] pci_unregister_driver+0x46/0xad
       [<ffffffffa035bae1>] ath_pci_exit+0x15/0x17 [ath9k]
       [<ffffffffa035e1a2>] ath9k_exit+0xe/0x2f [ath9k]
       [<ffffffff8108050a>] sys_delete_module+0x1c7/0x236
       [<ffffffff813a7df5>] ? retint_swapgs+0x13/0x1b
       [<ffffffff810749b5>] ? trace_hardirqs_on_caller+0x119/0x144
       [<ffffffff8109b9f6>] ? audit_syscall_entry+0x11e/0x14a
       [<ffffffff81009bb2>] system_call_fastpath+0x16/0x1b
      wlan1: deauthenticating from 00:23:cd:e1:f9:b2 by local choice (reason=3)
      PM: Removing info for No Bus:wlan1
      cfg80211: Calling CRDA to update world regulatory domain
      PM: Removing info for No Bus:rfkill2
      PM: Removing info for No Bus:phy1
      ath9k 0000:16:00.0: PCI INT A disabled
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a9f042cb
  13. 10 2月, 2010 1 次提交
  14. 09 2月, 2010 1 次提交
  15. 02 2月, 2010 1 次提交
  16. 20 1月, 2010 1 次提交
    • F
      ath9k: fix RTS/CTS handling · 27032059
      Felix Fietkau 提交于
      The Tx DMA descriptor has two kinds of flags that select RTS/CTS usage.
      The first one (global for the frame) selects whether RTS/CTS or
      CTS-to-self should be used, the second one enables RTS/CTS or
      CTS-to-self usage for an individual multi-rate-retry entry.
      Previously the code preparing the descriptor only enabled the global
      flag, if the first MRR series selected the local one.
      Fix this by enabling the global flag if any of the MRR entries need it.
      With this patch, rate control can properly select the use of RTS/CTS
      for all MRR entries except the first one, which is the default behavior.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      27032059
  17. 13 1月, 2010 1 次提交
  18. 29 12月, 2009 1 次提交
  19. 22 12月, 2009 3 次提交
  20. 08 12月, 2009 1 次提交
    • F
      ath9k: fix tx status reporting · 815833e7
      Felix Fietkau 提交于
      This patch fixes a bug in ath9k's tx status check, which
      caused mac80211 to consider regularly transmitted unicast frames
      as un-acked.
      When checking the ts_status field for errors, it needs to be masked
      with ATH9K_TXERR_FILT, because this field also contains other fields
      like ATH9K_TX_ACKED.
      Without this patch, AP mode is pretty much unusable, as hostapd
      checks the ACK status for the frames that it injects.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      815833e7