1. 31 3月, 2010 4 次提交
  2. 17 3月, 2010 3 次提交
    • A
      iwlwifi: Silence tfds_in_queue message · c8406ea8
      Adel Gadllah 提交于
      Commit a239a8b4 introduced a
      noisy message, that fills up the log very fast.
      
      The error seems not to be fatal (the connection is stable and
      performance is ok), so make it IWL_DEBUG_TX rather than IWL_ERR.
      Signed-off-by: NAdel Gadllah <adel.gadllah@gmail.com>
      Cc: stable@kernel.org
      Acked-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c8406ea8
    • 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
    • G
      wl1251: fix potential crash · 3f60ebc9
      Grazvydas Ignotas 提交于
      In case debugfs does not init for some reason (or is disabled
      on older kernels) driver does not allocate stats.fw_stats
      structure, but tries to clear it later and trips on a NULL
      pointer:
      
      Unable to handle kernel NULL pointer dereference at virtual address
      00000000
      PC is at __memzero+0x24/0x80
      Backtrace:
      [<bf0ddb88>] (wl1251_debugfs_reset+0x0/0x30 [wl1251])
      [<bf0d6a2c>] (wl1251_op_stop+0x0/0x12c [wl1251])
      [<bf0bc228>] (ieee80211_stop_device+0x0/0x74 [mac80211])
      [<bf0b0d10>] (ieee80211_stop+0x0/0x4ac [mac80211])
      [<c02deeac>] (dev_close+0x0/0xb4)
      [<c02deac0>] (dev_change_flags+0x0/0x184)
      [<c031f478>] (devinet_ioctl+0x0/0x704)
      [<c0320720>] (inet_ioctl+0x0/0x100)
      
      Add a NULL pointer check to fix this.
      Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
      Acked-by: NKalle Valo <kalle.valo@iki.fi>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3f60ebc9
  3. 11 3月, 2010 7 次提交
  4. 10 3月, 2010 2 次提交
    • R
      Revert "iwlwifi: Send broadcast probe request only when asked to" · 1382c71c
      Reinette Chatre 提交于
      This reverts commit 21b2d8bd.
      
      As explained by Johannes:
      When we
      build a probe request frame in the buffer with the SSID, we could
      arrive over the limit of 200 bytes. When we build it in the buffer
      without the SSID (wildcard) we don't arrive over 200 bytes, but the
      ucode still allows direct probe in addition because it has an internal
      buffer that is larger when it inserts the SSID...
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      1382c71c
    • R
      iwl3945: fix memory corruption · 1d79e53c
      Reinette Chatre 提交于
      Recent patch "iwlwifi: move 3945 clip groups to 3945 data" exposed a memory
      corruption problem. When initializing the clip groups the code was
      mistakenly using the iwlagn rate count, not the 3945 rate count. This
      resulted in more memory being written than was allocated.
      
      "iwlwifi: move 3945 clip groups to 3945 data" moved the location where the
      clip groups are stored and the impact is now severe in that the number of
      configured TX queues is modified. Previously the
      "temperature" field was overwritten, which did not seem to affect the
      operation.
      
      Fix this one instance where wrong rate count was used. I also noticed one
      more location where the iwlagn rate count was used to index an iwl3945
      array, fix this. I also modified one location that modified the iwlagn rate
      count to obtain the iwl3945 rate count ... just use the iwl3945 rate count
      directly.
      
      This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2165 and
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2168Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      1d79e53c
  5. 04 3月, 2010 3 次提交
  6. 03 3月, 2010 7 次提交
    • J
      iwlwifi: load firmware asynchronously before mac80211 registration · b08dfd04
      Johannes Berg 提交于
      At the wireless summit in Portland we discussed a way of
      loading firmware asynchronously from ->probe() before
      registration to mac80211, in order to register with the
      wireless subsystems with complete information in cases
      where firmware is required to know parameters.
      
      This is not yet the case in iwlwifi, but for some new
      features we're working on it will be the case since
      those will only be supported by new firmware images.
      
      Hence, to start with, convert iwlwifi to load firmware
      asynchronously from probe, unbinding the device when
      firmware loading fails, and only registering with the
      wireless subsystems after firmware has been loaded
      successfully.
      
      Future patches will hook into this to register the
      new firmware capabilities, depending on the firmware
      API version.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b08dfd04
    • J
      ar9170: load firmware asynchronously · 53576517
      Johannes Berg 提交于
      This converts ar9170 to load firmware asynchronously
      out of ->probe() and only register with mac80211 when
      all firmware has been loaded successfully. If, on the
      other hand, any firmware fails to load, it will now
      unbind from the device.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      53576517
    • H
      rt2x00: fix rt2800pci compilation with SoC · 6e93d719
      Helmut Schaa 提交于
      Compiling rt2800pci with CONFIG_RT2800PCI_SOC fails with "... rt2880pci.c:
      error: incompatible type for argument 2 of 'rt2x00soc_probe'".
      
      Fix this by using &rt2800pci_ops instead of rt2800pci_ops.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6e93d719
    • B
      rt2x00: Add USB ID for CEIVA adapter to rt73usb · 51b2853f
      Bryan Polk 提交于
      This adds support for CEIVA USB wireless adapters to the rt73usb driver.
      Signed-off-by: NBryan Polk <sainth@eidolons.org>
      Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
      Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      51b2853f
    • 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
    • D
      zd1211rw: fix potential array underflow · 86baf712
      Dan Carpenter 提交于
      The first chunk fixes a debugging assert to print a warning about array underflows.
      The second chunk corrects a potential array underflow.  I also removed an assert
      in the second chunk because it can no longer happen.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Acked-by: NBenoit Papillault <benoit.papillault@free.fr>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      86baf712
    • S
      airo: return from set_wep_key() when key length is zero · 6510b891
      Stanislaw Gruszka 提交于
      Even if keylen == 0 is a bug and should not really happen, better avoid
      possibility of passing bad value to firmware.
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6510b891
  7. 28 2月, 2010 1 次提交
  8. 27 2月, 2010 2 次提交
  9. 24 2月, 2010 2 次提交
  10. 23 2月, 2010 3 次提交
  11. 20 2月, 2010 6 次提交