DragonFly users List (threaded) for 2006-10
Re: Network Slowdowns
Paul Allen wrote:
See commit relating to revision 1.258 of if_fxp.c (in FreeBSD)
There is some evidence that this problem is not localized to fxp but common
to many driver implementations.
----- Forwarded message from John-Mark Gurney <gurney_j@xxxxxxxxxxxxxxxxxx> -----
Jeremy Chadwick wrote this message on Thu, Oct 05, 2006 at 09:08 -0700:
The problem in that case turned out to be duplex-related. Both
boxes were auto-negotiating with the Cisco switch correctly, and
indeed the Cisco labelled them as auto-100/full, but as anyone who
is familiar with Ciscos knows, auto-negotiation on Catalysts is
far from reliable. Both boxes reported auto-neg and being at 100/full
as well. I ended up hard-setting the boxes to use 100/full, and
set the switch ports to 100/full, then rebooted both boxes (yes,
this is sometimes required, as driver auto-neg code is a bit tweaky);
voila, problem fixed.
It appears that some ethernet drivers don't reset the phy (bring the
link down) when changing media (duplex setting, etc).. This means that
if you boot w/ autoselect, and the switch autoselects to 100/full, but
then later change it to 100/full (w/ autoselect off) it will work fine..
but then if the cabel is pulled, or the switch resets, it attempts to
reautoselect, but falls back to 100/half while you are still running
As you can imagine, it causes a very hard to track down problem since
the time it breaks is not readily apparent...
First two whole generations of Intel 10/100 did that, *even if* set to fixed
Killer wasn't just cable move - one learned to check on that.
But they went walk-about after a power-outage on the 'SWUB' as well.
First generation just stopped talking altogether.
Switched to DEC until they were bought by Intel, then RealTek, AKA el-cheapo.
Back with Intel and Broadcom Gig-E now, and no longer a hassle.
an ifconfig <iface> down; ifconfig <iface> up may help resolve this
issue if you are not sure...
I have just committed a patch to fxp0 to do this...