1. 20 Jun, 2012 4 commits
  2. 19 Jun, 2012 8 commits
  3. 14 Jun, 2012 1 commit
  4. 13 Jun, 2012 5 commits
    • Mohammed Shafi Shajakhan's avatar
      ath9k: Fix softlockup in AR9485 · bcb7ad7b
      Mohammed Shafi Shajakhan authored
      steps to recreate:
      load latest ath9k driver with AR9485
      stop the network-manager and wpa_supplicant
      bring the interface up
      
      	Call Trace:
      	[<ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k]
      	[<ffffffff812cd1e8>] __const_udelay+0x28/0x30
      	[<ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
      	[<ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k]
      	[<ffffffff810744fe>] process_one_work+0x11e/0x470
      	[<ffffffff8107530f>] worker_thread+0x15f/0x360
      	[<ffffffff810751b0>] ? manage_workers+0x230/0x230
      	[<ffffffff81079af3>] kthread+0x93/0xa0
      	[<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10
      	[<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70
      	[<ffffffff815fd3a0>] ? gs_change+0x13/0x13
      
      ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
      associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
      is needed to recover from some rare beacon stuck during stress testing.
      Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
      always seem to have zero even though we had configured PLL3(0x16188) to
      query about PLL's locking status. When we keep on polling infinitely PLL4's
      8th bit(ie check for PLL locking measurements is done), machine hangs
      due to softlockup.
      
      fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142Reported-by: default avatarRolf Offermanns <rolf.offermanns@gmx.net>
      Cc: stable@vger.kernel.org [3.0+]
      Tested-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      bcb7ad7b
    • John W. Linville's avatar
    • David Spinadel's avatar
      mac80211: stop polling in disassociation · 79543d8e
      David Spinadel authored
      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: default avatarDavid Spinadel <david.spinadel@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      79543d8e
    • Eliad Peller's avatar
      mac80211: check sdata_running on ieee80211_set_bitrate_mask · 554a43d5
      Eliad Peller authored
      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: default avatarEliad Peller <eliad@wizery.com>
      [removed timestamps, added note - Johannes]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      554a43d5
    • Eliad Peller's avatar
      cfg80211: fix potential deadlock in regulatory · fe20b39e
      Eliad Peller authored
      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: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fe20b39e
  5. 12 Jun, 2012 4 commits
  6. 11 Jun, 2012 4 commits
    • John W. Linville's avatar
    • Jussi Kivilinna's avatar
      rndis_wlan: fix matching bssid check in rndis_check_bssid_list() · b0fd49b7
      Jussi Kivilinna authored
      rndis_check_bssid_list() originally tried to check if bssid->mac and
      match_bssid are equal using compare_ether_addr() when it should use
      !compare_ether_addr(). This check was added by commit
      b5257c95 as part of workaround for
      hardware issue.
      
      Commit 2e42e474 that replaced
      compare_ether_addr with ether_addr_equal relieved that this compare
      to be inverse of what it should be.
      
      Compare was added as response to hardware bug, where bssid-list does
      not contain BSSID and other information of currently connected AP
      (spec insists that device must provide this information in the list
      when connected). Lack bssid-data on current connection then causes
      WARN_ON somewhere in cfg80211. Workaround was to check if bssid-list
      returns current bssid and if it does not, manually construct bssid
      information in other ways. And this workaround worked, with inverse
      check. Which must mean that when hardware is experiencing the problem,
      it's actually returning empty bssid-list and this check didn't make
      any difference for workaround.
      
      However inverse check causes workaround be activated when bssid-list
      returns only entry, currently connected BSSID. That does not cause
      problems in itself, just slightly more inaccurate information in
      scan-list.
      
      Cc: Joe Perches <joe@perches.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b0fd49b7
    • Mohammed Shafi Shajakhan's avatar
      ath9k: remove incompatible IBSS interface check in change_iface · a23415fd
      Mohammed Shafi Shajakhan authored
      'cfg80211: fix interface combinations' ensures that if an interface
      type is not advertised by the driver in any of the interface combinations
      (via ieee80211_iface_combination) then it shall be treated as a single
      incompatible interface. if there are more than one interfaces present
      and changing them to incompatible interface type is not possible.
      These checks will be properly handled by cfg80211_change_iface ->
      cfg80211_can_change_interface.
      
      this patch is dependent on 'cfg80211: fix interface combinations'
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a23415fd
    • Mohammed Shafi Shajakhan's avatar
      ath9k: Fix a WARNING on suspend/resume with IBSS · 2031b4c2
      Mohammed Shafi Shajakhan authored
      this patch is dependent on the patch "cfg80211: fix interface
      combinations"
      
      In ath9k currently we have ADHOC interface as a single incompatible
      interface. when drv_add_interface is called during resume we got to
      consider number of vifs already present in addition to checking the
      drivers 'opmode' information about ADHOC.  we incorrectly assume
      an ADHOC interface is already present. Then we may miss some driver
      specific data for the ADHOC interface after resume.
      
      The above mentioned checks can be removed from the driver,
      as the patch 'cfg80211: fix interface combinations' ensures that
      if an interface type is not advertised by the driver in any of the
      interface combinations(via ieee80211_iface_combination) then it shall
      be treated as a single incompatible interface. Fixes the following
      warning on suspend/resume with ibss interface.
      
              ath: phy0: Cannot create ADHOC interface when other
              interfaces already exist.
              WARNING: at net/mac80211/driver-ops.h:12
              ieee80211_reconfig+0x1882/0x1ca0 [mac80211]()
              Hardware name: 2842RK1
              wlan2:  Failed check-sdata-in-driver check, flags: 0x0
      
              Call Trace:
              [<c01361b2>] warn_slowpath_common+0x72/0xa0
              [<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
              [mac80211]
              [<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
              [mac80211]
              [<c0136283>] warn_slowpath_fmt+0x33/0x40
              [<f8aaa7c2>] ieee80211_reconfig+0x1882/0x1ca0 [mac80211]
              [<c06c1d1a>] ? mutex_lock_nested+0x23a/0x2f0
              [<f8a95097>] ieee80211_resume+0x27/0x70 [mac80211]
              [<fd177edf>] wiphy_resume+0x8f/0xa0 [cfg80211]
      
      Cc: stable@vger.kernel.org
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: default avatarMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2031b4c2
  7. 09 Jun, 2012 4 commits
  8. 08 Jun, 2012 10 commits