[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: half-/full-duplex ethernet and ifconfig
On Wed, Nov 14, 2012 at 11:17:59AM -0500, Mouse wrote:
> > Yes. I firmly believe that allowing "hardwired" setting of duplex
> > and speed is insane. If it ever solves a problem, the problem should
> > be solved at the other end of the link, instead.
> I have seen cases where NetBSD's taking this stance would simply render
> it useless, even if it is abstractly correct. There are cases where it
> is important to interoperate with a particular device, even if it is
> broken, and broken autoneg, while less common than it once was, is
> hardly unheard of.
I've heard this argument before. I don't agree. Here is why.
You're positing a device at the other end which has broken autonegotiation
*that cannot be turned off*. I haven't actually seen a device like that.
And I've seen a lot of network devices.
Remember, if you restrict the set of modes on the PHY at the NetBSD end,
if properly implemented drivers will not use any other mode *whether they
manage to autonegotiate or not*.
So, if you have a device with broken autonegotiation, you do not need to
turn off autonegotiation on the NetBSD end; you can turn it off on that
device's end instead. If NetBSD is made to behave like OS X and Windows
in this regard, then even if configured to always try to autonegotiate,
will not somehow agree to a mode other than the one you told it to try to
negotiate for, even if autonegotiation fails.
Now, I didn't win this argument at Coyote Point and I don't expect to
necessarily win it here. What we did there was to implement a "force"
bit that reverted to the current behavior. So if you select
media 100baseTX -- only -- and don't specify "force" it does what everyone
else sane does, and restricts autonegotiation to 100baseTX only; if you do
say "force", it forces the PHY to 100baseTX and refuses to negotiate about
I think that is a nasty hack that is not actually justified by real world
behavior of link partners but it's one I would not oppose for inclusion
in NetBSD if others think it is needed.
Main Index |
Thread Index |