1. 14 2月, 2012 17 次提交
  2. 01 2月, 2012 1 次提交
  3. 24 1月, 2012 1 次提交
  4. 18 1月, 2012 1 次提交
    • M
      tg3: Fix single-vector MSI-X code · c3b5003b
      Matt Carlson 提交于
      Kdump kernels leave MSI-X interrupts (as setup by the crashed kernel)
      enabled.  However, kdump only enables one CPU in the new environment,
      thus causing tg3 to abort MSI-X setup.  When the driver attempts to
      enable INTA or MSI interrupt modes on a kdump kernel, interrupt
      delivery fails.
      
      This patch attempts to workaround the problem by forcing the driver
      to enable a single MSI-X interrupt.  In such a configuration, the
      device's multivector interrupt mode must be disabled.
      Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c3b5003b
  5. 20 12月, 2011 2 次提交
  6. 16 12月, 2011 5 次提交
  7. 09 12月, 2011 6 次提交
  8. 30 11月, 2011 1 次提交
  9. 29 11月, 2011 2 次提交
    • M
      tg3: Scale back code that modifies MRRS · 2c55a3d0
      Matt Carlson 提交于
      Tg3 normally gets a performance boost by increasing the PCI Maximum Read
      Request Size (MRRS) to 4k.  Unfortunately, this is causing some problems
      on particular hardware platforms.  This patch removes all code that
      modifies the MRRS except for one case.
      
      As part of a solution to fix an internal FIFO problem on the 5719, the
      driver artificially capped the MRRS to 2k for the entire 5719, and later
      5720, ASIC revs.  This was overly aggressive and only really needed to
      be done for the 5719 A0.  In the spirit of the rest of this patch, the
      driver will only reprogram the MRRS for this device if the value exceeds
      the 2k cap.
      Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c55a3d0
    • M
      tg3: Fix TSO CAP for 5704 devs w / ASF enabled · cf9ecf4b
      Matt Carlson 提交于
      On the earliest TSO capable devices, TSO was accomplished through
      firmware.  The TSO cannot coexist with ASF management firmware though.
      The tg3 driver determines whether or not ASF is enabled by calling
      tg3_get_eeprom_hw_cfg(), which checks a particular bit of NIC memory.
      Commit dabc5c67, entitled "tg3: Move
      TSO_CAPABLE assignment", accidentally moved the code that determines
      TSO capabilities earlier than the call to tg3_get_eeprom_hw_cfg().  As a
      consequence, the driver was attempting to determine TSO capabilities
      before it had all the data it needed to make the decision.
      
      This patch fixes the problem by revisiting and reevaluating the decision
      after tg3_get_eeprom_hw_cfg() is called.
      Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf9ecf4b
  10. 23 11月, 2011 4 次提交