Date: Mon, 9 Feb 2009 01:38:01 +0000 (UTC) From: Pyun YongHyeon <yongari@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/dev/re if_re.c src/sys/pci if_rlreg.h Message-ID: <200902090138.n191cEQW073848@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
yongari 2009-02-09 01:38:01 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_7)
sys/dev/re if_re.c
sys/pci if_rlreg.h
Log:
SVN rev 188359 on 2009-02-09 01:38:01Z by yongari
MFC r186214,186389,187417
r186214:
It seems that RealTek PCIe controllers require an explicit Tx poll
command whenever Tx completion interrupt is raised. The Tx poll
bit is cleared when all packets waiting to be transferred have been
processed. This means the second Tx poll command can be silently
ignored as the Tx poll bit could be still active while processing
of previous Tx poll command is in progress.
To address the issue re(4) used to invoke the Tx poll command in Tx
completion handler whenever it detects there are pending packets in
TxQ. However that still does not seem to completely eliminate
watchdog timeouts seen on RealTek PCIe controllers. To fix the
issue kick Tx poll command only after Tx completion interrupt is
raised as this would indicate Tx is now idle state such that it can
accept new Tx poll command again. While here apply this workaround
for PCIe based controllers as other controllers does not seem to
have this limitation.
r186389:
Since we don't request reset for rlphy(4), the link state 'UP'
event from mii(4) may not be delivered if valid link was already
established. To address the issue, check current link state after
driving MII_TICK. This should fix a regression introduced in
r185753 on fast ethernet controllers.
r187417:
Sometimes RTL8168B seems to take long time to access GMII registers
in device attach phase. Double GMII register access timeout value
to fix the issue.
Revision Changes Path
1.95.2.41 +21 -14 src/sys/dev/re/if_re.c
1.67.2.20 +2 -0 src/sys/pci/if_rlreg.h
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200902090138.n191cEQW073848>