1. 12 2月, 2010 1 次提交
  2. 20 1月, 2010 1 次提交
  3. 22 12月, 2009 1 次提交
  4. 08 12月, 2009 1 次提交
  5. 01 12月, 2009 1 次提交
    • J
      mac80211: fix spurious delBA handling · 827d42c9
      Johannes Berg 提交于
      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: NLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      827d42c9
  6. 24 11月, 2009 1 次提交
  7. 19 11月, 2009 2 次提交
    • J
      mac80211: convert aggregation to operate on vifs/stas · c951ad35
      Johannes Berg 提交于
      The entire aggregation code currently operates on the
      hw pointer and station addresses, but that needs to
      change to make stations purely per-vif; As one step
      preparing for that make the aggregation code callable
      with the station, or by the combination of virtual
      interface and station address.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c951ad35
    • J
      iwlwifi: handle unicast PS buffering · 6ab10ff8
      Johannes Berg 提交于
      Using the new mac80211 functionality, this makes
      iwlwifi handle unicast PS buffering correctly.
      The device works like this:
      
       * when a station goes to sleep, the microcode notices
         this and marks the station as asleep
       * when the station is marked asleep, the microcode
         refuses to transmit to the station and rejects all
         frames queued to it with the failure status code
         TX_STATUS_FAIL_DEST_PS (a previous patch handled
         this correctly)
       * when we need to send frames to the station _although_
         it is asleep, we need to tell the ucode how many,
         and this is asynchronous with sending so we cannot
         just send the frames, we need to wait for all other
         frames to be flushed, and then update the counter
         before sending out the poll response frames. This
         is handled partially in the driver and partially in
         mac80211.
      
      In order to do all this correctly, we need to
       * keep track of how many frames are pending for each
         associated client station (avoid doing it for other
         stations to avoid the atomic ops)
       * tell mac80211 that we driver-block the PS status
         while there are still frames pending on the queues,
         and once they are all rejected (due to the dest sta
         being in PS) unblock mac80211
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6ab10ff8
  8. 12 11月, 2009 2 次提交
  9. 03 11月, 2009 2 次提交
  10. 28 10月, 2009 4 次提交
  11. 12 10月, 2009 1 次提交
  12. 08 10月, 2009 3 次提交
    • J
      iwlwifi: device tracing · be1a71a1
      Johannes Berg 提交于
      In order to have an easier way to debug issues, create
      trace events (using the ftrace framework) that will
      allow us to follow exactly what the driver is doing
      with the device.
      
      The text format isn't all that useful, but the binary
      format can also be obtained easily via debugfs and
      then analysed on the fly or offline with debugging
      tools.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      be1a71a1
    • W
      iwlwifi: reliable entering of critical temperature state · 7812b167
      Wey-Yi Guy 提交于
      When uCode detects critical temperature it should send "card state
      notification" interrupt to driver and then shut itself down to prevent
      overheating. There is a race condition where uCode shuts down before it
      can deliver the interrupt to driver.
      Additional method provided here for driver to enter CT_KILL state based
      on temperature reading.
      
      How it works:
      Method 1:
      If driver receive "card state notification" interrupt from uCode; it
      enters "CT_KILL" state immediately
      
      Method 2:
      If the last temperature report by Card reach Critical temperature,
      driver will send "statistic notification" request to uCode to verify the
      temperature reading, if driver can not get reply from uCode within
      300ms, driver will enter CT_KILL state automatically.
      
      Method 3:
      If the last temperature report by Card did not reach Critical
      temperature, but uCode already shut down due to critical temperature.
      All the host commands send to uCode will not get process by uCode;
      when command queue reach the limit, driver will check the last reported
      temperature reading, if it is within pre-defined margin, enter "CT_KILL"
      state immediately. In this case, when uCode ready to exit from "CT_KILL" state,
      driver need to restart the adapter in order to reset all the queues and
      resume normal operation.
      
      One additional issue being address here, when system is in CT_KILL
      state, both tx and rx already stopped, but driver still can send host
      command to uCode, it will flood the command queue since card was not
      responding; adding STATUS_CT_KILL flag to reject enqueue host commands
      to uCode if it is in CT_KILL state, when uCode is ready to come out of
      CT_KILL, driver will clear  the STATUS_CT_KILL bit and allow enqueue the host
      commands to uCode to recover from CT_KILL state.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7812b167
    • D
      iwlwifi: do not clear TX info flags when receiving BlockAckResponse · 91a55ae6
      Daniel C Halperin 提交于
      OR-in AMPDU flags rather than assigning them.  This lets the TX status for
      aggregated packets be processed by rs_tx_status.
      Signed-off-by: NDaniel C Halperin <daniel.c.halperin@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      91a55ae6
  13. 29 9月, 2009 1 次提交
  14. 01 9月, 2009 1 次提交
    • D
      iwlwifi: remove incorrect uses of ieee80211_get_tx_rate to prevent TX stall · b58ef214
      Daniel C Halperin 提交于
      Refactor and correct rate selection for outgoing transmitted
      packets.
      
      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: NDaniel C Halperin <daniel.c.halperin@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b58ef214
  15. 29 8月, 2009 1 次提交
    • G
      iwlwifi: Make injection of non-broadcast frames work again · aa065263
      Gábor Stefanik 提交于
      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
      regression.
      
      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: NGábor Stefanik <netrolller.3d@gmail.com>
      Acked-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      aa065263
  16. 20 8月, 2009 1 次提交
  17. 14 8月, 2009 3 次提交
  18. 05 8月, 2009 1 次提交
  19. 28 7月, 2009 5 次提交
    • R
      iwlwifi: print packet contents in error case · ec741164
      Reinette Chatre 提交于
      This data is more useful to debugging that the receive
      buffer contents.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ec741164
    • J
      iwlwifi: remove command callback return value · 5696aea6
      Johannes Berg 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5696aea6
    • J
      iwlwifi: fix up command sending · c2acea8e
      Johannes Berg 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c2acea8e
    • R
      iwlwifi: Read outside array bounds · 082e708a
      Roel Kluin 提交于
      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: NRoel Kluin <roel.kluin@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      082e708a
    • J
      iwlwifi: fix TX queue race · 3995bd93
      Johannes Berg 提交于
      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:
      
              lock(queues)
              if (stopped(queue)) {
                      unlock(queues)
                      return busy;
      	}
              unlock(queues)
              ...             <-- this place will be important
      			    there is some more code here
              drv_tx(frame)
      
      The driver, on the other hand, can stop and start queues, which does
      
              lock(queues)
              mark_running/stopped(queue)
              unlock(queues)
      
      	[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
      wrong.
      
      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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3995bd93
  20. 25 7月, 2009 2 次提交
    • R
      iwlwifi: inform user about rfkill state changes · 4c423a2b
      Reinette Chatre 提交于
      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: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4c423a2b
    • R
      iwlwifi: make debug level more user friendly · a562a9dd
      Reinette Chatre 提交于
      * 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: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a562a9dd
  21. 22 7月, 2009 1 次提交
  22. 11 7月, 2009 2 次提交
  23. 23 5月, 2009 1 次提交
  24. 23 4月, 2009 1 次提交