1. 30 Nov, 2009 1 commit
    • Johannes Berg's avatar
      mac80211: fix spurious delBA handling · 827d42c9
      Johannes Berg authored
      Lennert Buytenhek noticed that delBA handling in mac80211
      was broken and has remotely triggerable problems, some of
      which are due to some code shuffling I did that ended up
      changing the order in which things were done -- this was
        commit d75636ef
        Author: Johannes Berg <johannes@sipsolutions.net>
        Date:   Tue Feb 10 21:25:53 2009 +0100
          mac80211: RX aggregation: clean up stop session
      and other parts were already present in the original
        commit d92684e6
        Author: Ron Rindjunsky <ron.rindjunsky@intel.com>
        Date:   Mon Jan 28 14:07:22 2008 +0200
            mac80211: A-MPDU Tx add delBA from recipient support
      The first problem is that I moved a BUG_ON before various
      checks -- thereby making it possible to hit. As the comment
      indicates, the BUG_ON can be removed since the ampdu_action
      callback must already exist when the state is != IDLE.
      The second problem isn't easily exploitable but there's a
      race condition due to unconditionally setting the state to
      OPERATIONAL when a delBA frame is received, even when no
      aggregation session was ever initiated. All the drivers
      accept stopping the session even then, but that opens a
      race window where crashes could happen before the driver
      accepts it. Right now, a WARN_ON may happen with non-HT
      drivers, while the race opens only for HT drivers.
      For this case, there are two things necessary to fix it:
       1) don't process spurious delBA frames, and be more careful
          about the session state; don't drop the lock
       2) HT drivers need to be prepared to handle a session stop
          even before the session was really started -- this is
          true for all drivers (that support aggregation) but
          iwlwifi which can be fixed easily. The other HT drivers
          (ath9k and ar9170) are behaving properly already.
      Reported-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  2. 11 Oct, 2009 1 commit
  3. 28 Sep, 2009 1 commit
  4. 31 Aug, 2009 1 commit
    • Daniel C Halperin's avatar
      iwlwifi: remove incorrect uses of ieee80211_get_tx_rate to prevent TX stall · b58ef214
      Daniel C Halperin authored
      Refactor and correct rate selection for outgoing transmitted
      First, note that HT rates in the mac80211 rate table do not provide valid
      indices when ieee80211_get_tx_rate is called; the check to see if we could to
      abort a transmission early in iwl_tx_skb() would thus occasionally read invalid
      memory and occasionally stall transmission (if the erroneous byte was 0xff).
      We remove that code; the check wasn't valid anyway.
      Second, iwl_tx_cmd_build_rate() also called ieee80211_get_tx_rate to be used
      for sending management packets, which do not use the uCode station table.  This
      patch refactors that function and adds comments to enhance legibility, replaces
      the call to ieee80211_get_tx_rate() with a direct lookup, and adds error
      handling in case the table entry is invalid.
      Signed-off-by: default avatarDaniel C Halperin <daniel.c.halperin@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  5. 28 Aug, 2009 1 commit
    • Gábor Stefanik's avatar
      iwlwifi: Make injection of non-broadcast frames work again · aa065263
      Gábor Stefanik authored
      Commit 1ccb84d87d04df3c76cd4352fe69786d8c7cf016 by Wey-Yi Guy
      ("iwlwifi: clean up unused NL80211_IFTYPE_MONITOR for Monitor mode")
      broke injection of non-broadcast frames to unassociated stations
      (causing a SYSASSERT for all such injected frames), due to injected
      frames no longer automatically getting a broadcast station ID assigned.
      This patch restores the old behavior, fixing the aforementioned
      Also, consistently check for IEEE80211_TX_CTL_INJECTED instead of
      iwl_is_monitor_mode in the TX path, as TX_CTL_INJECTED specifically
      means that a given packet is coming from a monitor interface, while
      iwl_is_monitor_mode only shows whether a monitor interface exists
      on the device.
      Signed-off-by: default avatarGábor Stefanik <netrolller.3d@gmail.com>
      Acked-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  6. 20 Aug, 2009 1 commit
  7. 14 Aug, 2009 3 commits
  8. 04 Aug, 2009 1 commit
  9. 27 Jul, 2009 5 commits
    • Reinette Chatre's avatar
      iwlwifi: print packet contents in error case · ec741164
      Reinette Chatre authored
      This data is more useful to debugging that the receive
      buffer contents.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      iwlwifi: remove command callback return value · 5696aea6
      Johannes Berg authored
      No existing callbacks use anything other than the return
      value 1, which means that the caller should free the
      reply skb, so it seems safer in terms of not introducing
      memory leaks to simply remove the return value and let
      the caller always free the skb.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      iwlwifi: fix up command sending · c2acea8e
      Johannes Berg authored
      The current command sending in iwlwifi is a bit of a mess:
       1) there is a struct, iwl_cmd, that contains both driver
          and device data in a single packed structure -- this
          is very confusing
       2) the on-stack data and the command metadata share a
          structure by embedding the latter in the former, which
          is also rather confusing because it leads to weird
          unions and similarly odd constructs
       3) each txq always has enough space for 256 commands,
          even if only 32 end up being used
      This patch fixes these things:
       1) rename iwl_cmd to iwl_device_cmd and keep track of
          command metadata and device command separately, in
          two arrays in each tx queue
       2) remove the 'meta' member from iwl_host_cmd and only
          put in the required members
       3) allocate the cmd/meta arrays separately instead of
          embedding them into the txq structure
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Roel Kluin's avatar
      iwlwifi: Read outside array bounds · 082e708a
      Roel Kluin authored
      tid is bounded (above) by the size of default_tid_to_tx_fifo (17 elements), but
      the size of priv->stations[].tid[] is MAX_TID_COUNT (9) elements.
      Signed-off-by: default avatarRoel Kluin <roel.kluin@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      iwlwifi: fix TX queue race · 3995bd93
      Johannes Berg authored
      I had a problem on 4965 hardware (well, probably other hardware too,
      but others don't survive my stress testing right now, unfortunately)
      where the driver was sending invalid commands to the device, but no
      such thing could be seen from the driver's point of view. I could
      reproduce this fairly easily by sending multiple TCP streams with
      iperf on different TIDs, though sometimes a single iperf stream was
      sufficient. It even happened with a single core, but I have forced
      preemption turned on.
      The culprit was a queue overrun, where we advanced the queue's write
      pointer over the read pointer. After careful analysis I've come to
      the conclusion that the cause is a race condition between iwlwifi
      and mac80211.
      mac80211, of course, checks whether the queue is stopped, before
      transmitting a frame. This effectively looks like this:
              if (stopped(queue)) {
                      return busy;
              ...             <-- this place will be important
      			    there is some more code here
      The driver, on the other hand, can stop and start queues, which does
      	[if marked running: wake up tasklet to send pending frames]
      Now, however, once the driver starts the queue, mac80211 can see that
      and end up at the marked place above, at which point for some reason the
      driver seems to stop the queue again (I don't understand that) and then
      we end up transmitting while the queue is actually full.
      Now, this shouldn't actually matter much, but for some reason I've seen
      it happen multiple times in a row and the queue actually overflows, at
      which point the queue bites itself in the tail and things go completely
      This patch fixes this by just dropping the packet should this have
      happened, and making the lock in iwlwifi cover everything so iwlwifi
      can't race against itself (dropping the lock there might make it more
      likely, but it did seem to happen without that too).
      Since we can't hold the lock across drv_tx() above, I see no way to fix
      this in mac80211, but I also don't understand why I haven't seen this
      before -- maybe I just never stress tested it this badly.
      With this patch, the device has survived many minutes of simultanously
      sending two iperf streams on different TIDs with combined throughput
      of about 60 Mbps.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  10. 24 Jul, 2009 2 commits
    • Reinette Chatre's avatar
      iwlwifi: inform user about rfkill state changes · 4c423a2b
      Reinette Chatre authored
      rfkill state changes are mostly available through debug messages.
      These are significant enough to always make user aware of so
      we turn them into warnings.
      Also insert a missing newline in some rfkill related debug message.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Reinette Chatre's avatar
      iwlwifi: make debug level more user friendly · a562a9dd
      Reinette Chatre authored
      * Deprecate the "debug50" module parameter used to obtain
        5000 series and up debugging. Replace it with "debug" module
        parameter to match with original driver and be consistent
        between them. The "debug50" module parameter can still be used,
        except that the module parameter is not writable in keeping
        with its previous state. We currently just mark it as "deprecated"
        and do not have it in the feature-removal-schedule. Some more
        cleanup of module parameters needs to be done and can then be
        entered together.
      * Only make "debug" module parameters visible if the driver
        is compiled with CONFIG_IWLWIFI_DEBUG. This will eliminate
        a lot of confusion where users think they have set debug flags
        but yet cannot see any debug output.
      * Make module parameters writable. This eliminates the need for the
        "debug_level" sysfs file, which can now also be deprecated and
        added to feature-removal-schedule. This file is in significant
        use though with many iwlwifi documents and text referring users
        to it. We can thus not take its removal lightly and keep it around.
      With iwlcore shared between iwlagn and iwl3945 we really do not need
      debug module parameters for each but can instead have one debug
      module parameter for the iwlcore module. The same issue is here as
      with the sysfs file - a lot of iwlwifi documentation and text (like
      bug reports) rely on iwlagn and iwl3945 having this module parameter,
      so changing this to a module parameter of iwlcore will have significant
      impact and we do not do this for that reason.
      One consequence of this patch is that if a user is running a system
      with both 3945 and later hardware then the setting of the one module
      parameter will affect the value of the other. The likelihood of this
      seems low - and even if this setup is present it does not seem like an
      issue for both modules to run with the same debug level.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  11. 21 Jul, 2009 1 commit
  12. 10 Jul, 2009 2 commits
  13. 22 May, 2009 1 commit
  14. 22 Apr, 2009 2 commits
  15. 21 Apr, 2009 2 commits
    • Reinette Chatre's avatar
      iwlwifi: DMA fixes · df833b1d
      Reinette Chatre authored
      A few issues wrt DMA were uncovered when using the driver with swiotlb.
      - driver should not use memory after it has been mapped
      - iwl3945's RX queue management cannot use all of iwlagn because
        the size of the RX buffer is different. Revert back to using
        iwl3945 specific routines that map/unmap memory.
      - no need to "dma_syn_single_range_for_cpu" followed by pci_unmap_single,
        we can just call pci_unmap_single initially
      - only map the memory area that will be used by device. this is especially
        relevant to the mapping of iwl_cmd. we should not map the entire
        structure because the meta data at the beginning of structure contains
        the address to be used later for unmapping. If the address to be used for
        unmapping is stored in mapped data it creates a problem.
      - ensure that _if_ memory needs to be modified after it is mapped that we
        call _sync_single_for_cpu first, and then release it back to device with
      - we mapped the wrong length of data for host commands, with mapped length
        differing with length provided to device, fix that.
      Thanks to Jason Andryuk <jandryuk@gmail.com> for significant bisecting
      help to find these issues.
      This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1964
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Tested-by: default avatarJason Andryuk <jandryuk@gmail.com>
      Tested-by: default avatarBen Gamari <bgamari@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Reinette Chatre's avatar
      iwlwifi: add debugging for TX path · d2ee9cd2
      Reinette Chatre authored
      When debugging TX issues it is helpful to know the seq nr of the
      frame being transmitted. The seq nr is printed as part of ucode's
      log informing us which frame is being processed. Having this information
      printed in driver log makes it easy to match activities between driver
      and firmware.
      Also make possible to print TX flags directly. These are already printed
      as part of entire TX command, but having it printed directly in cpu format
      makes it easier to look at.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  16. 27 Mar, 2009 3 commits
  17. 27 Feb, 2009 1 commit
  18. 25 Feb, 2009 1 commit
  19. 09 Feb, 2009 2 commits
  20. 29 Jan, 2009 8 commits