1. 29 1月, 2008 2 次提交
    • A
      e1000/e1000e: Move PCI-Express device IDs over to e1000e · 040babf9
      Auke Kok 提交于
      e1000e will from now on support the PCI-Express adapters that
      previously were supported by e1000. This support means better
      performance and easier debugging from now on for both the old
      PCI-X/PCI hardware and PCI-Express adapters.
      
      This patch also moves 3 recently merged device IDs over to e1000e
      that are identical to quad-port versions of already existing
      dual port versions. With this last bit every former e1000 pci-e
      device should work now with e1000e.
      
      Here is a brief list of which gigabit driver to use with which
      adapter:
      
        e1000:
      	82540 -> 82547
      
        e1000e:
      	82571 -> 82573
      	ich8, ich9       (82562 or 82566)
      	es2lan           (80003eslan)
      
        igb: (not yet merged, only available from e1000.sf.net)
      	82575
      Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      040babf9
    • A
      e1000e: Disable L1 ASPM power savings for 82573 mobile variants · 1eae4eb2
      Auke Kok 提交于
      L1 ASPM link (pci-e link power savings) has significant benefits
      (~1W savings when link is active) but unfortunately does not work
      correctly on any of the chipsets that have 82573 on mobile platforms
      which causes various nuisances:
       - eeprom reads return garbage information leading to bad eeprom
         checksums
       - long ping times (up to 2 seconds)
       - complete system hangs (freeze/lockup)
      
      A lot of T60 owners have been plagued by this, but other mobile
      solutions also suffer from these symptoms.
      
      Disabling L1 ASPM before we activate the PCI-E link fixes all of
      these issues at the cost of some power consumption.
      
      Remove a workaround RDTR adjustment that is no longer needed with
      this new one.
      Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      1eae4eb2
  2. 21 1月, 2008 1 次提交
    • D
      [NET]: Fix interrupt semaphore corruption in Intel drivers. · 49d85c50
      David S. Miller 提交于
      Several of the Intel ethernet drivers keep an atomic counter used to
      manage when to actually hit the hardware with a disable or an enable.
      
      The way the net_rx_work() breakout logic works during a pending
      napi_disable() is that it simply unschedules the poll even if it
      still has work.
      
      This can potentially leave interrupts disabled, but that is OK
      because all of the drivers are about to disable interrupts
      anyways in all such code paths that do a napi_disable().
      
      Unfortunately, this trips up the semaphore used here in the Intel
      drivers.  If you hit this case, when you try to bring the interface
      back up it won't enable interrupts.  A reload of the driver module
      fixes it of course.
      
      So what we do is make sure all the sequences now go:
      
      	napi_disable();
      	atomic_set(&adapter->irq_sem, 0);
      	*_irq_disable();
      
      which makes sure the counter is always in the correct state.
      
      Reported by Robert Olsson.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      49d85c50
  3. 17 1月, 2008 1 次提交
  4. 09 1月, 2008 2 次提交
  5. 29 10月, 2007 4 次提交
  6. 11 10月, 2007 6 次提交