Re: Question about dev.fxp.0.noflow

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