1. 14 Jun, 2010 20 commits
  2. 08 Jun, 2010 8 commits
  3. 07 Jun, 2010 9 commits
  4. 06 Jun, 2010 3 commits
    • Daniel Halperin's avatar
      iwlwifi: fix wrapping when handling aggregated batches · f668da2f
      Daniel Halperin authored
      Fairly complex code in iwlagn_tx_status_reply_tx handle the status reports for
      aggregated packet batches sent by the NIC. This code aims to handle the case
      where the NIC retransmits failed packets from a previous batch; the status
      information for these packets can sometimes be inserted in the middle of a
      batch and are actually not in order by sequence number! (I verified this can
      happen with printk's in the function.)
      
      The code in question adaptively identifies the "first" frame of the batch,
      taking into account that it may not be the one corresponding to the first agg
      status report, and also handles the case when the set of sent packets wraps the
      256-character entry buffer. It generates the agg->bitmap field of sent packets
      which is later compared to the BlockAck response from the receiver to see which
      frames of those sent in this batch were ACKed. A small logic error (wrapping by
      0xff==255 instead of 0x100==256) was causing the agg->bitmap to be set
      incorrectly.
      
      Fix this wrapping code, and add extensive comments to clarify what is going on.
      Signed-off-by: default avatarDaniel Halperin <dhalperi@cs.washington.edu>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      f668da2f
    • Daniel Halperin's avatar
      iwlwifi: parse block ack responses correctly · 02cd8dee
      Daniel Halperin authored
      Compressed BlockAck frames store the ACKs/NACKs in a 64-bit bitmap that starts
      at the sequence number of the first frame sent in the aggregated batch. Note
      that this is a selective ACKnowledgement following selective retransmission;
      e.g., if frames 1,4-5 in a batch are ACKed then the next transmission will
      include frames 2-3,6-10 (7 frames). In this latter case, the Compressed
      BlockAck will not have all meaningful information in the low order bits -- the
      semantically meaningful bits of the BA will be 0x1f3 (where the low-order frame
      is seq 2).
      
      The driver code originally just looked at the lower (in this case, 7) bits of
      the BlockAck. In this case, the lower 7 bits of 0x1f3 => only 5 packets,
      maximum, could ever be ACKed. In reality it should be looking at all of the
      bits, filtered by those corresponding to packets that were actually sent. This
      flaw meant that the number of correctly ACked packets could be significantly
      underreported and might result in asynchronous state between TX and RX sides as
      well as driver and uCode.
      
      Fix this and also add a shortcut that doesn't require the code to loop through
      all 64 bits of the bitmap but rather stops when no higher packets are ACKed.
      
      In my experiments this fix greatly reduces throughput swing, making throughput
      stable and high. It is also likely related to some of the stalls observed in
      aggregation mode and maybe some of the buffer underruns observed, e.g.,
      
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1968
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2098
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2018Signed-off-by: default avatarDaniel Halperin <dhalperi@cs.washington.edu>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      02cd8dee
    • Wey-Yi Guy's avatar
      iwlwifi: remove unused parameter · 18ab9f1e
      Wey-Yi Guy authored
      framecnt_to_us is not used, remove it
      Signed-off-by: default avatarWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      18ab9f1e