1. 23 4月, 2009 1 次提交
  2. 10 2月, 2009 2 次提交
  3. 30 1月, 2009 5 次提交
  4. 20 12月, 2008 1 次提交
    • Z
      iwlwifi: use GFP_KERNEL to allocate Rx SKB memory · f1bc4ac6
      Zhu Yi 提交于
      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: NZhu Yi <yi.zhu@intel.com>
      Acked-by: NTomas Winkler <tomas.winkler@intel.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f1bc4ac6
  5. 13 12月, 2008 7 次提交
  6. 26 11月, 2008 1 次提交
  7. 22 11月, 2008 2 次提交
  8. 19 11月, 2008 1 次提交
    • J
      iwlagn: fix RX skb alignment · 4018517a
      Johannes Berg 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4018517a
  9. 01 11月, 2008 1 次提交
  10. 01 10月, 2008 1 次提交
  11. 16 9月, 2008 1 次提交
  12. 04 9月, 2008 1 次提交
  13. 23 8月, 2008 1 次提交
  14. 05 8月, 2008 1 次提交
  15. 15 7月, 2008 1 次提交
  16. 03 7月, 2008 1 次提交
  17. 01 7月, 2008 5 次提交
  18. 15 6月, 2008 1 次提交
  19. 04 6月, 2008 2 次提交
  20. 15 5月, 2008 3 次提交