1. 10 Jul, 2009 1 commit
    • Johannes Berg's avatar
      mac80211: push rx status into skb->cb · f1d58c25
      Johannes Berg authored
      
      
      Within mac80211, we often need to copy the rx status into
      skb->cb. This is wasteful, as drivers could be building it
      in there to start with. This patch changes the API so that
      drivers are expected to pass the RX status in skb->cb, now
      accessible as IEEE80211_SKB_RXCB(skb). It also updates all
      drivers to pass the rx status in there, but only by making
      them memcpy() it into place before the call to the receive
      function (ieee80211_rx(_irqsafe)). Each driver can now be
      optimised on its own schedule.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f1d58c25
  2. 22 May, 2009 4 commits
  3. 22 Apr, 2009 1 commit
  4. 09 Feb, 2009 2 commits
  5. 29 Jan, 2009 5 commits
  6. 19 Dec, 2008 1 commit
    • Zhu Yi's avatar
      iwlwifi: use GFP_KERNEL to allocate Rx SKB memory · f1bc4ac6
      Zhu Yi authored
      
      
      Previously we allocate Rx SKB with GFP_ATOMIC flag. This is because we need
      to hold a spinlock to protect the two rx_used and rx_free lists operation
      in the rxq.
      
      	spin_lock();
      	...
      	element = rxq->rx_used.next;
      	element->skb = alloc_skb(..., GFP_ATOMIC);
      	list_del(element);
      	list_add_tail(&element->list, &rxq->rx_free);
      	...
      	spin_unlock();
      
      After spliting the rx_used delete and rx_free insert into two operations,
      we don't require the skb allocation in an atomic context any more (the
      function itself is scheduled in a workqueue).
      
      	spin_lock();
      	...
      	element = rxq->rx_used.next;
      	list_del(element);
      	...
      	spin_unlock();
      	...
      	element->skb = alloc_skb(..., GFP_KERNEL);
      	...
      	spin_lock()
      	...
      	list_add_tail(&element->list, &rxq->rx_free);
      	...
      	spin_unlock();
      
      This patch should fix the "iwlagn: Can not allocate SKB buffers" warning
      we see recently.
      Signed-off-by: default avatarZhu Yi <yi.zhu@intel.com>
      Acked-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f1bc4ac6
  7. 12 Dec, 2008 7 commits
  8. 25 Nov, 2008 1 commit
  9. 21 Nov, 2008 2 commits
  10. 18 Nov, 2008 1 commit
    • Johannes Berg's avatar
      iwlagn: fix RX skb alignment · 4018517a
      Johannes Berg authored
      So I dug deeper into the DMA problems I had with iwlagn and a kind soul
      helped me in that he said something about pci-e alignment and mentioned
      the iwl_rx_allocate function to check for crossing 4KB boundaries. Since
      there's 8KB A-MPDU support, crossing 4k boundaries didn't seem like
      something the device would fail with, but when I looked into the
      function for a minute anyway I stumbled over this little gem:
      
      	BUG_ON(rxb->dma_addr & (~DMA_BIT_MASK(36) & 0xff));
      
      Clearly, that is a totally bogus check, one would hope the compiler
      removes it entirely. (Think about it)
      
      After fixing it, I obviously ran into it, nothing guarantees the
      alignment the way you want it,  because of the way skbs and their
      headroom are allocated. I won't explain that here nor double-check that
      I'm right, that goes beyond what most of the CC'ed people care about.
      
      So then I came up with the patch below, and so far my system has
      survived minutes with 64K pages, when it would previously fail in
      seconds. And I haven't seen a single instance of the TX bug either. But
      when you see the patch it'll be pretty obvious to you why.
      
      This should fix the following reported kernel bugs:
      
      http://bugzilla.kernel.org/show_bug.cgi?id=11596
      http://bugzilla.kernel.org/show_bug.cgi?id=11393
      http://bugzilla.kernel.org/show_bug.cgi?id=11983
      
      
      
      I haven't checked if there are any elsewhere, but I suppose RHBZ will
      have a few instances too...
      
      I'd like to ask anyone who is CC'ed (those are people I know ran into
      the bug) to try this patch.
      
      I am convinced that this patch is correct in spirit, but I haven't
      understood why, for example, there are so many unmap calls. I'm not
      entirely convinced that this is the only bug leading to the TX reply
      errors.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4018517a
  11. 31 Oct, 2008 1 commit
  12. 30 Sep, 2008 1 commit
  13. 15 Sep, 2008 1 commit
  14. 03 Sep, 2008 1 commit
  15. 22 Aug, 2008 1 commit
  16. 04 Aug, 2008 1 commit
  17. 14 Jul, 2008 1 commit
  18. 02 Jul, 2008 1 commit
  19. 30 Jun, 2008 5 commits
  20. 14 Jun, 2008 1 commit
  21. 03 Jun, 2008 1 commit