1. 14 7月, 2012 1 次提交
  2. 11 7月, 2012 1 次提交
  3. 01 7月, 2012 1 次提交
    • B
      e1000e: remove use of IP payload checksum · 2e1706f2
      Bruce Allan 提交于
      Currently only used when packet split mode is enabled with jumbo frames,
      IP payload checksum (for fragmented UDP packets) is mutually exclusive with
      receive hashing offload since the hardware uses the same space in the
      receive descriptor for the hardware-provided packet checksum and the RSS
      hash, respectively.  Users currently must disable jumbos when receive
      hashing offload is enabled, or vice versa, because of this incompatibility.
      Since testing has shown that IP payload checksum does not provide any real
      benefit, just remove it so that there is no longer a choice between jumbos
      or receive hashing offload but not both as done in other Intel GbE drivers
      (e.g. e1000, igb).
      
      Also, add a missing check for IP checksum error reported by the hardware;
      let the stack verify the checksum when this happens.
      
      CC: stable <stable@vger.kernel.org> [3.4]
      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>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e1706f2
  4. 14 6月, 2012 1 次提交
  5. 06 6月, 2012 1 次提交
  6. 05 5月, 2012 1 次提交
  7. 04 5月, 2012 2 次提交
  8. 03 5月, 2012 3 次提交
  9. 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
  10. 01 5月, 2012 1 次提交
  11. 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
  12. 25 4月, 2012 1 次提交
    • P
      e1000e: MSI interrupt test failed, using legacy interrupt · 569a3aff
      Prasanna S Panchamukhi 提交于
      Following logs where seen on Systems with multiple NICs,
      while using MSI interrupts as shown below:
      
      Feb 16 15:09:32 (none) user.notice kernel: 0000:00:0d.0: lan0_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:32 (none) user.notice kernel: 0000:40:0d.0: wan0_1: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:32 (none) user.notice kernel: 0000:40:0d.0: lan0_1: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:32 (none) user.warn kernel: 0000:40:0e.0: wan4_0: MSI interrupt
      test failed, using legacy interrupt.
      Feb 16 15:09:32 (none) user.notice kernel: 0000:00:0e.0: wan1_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0e.0: lan1_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0f.0: wan2_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0f.0: lan2_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:40:0a.0: wan3_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:40:0a.0: lan3_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0e.0: lan4_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0f.0: wan5_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0f.0: lan5_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      
      This patch fixes this problem by increasing the msleep from 50 to 100.
      Signed-off-by: NPrasanna S Panchamukhi <ppanchamukhi@riverbed.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      569a3aff
  13. 04 4月, 2012 6 次提交
  14. 28 3月, 2012 1 次提交
  15. 20 3月, 2012 1 次提交
  16. 01 3月, 2012 2 次提交
  17. 25 2月, 2012 3 次提交
  18. 24 2月, 2012 3 次提交
  19. 14 2月, 2012 2 次提交
  20. 10 2月, 2012 2 次提交
  21. 07 2月, 2012 5 次提交