1. 11 11月, 2014 8 次提交
  2. 04 11月, 2014 1 次提交
  3. 31 10月, 2014 1 次提交
  4. 29 10月, 2014 26 次提交
  5. 24 10月, 2014 4 次提交
    • E
      iwlwifi: pcie: fix polling in various places · 7f2ac8fb
      Emmanuel Grumbach 提交于
      iwl_poll_bit may return a strictly positive value when the
      poll doesn't match on the first try.
      This was caught when WoWLAN started failing upon resume
      even if the poll_bit actually succeeded.
      
      Also change a wrong print. If we reach the end of
      iwl_pcie_prepare_card_hw, it means that we couldn't
      get the devices.
      Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
      Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      7f2ac8fb
    • E
      Revert "iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate" · 1ffde699
      Emmanuel Grumbach 提交于
      This reverts commit aa11bbf3.
      This commit was causing connection issues and is not needed
      if IWL_MVM_RS_RSSI_BASED_INIT_RATE is set to false by default.
      
      Regardless of the issues mentioned above, this patch added the
      following WARNING:
      
      WARNING: CPU: 0 PID: 3946 at drivers/net/wireless/iwlwifi/mvm/tx.c:190 iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]()
      Got an HT rate for a non data frame 0x8
      CPU: 0 PID: 3946 Comm: wpa_supplicant Tainted: G           O   3.17.0+ #6
      Hardware name: LENOVO 20ANCTO1WW/20ANCTO1WW, BIOS GLET71WW (2.25 ) 07/02/2014
       0000000000000009 ffffffff814fa911 ffff8804288db8f8 ffffffff81064f52
       0000000000001808 ffff8804288db948 ffff88040add8660 ffff8804291b5600
       0000000000000000 ffffffff81064fb7 ffffffffa07b73d0 0000000000000020
      Call Trace:
       [<ffffffff814fa911>] ? dump_stack+0x41/0x51
       [<ffffffff81064f52>] ? warn_slowpath_common+0x72/0x90
       [<ffffffff81064fb7>] ? warn_slowpath_fmt+0x47/0x50
       [<ffffffffa07a39ea>] ? iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]
       [<ffffffffa07a3cf8>] ? iwl_mvm_tx_skb+0x48/0x3c0 [iwlmvm]
       [<ffffffffa079cb9b>] ? iwl_mvm_mac_tx+0x7b/0x180 [iwlmvm]
       [<ffffffffa0746ce9>] ? __ieee80211_tx+0x2b9/0x3c0 [mac80211]
       [<ffffffffa07492f3>] ? ieee80211_tx+0xb3/0x100 [mac80211]
       [<ffffffffa0749c49>] ? ieee80211_subif_start_xmit+0x459/0xca0 [mac80211]
       [<ffffffff814116e7>] ? dev_hard_start_xmit+0x337/0x5f0
       [<ffffffff81430d46>] ? sch_direct_xmit+0x96/0x1f0
       [<ffffffff81411ba3>] ? __dev_queue_xmit+0x203/0x4f0
       [<ffffffff8142f670>] ? ether_setup+0x70/0x70
       [<ffffffff814e96a1>] ? packet_sendmsg+0xf81/0x1110
       [<ffffffff8140625c>] ? skb_free_datagram+0xc/0x40
       [<ffffffff813f7538>] ? sock_sendmsg+0x88/0xc0
       [<ffffffff813f7274>] ? move_addr_to_kernel.part.20+0x14/0x60
       [<ffffffff811c47c2>] ? __inode_wait_for_writeback+0x62/0xb0
       [<ffffffff813f7a91>] ? SYSC_sendto+0xf1/0x180
       [<ffffffff813f88f9>] ? __sys_recvmsg+0x39/0x70
       [<ffffffff8150066d>] ? system_call_fastpath+0x1a/0x1f
      ---[ end trace cc19a150d311fc63 ]---
      
      which was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=85691
      
      CC: <stable@vger.kernel.org> [3.13+]
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      1ffde699
    • E
      iwlwifi: dvm: drop non VO frames when flushing · a0855054
      Emmanuel Grumbach 提交于
      When mac80211 wants to ensure that a frame is sent, it calls
      the flush() callback. Until now, iwldvm implemented this by
      waiting that all the frames are sent (ACKed or timeout).
      In case of weak signal, this can take a significant amount
      of time, delaying the next connection (in case of roaming).
      Many users have reported that the flush would take too long
      leading to the following error messages to be printed:
      
      iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2
      iwlwifi 0000:03:00.0: Current SW read_ptr 161 write_ptr 201
      iwl data: 00000000: 00 00 00 00 00 00 00 00 fe ff 01 00 00 00 00 00
      [snip]
      iwlwifi 0000:03:00.0: FH TRBs(0) = 0x00000000
      [snip]
      iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [9,9]
      [snip]
      
      Instead of waiting for these packets, simply drop them. This
      significantly improves the responsiveness of the network.
      Note that all the queues are flushed, but the VO one. This
      is not typically used by the applications and it likely
      contains management frames that are useful for connection
      or roaming.
      
      This bug is tracked here:
      https://bugzilla.kernel.org/show_bug.cgi?id=56581
      
      But it is duplicated in distributions' trackers.
      A simple search in Ubuntu's database led to these bugs:
      
      https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1270808
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305406
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356236
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1360597
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1361809
      
      Cc: <stable@vger.kernel.org>
      Depends-on: 77be2c54 ("mac80211: add vif to flush call")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      a0855054
    • M
      iwlwifi: mvm: ROC - bug fixes around time events and locking · a6cc5163
      Matti Gottlieb 提交于
      Don't add the time event to the list. We added it several
      times the same time event, which leads to an infinite loop
      when walking the list.
      
      Since we (currently) don't support more than one ROC for STA
      vif at a time, enforce this and don't add the time event
      to any list.
      
      We were also missing the locking of the mutex which led to
      a lockdep splat - fix that.
      Signed-off-by: NMatti Gottlieb <matti.gottlieb@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      a6cc5163