]> CyberLeo.Net >> Repos - FreeBSD/stable/8.git/commit
MFC r219407:
authoryongari <yongari@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Sun, 27 Mar 2011 23:13:02 +0000 (23:13 +0000)
committeryongari <yongari@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Sun, 27 Mar 2011 23:13:02 +0000 (23:13 +0000)
commitd36e867704281600c8937655162b3e51390cee9c
tree324aa37ede5b639efbc64e093067037cf50bcde0
parent2029dd07fec76efcb7140db89bbe12174c4374d5
MFC r219407:
  Rearrange dc_tx_underrun() a bit to correctly set TX FIFO threshold
  value. Controllers that always require "store and forward" mode(
  Davicom and PNIC 82C168) have no way to recover from TX underrun
  except completely reinitializing hardware. Previously only Davicom
  was reinitialized and the TX FIFO threshold was changed not to use
  "store and forward" mode after reinitialization since the default
  FIFO threshold value was 0. This effectively disabled Davicom
  controller's "store and forward" mode once it encountered TX
  underruns. In theory, this can cause watchodg timeouts.

  Intel 21143 controller requires TX MAC should be idle before
  changing TX FIFO threshold. So driver tried to disable TX MAC and
  checked whether it saw the idle state of TX MAC. Driver should
  perform full hardware reinitialization on failing to enter to idle
  state and it should not touch TX MAC again once it performed full
  reinitialization.

  While I'm here remove resetting TX FIFO threshold to 0 when
  interface is put into down state. If driver ever encountered TX
  underrun, it's likely to trigger TX underrun again whenever
  interface is brought to up again. Keeping old/learned TX FIFO
  threshold value shall reduce the chance of seeing TX underrns in
  next run.

git-svn-id: svn://svn.freebsd.org/base/stable/8@220078 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/dev/dc/if_dc.c