Question about dev.fxp.0.noflow
Pyun YongHyeon
pyunyh at gmail.com
Wed Dec 19 18:06:27 PST 2007
On Thu, Dec 20, 2007 at 04:37:20AM +0300, Andrey Chernov wrote:
> On Thu, Dec 20, 2007 at 10:25:22AM +0900, Pyun YongHyeon wrote:
> > On Wed, Dec 19, 2007 at 04:33:44AM +0300, Andrey Chernov wrote:
> > > Does anybody know why dev.fxp.0.noflow=1 by default?
> > > Is it more proper to set it to 0? (by default or via /etc/sysctl.conf)
> > >
> >
> > Since flow control is valid only when link partner also agrees on
> > advertised pause capability on full-duplex media, it needs more work
> > in mii/phy driver to advertise correct pause capability. It also needs
> > a way to pass negotiated pause capability back to drvier such that
> > each drvier should program necessary flow control parameters depending
> > on its MAC capability and negociated ones. Just enabling flow control
> > on one side have no effect.
>
> I also found this note in the commit log:
>
> date: 2003/05/16 01:13:16; author: rwatson; state: Exp; lines: +5 -1
> Add a tunable/sysctl "hw.fxp_noflow" which disables flow control support
> on if_fxp cards. When flow control is enabled, if the operating system
> doesn't acknowledge the packet buffer filling, the card will begin to
> generate ethernet quench packets, but appears to get into a feedback
> loop of some sort, hosing local switches. This is a temporary workaround
> for 5.1: the ability to configure flow control should probably be
> exposed by some or another management interface on ethernet link layer
> devices.
>
> Does it mean card hardware defect or lack of driver support? I.e. is this
> phrase
> "When flow control is enabled, if the operating system doesn't acknowledge
> the packet buffer filling"
> still true with latest drivers framework (the note as old as 2003)?
>
I'm not familiar with fxp(4) but it would be lack of driver support.
I can't see any special things on flow control in 82559 datasheet.
Also I can hardly believe flow control capability of fxp(4) works as
expected because it doesn't check negotiated link capability. At
least fxp(4) should have a handler for miibus_statchg method that will
decide which pause capability would be activated depending on duplex
state/link partner pause capability .
--
Regards,
Pyun YongHyeon
More information about the freebsd-current
mailing list