1. 15 5月, 2014 1 次提交
  2. 13 5月, 2014 1 次提交
  3. 11 5月, 2014 4 次提交
    • E
      iwlwifi: mvm: fix setting channel in monitor mode · 1c4abec0
      Emmanuel Grumbach 提交于
      There was a deadlock in monitor mode when we were setting the
      channel if the channel was not 1.
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.14.3 #4 Not tainted
      -------------------------------------------------------
      iw/3323 is trying to acquire lock:
       (&local->chanctx_mtx){+.+.+.}, at: [<ffffffffa062e2f2>] ieee80211_vif_release_channel+0x42/0xb0 [mac80211]
      
      but task is already holding lock:
       (&local->iflist_mtx){+.+...}, at: [<ffffffffa0609e0a>] ieee80211_set_monitor_channel+0x5a/0x1b0 [mac80211]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (&local->iflist_mtx){+.+...}:
             [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0
             [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0
             [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0
             [<ffffffffa06225cf>] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
             [<ffffffffa0518189>] iwl_mvm_recalc_multicast+0x49/0xa0 [iwlmvm]
             [<ffffffffa051822e>] iwl_mvm_configure_filter+0x4e/0x70 [iwlmvm]
             [<ffffffffa05e6d43>] ieee80211_configure_filter+0x153/0x5f0 [mac80211]
             [<ffffffffa05e71f5>] ieee80211_reconfig_filter+0x15/0x20 [mac80211]
             [snip]
      
      -> #1 (&mvm->mutex){+.+.+.}:
             [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0
             [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0
             [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0
             [<ffffffffa0517246>] iwl_mvm_add_chanctx+0x56/0xe0 [iwlmvm]
             [<ffffffffa062ca1e>] ieee80211_new_chanctx+0x13e/0x410 [mac80211]
             [<ffffffffa062d953>] ieee80211_vif_use_channel+0x1c3/0x5a0 [mac80211]
             [<ffffffffa06035ab>] ieee80211_add_virtual_monitor+0x1ab/0x6b0 [mac80211]
             [<ffffffffa06052ea>] ieee80211_do_open+0xe6a/0x15a0 [mac80211]
             [<ffffffffa0605a79>] ieee80211_open+0x59/0x60 [mac80211]
             [snip]
      
      -> #0 (&local->chanctx_mtx){+.+.+.}:
             [<ffffffff810d6cb7>] check_prevs_add+0x977/0x980
             [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0
             [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0
             [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0
             [<ffffffffa062e2f2>] ieee80211_vif_release_channel+0x42/0xb0 [mac80211]
             [<ffffffffa0609ec3>] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211]
             [<ffffffffa058fb37>] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211]
             [<ffffffffa056e0b2>] __nl80211_set_channel+0x122/0x140 [cfg80211]
             [<ffffffffa0581374>] nl80211_set_wiphy+0x284/0xaf0 [cfg80211]
             [snip]
      
      other info that might help us debug this:
      
      Chain exists of:
        &local->chanctx_mtx --> &mvm->mutex --> &local->iflist_mtx
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&local->iflist_mtx);
                                     lock(&mvm->mutex);
                                     lock(&local->iflist_mtx);
        lock(&local->chanctx_mtx);
      
       *** DEADLOCK ***
      
      This deadlock actually occurs:
      INFO: task iw:3323 blocked for more than 120 seconds.
            Not tainted 3.14.3 #4
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      iw              D ffff8800c8afcd80  4192  3323   3322 0x00000000
       ffff880078fdb7e0 0000000000000046 ffff8800c8afcd80 ffff880078fdbfd8
       00000000001d5540 00000000001d5540 ffff8801141b0000 ffff8800c8afcd80
       ffff880078ff9e38 ffff880078ff9e38 ffff880078ff9e40 0000000000000246
      Call Trace:
       [<ffffffff817ea841>] schedule_preempt_disabled+0x31/0x80
       [<ffffffff817ebaed>] mutex_lock_nested+0x19d/0x4f0
       [<ffffffffa06225cf>] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
       [<ffffffffa06225cf>] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
       [<ffffffffa052a680>] ? iwl_mvm_power_mac_update_mode+0xc0/0xc0 [iwlmvm]
       [<ffffffffa06225cf>] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
       [<ffffffffa0529357>] _iwl_mvm_power_update_binding+0x27/0x80 [iwlmvm]
       [<ffffffffa0516eb1>] iwl_mvm_unassign_vif_chanctx+0x81/0xc0 [iwlmvm]
       [<ffffffffa062d3ff>] __ieee80211_vif_release_channel+0xdf/0x470 [mac80211]
       [<ffffffffa062e2fa>] ieee80211_vif_release_channel+0x4a/0xb0 [mac80211]
       [<ffffffffa0609ec3>] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211]
       [<ffffffffa058fb37>] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211]
       [<ffffffffa056e0b2>] __nl80211_set_channel+0x122/0x140 [cfg80211]
       [<ffffffffa0581374>] nl80211_set_wiphy+0x284/0xaf0 [cfg80211]
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75541
      
      Cc: <stable@vger.kernel.org> [3.13+]
      Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      1c4abec0
    • D
      iwlwifi: mvm: stop sched scan before association · 723f02ed
      David Spinadel 提交于
      Stop sched scan on bss_info_changed if !idle to avoid sched scan
      during association.
      Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
      Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      723f02ed
    • D
      iwlwifi: mvm: notify sched scan complete from stop routine · 636a2cdc
      David Spinadel 提交于
      Add an option to notify mac80211 about sched scan complete from
      iwl_mvm_stop_sched_scan(), to enable this notification when the
      stop was called from within the driver.
      Signed-off-by: NDavid Spinadel <david.spinadel@intel.com>
      Reviewed-by: NAlexander Bondar <alexander.bondar@intel.com>
      Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      636a2cdc
    • J
      iwlwifi: add missing trailing newlines to debug messages · 3c6acb61
      Johannes Berg 提交于
      All messages should have a trailing newline, add all the
      missing ones. Also make all messages constants, replacing
      the single one that pointlessly used a variable.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      3c6acb61
  4. 07 5月, 2014 4 次提交
  5. 14 4月, 2014 5 次提交
  6. 13 4月, 2014 3 次提交
  7. 19 3月, 2014 3 次提交
    • E
      iwlwifi: mvm: disable uAPSD due to bugs in the firmware · a82dda6c
      Emmanuel Grumbach 提交于
      The current firmware advertises support for uAPSD, but
      critical bugs force us to disable the feature.
      When a fixed firmware will be available, we will be able to
      re-enable uAPSD.
      
      Cc: <stable@vger.kernel.org> [3.13+]
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      a82dda6c
    • A
      iwlwifi: mvm: restructure scan parameters calculation · 8a110d9b
      Alexander Bondar 提交于
      Some scan parameters should be dependent on traffic conditions.
      Centralize conditions verification in one function and obtain
      scan max out-of-channel and suspend time in that new function.
      Rely on bound interfaces indication instead of association state
      to calculate scan parameters. If no bound interfaces use default
      values for out-of-channel and suspend time parameters.
      
      Additionally, get rid of NL80211_SCAN_FLAG_LOW_PRIORITY checks
      since no use case for this exists so far.
      Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com>
      [reword commit log a bit]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      8a110d9b
    • E
      iwlwifi: mvm: send udev event upon firmware error to dump logs · 1bd3cbc1
      Emmanuel Grumbach 提交于
      When the firmware asserts, the driver will dump the firmware
      state to an internal buffer. This buffer is kept aside until
      it is dumped through debugfs. Once an external application
      fetched the data, the buffer is freed and a new buffer can
      be allocated in case another assert occurs.
      
      A udev event is sent to trigger an external application.
      
      A simple rule like:
      DRIVER=="iwlwifi", ACTION=="change", RUN+="/sbin/dump_sram.sh"
      
      can fetch the data from debugfs.
      
      Here is my dump_sram.sh:
      
      phyname=$(basename ${DEVPATH})
      date=$(date +%F_%H_%M)
      filename=/var/log/iwl-sram-${phyname}-${date}.bin
      cat /sys/kernel/debug/ieee80211/${phyname}/iwlwifi/iwlmvm/fw_error_dump > ${filename}
      
      The current SRAM size is 80KB so, currently:
      $ ls -lh iwl-sram-phy0-2014-03-16_13_14.bin
      -rw-r--r-- 1 emmanuel emmanuel 81K Mar 16 13:15 iwl-sram-phy0-2014-03-16_13_14.bin
      
      and after compression:
      $ ls -lh iwl-sram-phy0-2014-03-16_13_14.bin.xz
      -rw-r--r-- 1 emmanuel emmanuel 13K Mar 16 13:15 iwl-sram-phy0-2014-03-16_13_14.bin.xz
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      1bd3cbc1
  8. 16 3月, 2014 3 次提交
  9. 10 3月, 2014 3 次提交
  10. 20 2月, 2014 1 次提交
  11. 13 2月, 2014 4 次提交
  12. 07 2月, 2014 1 次提交
  13. 04 2月, 2014 7 次提交