Date: Tue, 12 Jul 2011 13:22:14 -0700 From: "David Christensen" <davidch@broadcom.com> To: "Charles Sprickman" <spork@bway.net> Cc: YongHyeon PYUN <pyunyh@gmail.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, David Christensen <davidch@freebsd.org> Subject: RE: bce packet loss Message-ID: <5D267A3F22FD854F8F48B3D2B523819385F12FEBE6@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: <alpine.OSX.2.00.1107112234460.1070@freemac> References: <alpine.OSX.2.00.1107042113000.2407@freemac> <20110706201509.GA5559@michelle.cdnetworks.com> <alpine.OSX.2.00.1107070121060.2407@freemac> <20110707174233.GB8702@michelle.cdnetworks.com> <alpine.OSX.2.00.1107072129310.2407@freemac> <5D267A3F22FD854F8F48B3D2B523819385C32D96B7@IRVEXCHCCR01.corp.ad.broadcom.com> <alpine.OSX.2.00.1107082009350.1070@freemac> <5D267A3F22FD854F8F48B3D2B523819385F12FE86B@IRVEXCHCCR01.corp.ad.broadcom.com> <alpine.OSX.2.00.1107112234460.1070@freemac>
next in thread | previous in thread | raw e-mail | index | archive | help
> > There won't be any indication in the driver since flow control > > is managed in hardware. You'd need a wire capture to see that > > bce(4) has stopped sending frames in response to receiving an > > XOFF flow control frame or started sending frames in response > > to receiving an XON flow control frame. >=20 > Ah. I was hoping for something in the ifconfig output. I'll see if > tcpdump and wireshark can tell me anything about this host. >=20 Flow control frames are consumed by the MAC and aren't passed to the OS stack so you won't see them with a host based packet capture application like tcpdump. You'd need something like a JDSU Xgig protocol analyzer to see them on the wire. > One the one host (w/bce) I just set to full auto, the switch claims to > have negotiated 1000FD w/flow control (this specifically shows as > "auto+enabled" on the switch side). >=20 > I see that the "sysctl dev.bce.1" tree has some info, and I can see that > the NIC is receiving flow control frames: >=20 > dev.bce.1.stat_XonPauseFramesReceived: 16638 > dev.bce.1.stat_XoffPauseFramesReceived: 17239 >=20 > These lines are a bit puzzling though: >=20 > dev.bce.1.stat_FlowControlDone: 0 > dev.bce.1.stat_XoffStateEntered: 0 Auto-negotiation occurs between PHYs and then the link comes up. When link is up bce(4) will configure the MAC based on the auto-neg results returned by brgphy(4) (the switch should follow a similar procedure on its side). Flow control occurs at the MAC level. It looks like the MAC is not configured to=20 support flow control as negotiated by the PHY during auto-neg, resulting in flow control frames being ignored. The driver will set this in the MAC based on PHY results: http://fxr.watson.org/fxr/source/dev/bce/if_bce.c#L2046 Either the PHY results are coming back incorrectly or it may be firmware on bce(4) is disabling the behavior even though bce(4) correctly enables it. Dave
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5D267A3F22FD854F8F48B3D2B523819385F12FEBE6>