1. 19 10月, 2012 4 次提交
  2. 23 9月, 2012 1 次提交
  3. 22 9月, 2012 7 次提交
  4. 20 9月, 2012 2 次提交
  5. 17 9月, 2012 6 次提交
  6. 08 9月, 2012 1 次提交
  7. 05 9月, 2012 3 次提交
  8. 24 8月, 2012 1 次提交
  9. 21 8月, 2012 2 次提交
  10. 09 8月, 2012 2 次提交
  11. 07 8月, 2012 1 次提交
    • S
      igb: add delay to allow igb loopback test to succeed on 8086:10c9 · 119b0e03
      Stefan Assmann 提交于
      Some 8086:10c9 NICs have a problem completing the ethtool loopback test.
      The result looks like this:
      
      ethtool -t eth1
      The test result is FAIL
      The test extra info:
      Register test  (offline)         0
      Eeprom test    (offline)         0
      Interrupt test (offline)         0
      Loopback test  (offline)         13
      Link test   (on/offline)         0
      
      A bisect clearly points to commit a95a0744.
      However that seems to only trigger the bug. While adding some printk the
      problem disappeared, so this might be a timing issue. After some trial and
      error I discovered that adding a small delay just before igb_write_phy_reg()
      in igb_integrated_phy_loopback() allows the loopback test to succeed.
      I was unable to figure out the root cause so far but I expect it to be
      somewhere in the following executing path
      igb_integrated_phy_loopback
      ->igb_write_phy_reg_igp
        ->igb_write_phy_reg_mdic
          ->igb_acquire_phy_82575
            ->igb_acquire_swfw_sync_82575
      
      The problem could only be observed on 8086:10c9 NICs so far and not all
      of them show the behaviour. I did not restrict the workaround to this
      type of NIC as it should do no harm to other igb NICs.
      
      With the patch below the loopback test succeeded 500 times in a row
      using a NIC that would otherwise fail.
      Signed-off-by: NStefan Assmann <sassmann@kpanic.de>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
      119b0e03
  12. 04 8月, 2012 3 次提交
  13. 01 8月, 2012 1 次提交
    • M
      netvm: propagate page->pfmemalloc from skb_alloc_page to skb · 0614002b
      Mel Gorman 提交于
      The skb->pfmemalloc flag gets set to true iff during the slab allocation
      of data in __alloc_skb that the the PFMEMALLOC reserves were used.  If
      page splitting is used, it is possible that pages will be allocated from
      the PFMEMALLOC reserve without propagating this information to the skb.
      This patch propagates page->pfmemalloc from pages allocated for fragments
      to the skb.
      
      It works by reintroducing and expanding the skb_alloc_page() API to take
      an skb.  If the page was allocated from pfmemalloc reserves, it is
      automatically copied.  If the driver allocates the page before the skb, it
      should call skb_propagate_pfmemalloc() after the skb is allocated to
      ensure the flag is copied properly.
      
      Failure to do so is not critical.  The resulting driver may perform slower
      if it is used for swap-over-NBD or swap-over-NFS but it should not result
      in failure.
      
      [davem@davemloft.net: API rename and consistency]
      Signed-off-by: NMel Gorman <mgorman@suse.de>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Christie <michaelc@cs.wisc.edu>
      Cc: Eric B Munson <emunson@mgebm.net>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Christoph Lameter <cl@linux.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0614002b
  14. 22 7月, 2012 1 次提交
  15. 17 7月, 2012 1 次提交
  16. 11 7月, 2012 1 次提交
  17. 20 6月, 2012 3 次提交