1. 01 12月, 2012 1 次提交
  2. 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
  3. 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
  4. 14 7月, 2012 1 次提交
  5. 04 5月, 2012 1 次提交
  6. 03 5月, 2012 1 次提交
  7. 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
  8. 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
  9. 04 4月, 2012 1 次提交
  10. 25 2月, 2012 6 次提交
  11. 24 2月, 2012 1 次提交
  12. 27 1月, 2012 2 次提交
  13. 26 1月, 2012 3 次提交
  14. 05 12月, 2011 1 次提交
  15. 16 10月, 2011 1 次提交
    • B
      e1000e: locking bug introduced by commit 67fd4fcb · a90b412c
      Bruce Allan 提交于
      Commit 67fd4fcb (e1000e: convert to stats64) added the ability to update
      statistics more accurately and on-demand through the net_device_ops
      .ndo_get_stats64 hook, but introduced a locking bug on 82577/8/9 when
      linked at half-duplex (seen on kernels with CONFIG_DEBUG_ATOMIC_SLEEP=y and
      CONFIG_PROVE_LOCKING=y).  The commit introduced code paths that caused a
      mutex to be locked in atomic contexts, e.g. an rcu_read_lock is held when
      irqbalance reads the stats from /sys/class/net/ethX/statistics causing the
      mutex to be locked to read the Phy half-duplex statistics registers.
      
      The mutex was originally introduced to prevent concurrent accesses of
      resources (the NVM and Phy) shared by the driver, firmware and hardware
      a few years back when there was an issue with the NVM getting corrupted.
      It was later split into two mutexes - one for the NVM and one for the Phy
      when it was determined the NVM, unlike the Phy, should not be protected by
      the software/firmware/hardware semaphore (arbitration of which is done in
      part with the SWFLAG bit in the EXTCNF_CTRL register).  This latter
      semaphore should be sufficient to prevent resource contention of the Phy in
      the driver (i.e. the mutex for Phy accesses is not needed), but to be sure
      the mutex is replaced with an atomic bit flag which will warn if any
      contention is possible.
      
      Also add additional debug output to help determine when the sw/fw/hw
      semaphore is owned by the firmware or hardware.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Reported-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
      a90b412c
  16. 05 10月, 2011 1 次提交
  17. 27 8月, 2011 1 次提交
  18. 19 8月, 2011 1 次提交
  19. 11 8月, 2011 1 次提交
  20. 13 7月, 2011 1 次提交
  21. 12 7月, 2011 1 次提交
  22. 10 6月, 2011 3 次提交
    • B
      e1000e: Clear host wakeup bit on 82577/8 without touching PHY page 800 · 3ebfc7c9
      Bruce Allan 提交于
      The Host Wakeup Active bit in the PHY Port General Configuration register
      (page 769 register 17) must be cleared after every PHY reset to prevent an
      unexpected wake signal from the PHY. Originally, this was accomplished by
      simply reading the PHY Wakeup Control register on page 800 which clears the
      Host Wakeup Active bit as a side-effect. Unfortunately, a hardware bug on
      the 82577 and 82578 PHY can cause unexpected behavior when registers on
      page 800 are accessed while in gigabit mode.
      
      This patch changes the remaining instances when the Host Wakeup Active bit
      needs to be cleared while possibly in gigabit mode by accessing the Port
      General Configuration register directly instead of accessing any register
      on page 800.
      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>
      3ebfc7c9
    • B
      e1000e: access multiple PHY registers on same page at the same time · 2b6b168d
      Bruce Allan 提交于
      Doing a PHY page select can take a long time, relatively speaking. This
      can cause a significant delay when updating a number of PHY registers on
      the same page by unnecessarily setting the page for each PHY access. For
      example when going to Sx, all the PHY wakeup registers (WUC, RAR[], MTA[],
      SHRAR[], IP4AT[], IP6AT[], etc.) on 82577/8/9 need to be updated which
      takes a long time which can cause issues when suspending.
      
      This patch introduces new PHY ops function pointers to allow callers to
      set the page directly and do any number of PHY accesses on that page.
      This feature is currently only implemented for 82577, 82578 and 82579
      PHYs for both the normally addressed registers as well as the special-
      case addressing of the PHY wakeup registers on page 800. For the latter
      registers, the existing function for accessing the wakeup registers has
      been divided up into three- 1) enable access to the wakeup register page,
      2) perform the register access and 3) disable access to the wakeup register
      page. The two functions that enable/disable access to the wakeup register
      page are necessarily available to the caller so that the caller can restore
      the value of the Port Control (a.k.a. Wakeup Enable) register after the
      wakeup register accesses are done.
      
      All instances of writing to multiple PHY registers on the same page are
      updated to use this new method and to acquire any PHY locking mechanism
      before setting the page and performing the register accesses, and release
      the locking mechanism afterward.
      
      Some affiliated magic number cleanup is done as well.
      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>
      2b6b168d
    • B
      e1000e: 82579 intermittently disabled during S0->Sx · 99730e4c
      Bruce Allan 提交于
      When repeatedly cycling Sx->S0 states with the network cable unplugged,
      the 82579 PHY may not initialize as expected and may require a full power
      cycle to recover functionality to the device.  Workaround this by testing
      access of the PHY registers after resuming; if that returns unexpected
      results toggle the LANPHYPC signal to power cycle the PHY.
      
      This is implemented in the new function e1000_resume_workarounds_pchlan()
      which calls another new function, e1000_toggle_lanphypc_value_ich8lan(),
      which has been created to reduce code duplication (same functionality
      required by a previous workaround).  Also, e1000e_disable_gig_wol_ich8lan
      is now e1000_suspend_workarounds_ich8lan to better reflect what it does.
      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>
      99730e4c
  23. 27 4月, 2011 1 次提交
  24. 14 4月, 2011 2 次提交
  25. 24 1月, 2011 1 次提交
  26. 14 1月, 2011 1 次提交
  27. 10 1月, 2011 2 次提交
  28. 11 12月, 2010 1 次提交