1. 08 3月, 2013 1 次提交
  2. 05 2月, 2013 6 次提交
  3. 01 2月, 2013 1 次提交
  4. 30 1月, 2013 1 次提交
    • B
      e1000e: enable ECC on I217/I218 to catch packet buffer memory errors · 28600304
      Bruce Allan 提交于
      In rare instances, memory errors have been detected in the internal packet
      buffer memory on I217/I218 when stressed under certain environmental
      conditions.  Enable Error Correcting Code (ECC) in hardware to catch both
      correctable and uncorrectable errors.  Correctable errors will be handled
      by the hardware.  Uncorrectable errors in the packet buffer will cause the
      packet to be received with an error indication in the buffer descriptor
      causing the packet to be discarded.  If the uncorrectable error is in the
      descriptor itself, the hardware will stop and interrupt the driver
      indicating the error.  The driver will then reset the hardware in order to
      clear the error and restart.
      
      Both types of errors will be accounted for in statistics counters.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Cc: <stable@vger.kernel.org> # 3.5.x & 3.6.x
      Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28600304
  5. 28 1月, 2013 4 次提交
  6. 27 1月, 2013 5 次提交
  7. 18 1月, 2013 2 次提交
  8. 16 1月, 2013 1 次提交
    • B
      e1000e: unexpected "Reset adapter" message when cable pulled · 12d43f7d
      Bruce Allan 提交于
      When there is heavy traffic and the cable is pulled, the driver must reset
      the adapter to flush the Tx queue in hardware.  This causes the reset path
      to be scheduled and logs the message "Reset adapter" which could be mis-
      interpreted as an error by the user.  Change how the reset path is invoked
      for this scenario by using the same method done in an existing work-around
      for 80003es2lan (i.e. set a flag and if the flag is set in the reset code
      do not log the "Reset adapter" message since the reset is expected).
      
      Re-name the FLAG_RX_RESTART_NOW to FLAG_RESTART_NOW since it is used for
      resets in both the Rx and Tx specific code.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      12d43f7d
  9. 01 12月, 2012 1 次提交
  10. 11 10月, 2012 1 次提交
    • H
      e1000e: Change wthresh to 1 to avoid possible Tx stalls · 8edc0e62
      Hiroaki SHIMODA 提交于
      This patch originated from Hiroaki SHIMODA but has been modified
      by Intel with some minor cleanups and additional commit log text.
      
      Denys Fedoryshchenko and others reported Tx stalls on e1000e with
      BQL enabled.  Issue was root caused to hardware delays. They were
      introduced because some of the e1000e hardware with transmit
      writeback bursting enabled, waits until the driver does an
      explict flush OR there are WTHRESH descriptors to write back.
      
      Sometimes the delays in question were on the order of seconds,
      causing visible lag for ssh sessions and unacceptable tx
      completion latency, especially for BQL enabled kernels.
      
      To avoid possible Tx stalls, change WTHRESH back to 1.
      
      The current plan is to investigate a method for re-enabling
      WTHRESH while not harming BQL, but those patches will be later
      for net-next if they work.
      
      please enqueue for stable since v3.3 as this bug was introduced in
      commit 3f0cfa3b
      Author: Tom Herbert <therbert@google.com>
      Date:   Mon Nov 28 16:33:16 2011 +0000
      
          e1000e: Support for byte queue limits
      
          Changes to e1000e to use byte queue limits.
      Reported-by: NDenys Fedoryshchenko <denys@visp.net.lb>
      Tested-by: NDenys Fedoryshchenko <denys@visp.net.lb>
      Signed-off-by: NHiroaki SHIMODA <shimoda.hiroaki@gmail.com>
      CC: eric.dumazet@gmail.com
      CC: therbert@google.com
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8edc0e62
  11. 31 8月, 2012 1 次提交
    • B
      e1000e: DoS while TSO enabled caused by link partner with small MSS · d821a4c4
      Bruce Allan 提交于
      With a low enough MSS on the link partner and TSO enabled locally, the
      networking stack can periodically send a very large (e.g.  64KB) TCP
      message for which the driver will attempt to use more Tx descriptors than
      are available by default in the Tx ring.  This is due to a workaround in
      the code that imposes a limit of only 4 MSS-sized segments per descriptor
      which appears to be a carry-over from the older e1000 driver and may be
      applicable only to some older PCI or PCIx parts which are not supported in
      e1000e.  When the driver gets a message that is too large to fit across the
      configured number of Tx descriptors, it stops the upper stack from queueing
      any more and gets stuck in this state.  After a timeout, the upper stack
      assumes the adapter is hung and calls the driver to reset it.
      
      Remove the unnecessary limitation of using up to only 4 MSS-sized segments
      per Tx descriptor, and put in a hard failure test to catch when attempting
      to check for message sizes larger than would fit in the whole Tx ring.
      Refactor the remaining logic that limits the size of data per Tx descriptor
      from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
      Tx packet buffer as described in the hardware specification.
      
      Also, fix the logic in the check for space in the Tx ring for the next
      largest possible packet after the current one has been successfully queued
      for transmit, and use the appropriate defines for default ring sizes in
      e1000_probe instead of magic values.
      
      This issue goes back to the introduction of e1000e in 2.6.24 when it was
      split off from e1000.
      Reported-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Cc: Stable <stable@vger.kernel.org> [2.6.24+]
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d821a4c4
  12. 14 7月, 2012 1 次提交
  13. 04 5月, 2012 1 次提交
  14. 03 5月, 2012 1 次提交
  15. 02 5月, 2012 1 次提交
    • B
      e1000e: fix .ndo_set_rx_mode for 82579 · 69e1e019
      Bruce Allan 提交于
      Secondary unicast and multicast addresses are added to the Receive
      Address registers (RAR) for most parts supported by the driver.  For
      82579, there is only one actual RAR and a number of Shared Receive Address
      registers (SHRAR) that are shared among the driver and f/w which can be
      reserved and write-protected by the f/w.  On this device, use the SHRARs
      that are not taken by f/w for the additional addresses.
      
      Add a MAC ops function pointer infrastructure (similar to other MAC
      operations in the driver) for setting RARs, introduce a new rar_set
      function for 82579 and convert the existing code that sets RARs on other
      devices to a generic rar_set function.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      69e1e019
  16. 27 4月, 2012 1 次提交
    • B
      e1000e: 82579 potential system hang on stress when ME enabled · bdc125f7
      Bruce Allan 提交于
      Previously, a workaround was added to address a hardware bug in the
      PCIm2PCI arbiter where a write by the driver of the Transmit/Receive
      Descriptor Tail register could happen concurrently with a write of any
      MAC CSR register by the Manageability Engine (ME) which could cause the
      Tail register to have an incorrect value.  The arbiter is supposed to
      prevent the concurrent writes but there is a bug that can cause the Host
      (driver) access to be acknowledged later than it should.
      After further investigation, it was discovered that a driver write access
      of any MAC CSR register after being idle for some time can be lost when
      ME is accessing a MAC CSR register.  When this happens, no further target
      access is claimed by the MAC which could hang the system.
      The workaround to check bit 24 in the FWSM register (set only when ME is
      accessing a MAC CSR register) and delay for a limited amount of time until
      it is cleared is now done for all driver writes of MAC CSR registers on
      82579 with ME enabled.  In the rare case when the driver is writing the
      Tail register and ME is accessing any MAC CSR register for a duration
      longer than the maximum delay, write the register and verify it has the
      correct value before continuing, otherwise reset the device.
      
      This patch also moves some pre-existing macros from the hardware-specific
      header file to the more appropriate generic driver header file.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      bdc125f7
  17. 04 4月, 2012 1 次提交
  18. 25 2月, 2012 6 次提交
  19. 24 2月, 2012 1 次提交
  20. 27 1月, 2012 2 次提交
  21. 26 1月, 2012 1 次提交