1. 30 7月, 2013 1 次提交
  2. 26 6月, 2013 1 次提交
    • G
      net/tg3: Avoid delay during MMIO access · 6d446ec3
      Gavin Shan 提交于
      When the EEH error is the result of a fenced host bridge, MMIO accesses
      can be very slow (milliseconds) to timeout and return all 1's,
      thus causing the driver various timeout loops to take way too long and
      trigger soft-lockup warnings (in addition to taking minutes to recover).
      
      It might be worthwhile to check if for any of these cases, ffffffff is
      a valid possible value, and if not, bail early since that means the HW
      is either gone or isolated. In the meantime, checking that the PCI channel
      is offline would be workaround of the problem.
      
      Cc: <stable@vger.kernel.org> # v3.0+
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d446ec3
  3. 18 6月, 2013 1 次提交
    • M
      tg3: Prevent system hang during repeated EEH errors. · 72bb72b0
      Michael Chan 提交于
      The current tg3 code assumes the pci_error_handlers to be always called
      in sequence.  In particular, during ->error_detected(), NAPI is disabled
      and the device is shutdown.  The device is later reset and NAPI
      re-enabled in ->slot_reset() and ->resume().
      
      In EEH, if more than 6 errors are detected in a hour, only
      ->error_detected() will be called.  This will leave the driver in an
      inconsistent state as NAPI is disabled but netif_running state is still
      true.  When the device is later closed, we'll try to disable NAPI again
      and it will loop forever.
      
      We fix this by closing the device if we encounter any error conditions
      during the normal sequence of the pci_error_handlers.
      
      v2: Remove the changes in tg3_io_resume() based on Benjamin Poirier's
          feedback.
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NNithin Nayak Sujir <nsujir@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72bb72b0
  4. 13 6月, 2013 1 次提交
    • N
      tg3: Wait for boot code to finish after power on · df465abf
      Nithin Sujir 提交于
      Some systems that don't need wake-on-lan may choose to power down the
      chip on system standby. Upon resume, the power on causes the boot code
      to startup and initialize the hardware. On one new platform, this is
      causing the device to go into a bad state due to a race between the
      driver and boot code, once every several hundred resumes. The same race
      exists on open since we come up from a power on.
      
      This patch adds a wait for boot code signature at the beginning of
      tg3_init_hw() which is common to both cases. If there has not been a
      power-off or the boot code has already completed, the signature will be
      present and poll_fw() returns immediately. Also return immediately if
      the device does not have firmware.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NNithin Nayak Sujir <nsujir@broadcom.com>
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      df465abf
  5. 05 6月, 2013 1 次提交
  6. 03 6月, 2013 1 次提交
  7. 25 5月, 2013 6 次提交
  8. 23 5月, 2013 3 次提交
  9. 20 5月, 2013 4 次提交
  10. 15 5月, 2013 2 次提交
  11. 01 5月, 2013 1 次提交
  12. 30 4月, 2013 1 次提交
  13. 20 4月, 2013 2 次提交
  14. 17 4月, 2013 1 次提交
  15. 10 4月, 2013 11 次提交
  16. 28 3月, 2013 1 次提交
  17. 18 3月, 2013 1 次提交
  18. 13 3月, 2013 1 次提交