1. 18 1月, 2013 2 次提交
  2. 16 1月, 2013 5 次提交
  3. 09 1月, 2013 1 次提交
  4. 08 12月, 2012 1 次提交
  5. 04 12月, 2012 1 次提交
    • B
      net/intel: remove __dev* attributes · 9f9a12f8
      Bill Pemberton 提交于
      CONFIG_HOTPLUG is going away as an option.  As result the __dev*
      markings will be going away.
      
      Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
      and __devexit.
      Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Cc: Bruce Allan <bruce.w.allan@intel.com>
      Cc: Carolyn Wyborny <carolyn.wyborny@intel.com>
      Cc: Don Skidmore <donald.c.skidmore@intel.com>
      Cc: Greg Rose <gregory.v.rose@intel.com>
      Cc: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
      Cc: Alex Duyck <alexander.h.duyck@intel.com>
      Cc: John Ronciak <john.ronciak@intel.com>
      Cc: Tushar Dave <tushar.n.dave@intel.com>
      Cc: e1000-devel@lists.sourceforge.net
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f9a12f8
  6. 01 12月, 2012 1 次提交
  7. 23 10月, 2012 1 次提交
  8. 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
  9. 09 10月, 2012 1 次提交
  10. 08 9月, 2012 1 次提交
  11. 31 8月, 2012 5 次提交
  12. 24 8月, 2012 1 次提交
  13. 09 8月, 2012 1 次提交
  14. 14 7月, 2012 1 次提交
  15. 11 7月, 2012 1 次提交
  16. 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
  17. 14 6月, 2012 1 次提交
  18. 06 6月, 2012 1 次提交
  19. 05 5月, 2012 1 次提交
  20. 04 5月, 2012 2 次提交
  21. 03 5月, 2012 3 次提交
  22. 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
  23. 01 5月, 2012 1 次提交
  24. 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
  25. 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
  26. 04 4月, 2012 3 次提交