1. 31 3月, 2011 1 次提交
  2. 14 1月, 2011 1 次提交
  3. 10 1月, 2011 1 次提交
  4. 17 12月, 2010 1 次提交
  5. 11 12月, 2010 1 次提交
  6. 28 11月, 2010 1 次提交
  7. 22 11月, 2010 1 次提交
  8. 02 11月, 2010 1 次提交
  9. 25 10月, 2010 1 次提交
  10. 21 10月, 2010 2 次提交
  11. 27 9月, 2010 1 次提交
  12. 24 9月, 2010 3 次提交
  13. 23 9月, 2010 1 次提交
  14. 09 9月, 2010 1 次提交
    • J
      e1000: fix Tx hangs by disabling 64-bit DMA · e508be17
      Jesse Brandeburg 提交于
      Several users report issues with 32-bit adapters when plugged
      into PCI slots in machines with >= 4GB ram.  In particular AMD
      systems with HyperTransport to PCI bridges seem to trigger the
      issue, but it isn't limited to only them.
      
      This issue is not easily reproducible here, yet still continues
      to occur in the field.  For e1000 on PCI devices, just disable DMA
      addresses over the 4GB boundary when in PCI (not PCI-X) mode, to
      prevent the issue from continuing to pop up.  The performance
      impact for this is negligible.
      
      The code was refactored to move the init of the hw struct to its
      own function. This allows the init to be called very early in
      probe, which then allows using hw-> members for this fix.
      
      A slight refactor to the DMA mask code was done for minor
      correctness based on the instructions in DMA-API-HOWTO.
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e508be17
  15. 03 9月, 2010 1 次提交
  16. 26 8月, 2010 1 次提交
  17. 09 8月, 2010 1 次提交
    • J
      e100/e1000*/igb*/ixgb*: Add missing read memory barrier · 2d0bb1c1
      Jeff Kirsher 提交于
      Based on patches from Sonny Rao and Milton Miller...
      
      Combined the patches to fix up clean_tx_irq and clean_rx_irq.
      
      The PowerPC architecture does not require loads to independent bytes
      to be ordered without adding an explicit barrier.
      
      In ixgbe_clean_rx_irq we load the status bit then load the packet data.
      With packet split disabled if these loads go out of order we get a
      stale packet, but we will notice the bad sequence numbers and drop it.
      
      The problem occurs with packet split enabled where the TCP/IP header
      and data are in different descriptors. If the reads go out of order
      we may have data that doesn't match the TCP/IP header. Since we use
      hardware checksumming this bad data is never verified and it makes it
      all the way to the application.
      
      This bug was found during stress testing and adding this barrier has
      been shown to fix it.  The bug can manifest as a data integrity issue
      (bad payload data) or as a BUG in skb_pull().
      
      This was a nasty bug to hunt down, if people agree with the fix I think
      it's a candidate for stable.
      
      Previously Submitted to e1000-devel only for ixgbe
      
      http://marc.info/?l=e1000-devel&m=126593062701537&w=3
      
      We've now seen this problem hit with other device drivers (e1000e mostly)
      So I'm resubmitting with fixes for other Intel Device Drivers with
      similar issues.
      
      CC: Milton Miller <miltonm@bga.com>
      CC: Anton Blanchard <anton@samba.org>
      CC: Sonny Rao <sonnyrao@us.ibm.com>
      CC: stable <stable@kernel.org>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d0bb1c1
  18. 27 7月, 2010 1 次提交
  19. 14 6月, 2010 1 次提交
  20. 14 5月, 2010 3 次提交
  21. 06 5月, 2010 1 次提交
  22. 28 4月, 2010 2 次提交
  23. 15 4月, 2010 1 次提交
  24. 04 4月, 2010 1 次提交
    • J
      net: convert multicast list to list_head · 22bedad3
      Jiri Pirko 提交于
      Converts the list and the core manipulating with it to be the same as uc_list.
      
      +uses two functions for adding/removing mc address (normal and "global"
       variant) instead of a function parameter.
      +removes dev_mcast.c completely.
      +exposes netdev_hw_addr_list_* macros along with __hw_addr_* functions for
       manipulation with lists on a sandbox (used in bonding and 80211 drivers)
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22bedad3
  25. 27 3月, 2010 1 次提交
  26. 23 2月, 2010 3 次提交
  27. 04 2月, 2010 2 次提交
  28. 26 1月, 2010 1 次提交
  29. 23 1月, 2010 1 次提交
    • J
      e1000/e1000e: don't use small hardware rx buffers · 9926146b
      Jesse Brandeburg 提交于
      When testing the "e1000: enhance frame fragment detection" (and e1000e)
      patches we found some bugs with reducing the MTU size.  The 1024 byte
      descriptor used with the 1000 mtu test also (re) introduced the
      (originally) reported bug, and causes us to need the e1000_clean_tx_irq
      "enhance frame fragment detection" fix.
      
      So what has occured here is that 2.6.32 is only vulnerable for mtu <
      1500 due to the jumbo specific routines in both e1000 and e1000e.
      So, 2.6.32 needs the 2kB buffer len fix for those smaller MTUs, but
      is not vulnerable to the original issue reported.  It has been pointed
      out that this vulnerability needs to be patched in older kernels that
      don't have the e1000 jumbo routine.  Without the jumbo routines, we
      need the "enhance frame fragment detection" fix the e1000, old
      e1000e is only vulnerable for < 1500 mtu, and needs a similar
      fix.  We split the patches up to provide easy backport paths.
      
      There is only a slight bit of extra code when this fix and the
      original "enhance frame fragment detection" fixes are applied, so
      please apply both, even though it is a bit of overkill.
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9926146b
  30. 21 1月, 2010 2 次提交