At Tue, 6 Dec 2011 09:12:47 -0500, Thor Lancelot Simon
<tls%panix.com@localhost> wrote:
Subject: Re: Fix for kern/20700
>
> On Tue, Dec 06, 2011 at 10:41:01AM +0100, Manuel Bouyer wrote:
> >
> > But with old devices, hard setting both ends is often the only
> > way to get the desired media.
>
> I think this is largely a myth. I believe it is caused by the unpleasant
> fact that there's a race condition in the interaction between Nway and
> parallel autodetection, such that when one side is set to Nway and
> the other's set to no autonegotiation, the Nway side can fall back to
> parallel autodetection and end up with the wrong duplex setting.
Yup, that's the worst case in my experience. The connection simply
cannot work properly if one side tries to use auto-negotiation and the
other side has set full-duplex mode (and presumably a fixed speed as
well) and at the same time has disabled auto-negotiation.
> The result is that people will set one side to hardwired speed and
> duplex (no autonegotiation) and *that* will then cause the link partner
> to "autonegotiate" the wrong duplex setting as it fails at Nway and tries
> to do parallel detection.
Apparently (one text on Ethernet I have) 802.3u is quite clear that if
auto-negotiation is turned off then half-duplex "MUST" be used (on
twisted pair connections, at least). In theory I think this means that
auto-negotiation should never fall back on parallel detection unless
half-duplex is also forced. I think this also means that if auto-
negotiation is disabled on a NetBSD interface (i.e. one where "we"
control the code) and full-duplex mode is also selected then a warning
should be displayed by ifconfig(1) (both on the command and in the
status display, and perhaps also logged by the driver) to warn the
operator that unless the remote end also disables auto-negotiation and
enables full-duplex (and keeps a matching speed and technology type)
then the link will not work properly.
Part of the problem might also be with the vauge description, and
perhaps implementation, in ifmedia(4) and ifconfig(1).
IFM_AUTO is described as "autoselect the best media" and it is also said
that it is a media type shared by all link types, but of course "media
type" is a poor way of saying "media speed" for the most part since the
technology type is not really negotiable unless it's twisted pair and it
is only the difference between -T, -TX and -T4 that's being negotiated.
Also note that "ifconfig -m" shows that on the command-line interface
"autoselect" isn't an option ("mediaopt"), but rather a pseudo-type of
media.
> Using the user's selections to restrict the set of what modes will be
> offered is a good thing. Turning off Nway entirely just because the
> user has picked a particular mode is a very bad thing.
I haven't read IEEE 802.3u itself but as I understand it from at least
one source which tries to explain the standard, auto-negotiation should
never be turned off unless it is the very rare case where one is trying
to get a device to interoperate which has a broken and unusable auto-
negotation implementation, _and_ when both sides can be manually
configured to exactly match in their speed, type, and options. Indeed
failing to use auto-negotiation in some cases can disrupt an entire
collision domain.
If IFM_AUTO is currently actually meant to refer to whether the port
will attempt auto-negotiation (which to me is somewhat implied in the
discussion in ifmedia(4) of IFM_ETH_MASTER etc.) then it should be a
"mediaopt", not a "media" type, and it should be left on by default even
if a specific media speed (and/or type) is also selected.
However given the history and current state of ifmedia(4) and
ifconfig(1) I think IFM_AUTO should simply mean that the interface
simply follows the standard rules for auto-negotiating speed (and, for
twisted pair, -T, -TX, or -T4), but that IFM_AUTO not have anything to
do whatsoever with 802.3u auto-negotiation, and that the latter always
be enabled (i.e. on every device that supports it, and if a device does
not support it then "autoselect" should not be shown a possible media
option (which I think is how it does now work?)).
> At the very most, it should perhaps be possible to turn off autonegotiation
> by specifying an additional "force" media option but I think even that is
> a bad idea. Apple, for example, doesn't make it possible...
Perhaps if anyone is really worried about also having control over
auto-negotiation then maybe a new ifmedia(4) flag and ifconfig(1)
"mediaopt" could be invented to do that.
In that case maybe the somewhat confusing "autoselect" (and IFM_AUTO)
could be deprecated and eventually wholly converted to something more
meaningful like "autospeed" (and IFM_AUTO_SPEED). Also "ifconfig -m"
could offer "autospeed" with other valid mediaopt settings as well.
However I also note that for 1000base interfaces it seems auto-
negotiation is a mandatory feature, and so full-duplex can always be
negotiated (at 1000base speeds at least), and thus it doesn't have to be
an available option (at the full 1000base speed). I can't see any sense
in ever trying to manually force it to be different than it would be
negotiated to be.
Do any known implementations allow the admin to disable auto-negotiation
while still maintaining a 1000base speed setting?
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpr0j7tG0c4G.pgp
Description: PGP signature