1. 14 6月, 2012 29 次提交
  2. 13 6月, 2012 11 次提交
    • D
      mac80211: stop polling in disassociation · 79543d8e
      David Spinadel 提交于
      Stop connection monitor poll during disassociation.
      This clears the polling flags and if a scan was
      deferred it will be run.
      
      Without this fix, if a scan was deferred due to
      connection monitoring while disassociation happens,
      this scan blocks further scan requests until interface
      down/up which causes problems connecting to another AP.
      Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      79543d8e
    • E
      mac80211: check sdata_running on ieee80211_set_bitrate_mask · 554a43d5
      Eliad Peller 提交于
      Otherwise, we might call the driver callback before
      the interface was uploaded.
      
      Solves the following warning:
      WARNING: at net/mac80211/driver-ops.h:12 ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211]()
      wlan0:  Failed check-sdata-in-driver check, flags: 0x0
      Modules linked in: wlcore_sdio wl12xx wl18xx wlcore mac80211 cfg80211 [last unloaded: cfg80211]
      [<c001b964>] (unwind_backtrace+0x0/0x12c) from [<c0495550>] (dump_stack+0x20/0x24)
      [<c0495550>] (dump_stack+0x20/0x24) from [<c003ee28>] (warn_slowpath_common+0x5c/0x74)
      [<c003ee28>] (warn_slowpath_common+0x5c/0x74) from [<c003eefc>] (warn_slowpath_fmt+0x40/0x48)
      [<c003eefc>] (warn_slowpath_fmt+0x40/0x48) from [<bf5c1ad0>] (ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211])
      [<bf5c1ad0>] (ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211]) from [<bf575960>] (nl80211_set_tx_bitrate_mask+0x350/0x358 [cfg80211])
      [<bf575960>] (nl80211_set_tx_bitrate_mask+0x350/0x358 [cfg80211]) from [<c03e9e94>] (genl_rcv_msg+0x1a8/0x1e8)
      [<c03e9e94>] (genl_rcv_msg+0x1a8/0x1e8) from [<c03e9164>] (netlink_rcv_skb+0x5c/0xc0)
      [<c03e9164>] (netlink_rcv_skb+0x5c/0xc0) from [<c03e9ce0>] (genl_rcv+0x28/0x34)
      [<c03e9ce0>] (genl_rcv+0x28/0x34) from [<c03e8e74>] (netlink_unicast+0x158/0x234)
      [<c03e8e74>] (netlink_unicast+0x158/0x234) from [<c03e93e0>] (netlink_sendmsg+0x218/0x298)
      [<c03e93e0>] (netlink_sendmsg+0x218/0x298) from [<c03b4e5c>] (sock_sendmsg+0xa4/0xc0)
      [<c03b4e5c>] (sock_sendmsg+0xa4/0xc0) from [<c03b5af4>] (__sys_sendmsg+0x1d8/0x254)
      [<c03b5af4>] (__sys_sendmsg+0x1d8/0x254) from [<c03b5ca8>] (sys_sendmsg+0x4c/0x70)
      [<c03b5ca8>] (sys_sendmsg+0x4c/0x70) from [<c0013980>] (ret_fast_syscall+0x0/0x3c)
      
      Note that calling the driver can also result
      in undefined behaviour since it doesn't have
      to deal with calls while down.
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      [removed timestamps, added note - Johannes]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      554a43d5
    • E
      cfg80211: fix potential deadlock in regulatory · fe20b39e
      Eliad Peller 提交于
      reg_timeout_work() calls restore_regulatory_settings() which
      takes cfg80211_mutex.
      
      reg_set_request_processed() already holds cfg80211_mutex
      before calling cancel_delayed_work_sync(reg_timeout),
      so it might deadlock.
      
      Call the async cancel_delayed_work instead, in order
      to avoid the potential deadlock.
      
      This is the relevant lockdep warning:
      
      cfg80211: Calling CRDA for country: XX
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.4.0-rc5-wl+ #26 Not tainted
      -------------------------------------------------------
      kworker/0:2/1391 is trying to acquire lock:
       (cfg80211_mutex){+.+.+.}, at: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
      
      but task is already holding lock:
       ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 ((reg_timeout).work){+.+...}:
             [<c008fd44>] validate_chain+0xb94/0x10f0
             [<c0090b68>] __lock_acquire+0x8c8/0x9b0
             [<c0090d40>] lock_acquire+0xf0/0x114
             [<c005b600>] wait_on_work+0x4c/0x154
             [<c005c000>] __cancel_work_timer+0xd4/0x11c
             [<c005c064>] cancel_delayed_work_sync+0x1c/0x20
             [<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211]
             [<bf28bd84>] set_regdom+0x550/0x600 [cfg80211]
             [<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211]
             [<c03c7738>] genl_rcv_msg+0x1a8/0x1e8
             [<c03c6a00>] netlink_rcv_skb+0x5c/0xc0
             [<c03c7584>] genl_rcv+0x28/0x34
             [<c03c6720>] netlink_unicast+0x15c/0x228
             [<c03c6c7c>] netlink_sendmsg+0x218/0x298
             [<c03933c8>] sock_sendmsg+0xa4/0xc0
             [<c039406c>] __sys_sendmsg+0x1e4/0x268
             [<c0394228>] sys_sendmsg+0x4c/0x70
             [<c0013840>] ret_fast_syscall+0x0/0x3c
      
      -> #1 (reg_mutex){+.+.+.}:
             [<c008fd44>] validate_chain+0xb94/0x10f0
             [<c0090b68>] __lock_acquire+0x8c8/0x9b0
             [<c0090d40>] lock_acquire+0xf0/0x114
             [<c04734dc>] mutex_lock_nested+0x48/0x320
             [<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211]
             [<c0059f44>] process_one_work+0x2a0/0x480
             [<c005a4b4>] worker_thread+0x1bc/0x2bc
             [<c0061148>] kthread+0x98/0xa4
             [<c0014af4>] kernel_thread_exit+0x0/0x8
      
      -> #0 (cfg80211_mutex){+.+.+.}:
             [<c008ed58>] print_circular_bug+0x68/0x2cc
             [<c008fb28>] validate_chain+0x978/0x10f0
             [<c0090b68>] __lock_acquire+0x8c8/0x9b0
             [<c0090d40>] lock_acquire+0xf0/0x114
             [<c04734dc>] mutex_lock_nested+0x48/0x320
             [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
             [<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211]
             [<c0059f44>] process_one_work+0x2a0/0x480
             [<c005a4b4>] worker_thread+0x1bc/0x2bc
             [<c0061148>] kthread+0x98/0xa4
             [<c0014af4>] kernel_thread_exit+0x0/0x8
      
      other info that might help us debug this:
      
      Chain exists of:
        cfg80211_mutex --> reg_mutex --> (reg_timeout).work
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock((reg_timeout).work);
                                     lock(reg_mutex);
                                     lock((reg_timeout).work);
        lock(cfg80211_mutex);
      
       *** DEADLOCK ***
      
      2 locks held by kworker/0:2/1391:
       #0:  (events){.+.+.+}, at: [<c0059e94>] process_one_work+0x1f0/0x480
       #1:  ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
      
      stack backtrace:
      [<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24)
      [<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc)
      [<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0)
      [<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0)
      [<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114)
      [<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320)
      [<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211])
      [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211])
      [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480)
      [<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc)
      [<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4)
      [<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (kernel_thread_exit+0x0/0x8)
      cfg80211: Calling CRDA to update world regulatory domain
      cfg80211: World regulatory domain updated:
      cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
      cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
      
      Cc: stable@kernel.org
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fe20b39e
    • E
      iwlwifi: WARN only once when we have trouble in reclaim · 67711c17
      Emmanuel Grumbach 提交于
      This flow can actually happen due to a corner case in
      mac80211: the station is deleted before we get a chance
      to reclaim all the packets in flight in AGG queue.
      The tid_data for this station is zeroed, and we lose
      the match with the Tx queue.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      67711c17
    • J
      iwlwifi: use request_module instead of _nowait · d4b10483
      Johannes Berg 提交于
      Since request_module_nowait() can't be backported
      use request_module() instead -- we don't need the
      asynchronous behaviour of request_module_nowait()
      here since we're running in the firmware request
      work struct.
      Tested-by: NDonald H Fry <donald.h.fry@intel.com>
      Reviewed-by: NDonald H Fry <donald.h.fry@intel.com>
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d4b10483
    • J
      iwlwifi: fix 6035 device parameters · 3c70d087
      Johannes Berg 提交于
      Due to commit 26a7ca9a ("iwlwifi: refactor EEPROM
      reading/parsing") adding a new parameter, while commit
      d2c8b15d ("iwlwifi: use correct supported firmware
      for 6035 and 6000g2") added a new device structure we
      need to add the parameter to the new device structure
      to make 6035 device work.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3c70d087
    • J
    • E
      iwlwifi: warn if TFD index and WiFi Seq don't match · 7bc057ff
      Emmanuel Grumbach 提交于
      For AGG queues, we must match between the WiFi sequence
      number and the TFD number. This is a HW (SCD) requirement.
      
      This is a take two of my
      
          iwlwifi: add debug in Tx path in AGG flow
      
          This will allow us to catch bad cases in which the packets aren't in
          the right place on the ring.
      
      which disappeared during code move.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      7bc057ff
    • E
      iwlwifi: don't modify the timer if we don't Tx · 49a4fc20
      Emmanuel Grumbach 提交于
      In fragmentation we don't update the write pointer of the
      HW immediately. So we shouldn't modify the timer in that
      case.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      49a4fc20
    • D
      iwlwifi: turn on a lockdep assertion · f609607c
      Dan Carpenter 提交于
      CMD_SYNC is zero so the if (cmd->flags & CMD_SYNC) is never true and we
      never check the assertion.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f609607c
    • E
      iwlwifi: print even more info when a queue is stuck · 12af0468
      Emmanuel Grumbach 提交于
      Since the queue gets stuck from time to time, we are trying
      to get as much information as we can when this occurs.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      12af0468