1. 28 Mar, 2013 1 commit
    • Johannes Berg's avatar
      iwlwifi: dvm: fix the passive-no-RX workaround · b8730b40
      Johannes Berg authored
      Alex Romosan reported that since the mac80211 changes in
      "mac80211: start auth/assoc timeout on frame status" and
      the subsequent fixes in "mac80211: fix auth/assoc timeout
      handling" (commits 1672c0e3 and 89afe614) there's
      sometimes an issue connecting to a 5 GHz network with the
      iwlwifi DVM driver.
      
      The reason appears to be that since these commits any bad
      TX status makes mac80211 immediately try again, causing
      all of the authentication attempts to be quickly rejected
      by the firmware as it hasn't heard a beacon yet. Before,
      it would wait for the timeout regardless of status.
      
      To fix this, invoke the passive-no-RX workaround when not
      associated yet as well. This will cause the first frame
      to get lost, but then the driver will stop the queues and
      the second attempt will only be transmitted after hearing
      a beacon, thus delaying it appropriately to not make the
      firmware reject it again.
      Reported-by: default avatarAlex Romosan <romosan@sycorax.lbl.gov>
      Tested-by: default avatarAlex Romosan <romosan@sycorax.lbl.gov>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b8730b40
  2. 20 Mar, 2013 3 commits
  3. 04 Mar, 2013 7 commits
  4. 28 Feb, 2013 4 commits
    • Johannes Berg's avatar
      iwlwifi: use coherent DMA memory for command header · 38c0f334
      Johannes Berg authored
      Recently in commit 8a964f44
      ("iwlwifi: always copy first 16 bytes of commands") we fixed
      the problem that the hardware writes back to the command and
      that could overwrite parts of the data that was still needed
      and would thus be corrupted.
      
      Investigating this problem more closely we found that this
      write-back isn't really ordered very well with respect to
      other DMA traffic. Therefore, it sometimes happened that the
      write-back occurred after unmapping the command again which
      is clearly an issue and could corrupt the next allocation
      that goes to that spot, or (better) cause IOMMU faults.
      
      To fix this, allocate coherent memory for the first 16 bytes
      of each command, containing the write-back part, and use it
      for all queues. All the dynamic DMA mappings only need to be
      TO_DEVICE then. This ensures that even when the write-back
      happens "too late" it can't hit memory that has been freed
      or a mapping that doesn't exist any more.
      
      Since now the actual command is no longer modified, we can
      also remove CMD_WANT_HCMD and get rid of the DMA sync that
      was necessary to update the scratch pointer.
      Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      38c0f334
    • Emmanuel Grumbach's avatar
      iwlwifi: disable 8K A-MSDU by default · aed7d9ac
      Emmanuel Grumbach authored
      Supporting 8K A-MSDU means that we need to allocate order 1
      pages for every Rx packet. Even when there is no traffic.
      This adds stress on the memory manager. The handling of
      compound pages is also less trivial for the memory manager
      and not using them will make the allocation code run faster
      although I didn't really measure.
      Eric also pointed out that having huge buffers with little
      data in them is not very nice towards the TCP stack since
      the truesize of the skb is huge. This doesn't allow TCP
      to have a big Rx window.
      See https://patchwork.kernel.org/patch/2167711/ for details.
      
      Note that very few vendors will actually send A-MSDU.
      Disable this feature by default.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      aed7d9ac
    • Johannes Berg's avatar
      iwlwifi: rename IWL_MAX_CMD_TFDS to IWL_MAX_CMD_TBS_PER_TFD · 1afbfb60
      Johannes Berg authored
      The IWL_MAX_CMD_TFDS name for this constant is wrong, the
      constant really indicates how many TBs we can use in the
      driver for a single command TFD, rename the constant and
      also add a comment explaining it.
      Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1afbfb60
    • Johannes Berg's avatar
      iwlwifi: don't map complete commands bidirectionally · 98891754
      Johannes Berg authored
      The reason we mapped them bidirectionally was that not doing
      so had caused IOMMU exceptions, due to the fact that the HW
      writes back into the command. Now that the first part of the
      command including the write-back part is always in the first
      buffer, we don't need to map the remaining buffer(s) bidi
      and can get rid of the special-casing for commands.
      
      This is a requisite patch for another one to fix DMA mapping.
      Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      98891754
  5. 27 Feb, 2013 2 commits
  6. 26 Feb, 2013 2 commits
    • Johannes Berg's avatar
      iwlwifi: mvm: fix AP/GO mode station removal · 38a12b5b
      Johannes Berg authored
      When stations are removed while packets are in the queue,
      we drain the queues first, and then remove the stations.
      If this happens in AP mode while the interface is removed
      the MAC context might be removed from the firmware before
      we removed the station(s), resulting in a SYSASSERT 3421.
      This is because we remove the MAC context from the FW in
      stop_ap(), but only flush the station drain work later in
      remove_interface().
      
      Refactor the code a bit to have a common MAC context
      removal preparation first to solve this.
      Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      38a12b5b
    • Johannes Berg's avatar
      iwlwifi: always copy first 16 bytes of commands · 8a964f44
      Johannes Berg authored
      The FH hardware will always write back to the scratch field
      in commands, even host commands not just TX commands, which
      can overwrite parts of the command. This is problematic if
      the command is re-used (with IWL_HCMD_DFL_NOCOPY) and can
      cause calibration issues.
      
      Address this problem by always putting at least the first
      16 bytes into the buffer we also use for the command header
      and therefore make the DMA engine write back into this.
      
      For commands that are smaller than 16 bytes also always map
      enough memory for the DMA engine to write back to.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8a964f44
  7. 22 Feb, 2013 3 commits
  8. 18 Feb, 2013 18 commits