summaryrefslogtreecommitdiffstats
path: root/contrib/tzdata/southamerica
diff options
context:
space:
mode:
authoryongari <yongari@FreeBSD.org>2011-03-08 19:49:16 +0000
committeryongari <yongari@FreeBSD.org>2011-03-08 19:49:16 +0000
commit8a28fc08af90ae83c8aee55e730f4b572d83d418 (patch)
treec3151d37dbedaf68af52b7422e19472bf9d30136 /contrib/tzdata/southamerica
parentdbea1b3e681b1fc859d0cc2c85a3c5093e8da5b2 (diff)
downloadFreeBSD-src-8a28fc08af90ae83c8aee55e730f4b572d83d418.zip
FreeBSD-src-8a28fc08af90ae83c8aee55e730f4b572d83d418.tar.gz
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.
Diffstat (limited to 'contrib/tzdata/southamerica')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud