From: Auke Kok <auke-jan.h.kok@intel.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Rick Jones <rick.jones2@hp.com>, David Acker <dacker@roinet.com>,
Stephen Hemminger <shemminger@osdl.org>,
Jeff Garzik <jgarzik@pobox.com>,
dhinds@pcmcia.sourceforge.org, netdev@vger.kernel.org
Subject: Re: mii-tool gigabit support.
Date: Wed, 27 Sep 2006 11:42:56 -0700 [thread overview]
Message-ID: <451AC630.2030509@intel.com> (raw)
In-Reply-To: <Pine.LNX.4.64N.0609271858440.7657@blysk.ds.pg.gda.pl>
Maciej W. Rozycki wrote:
> On Wed, 27 Sep 2006, Rick Jones wrote:
>
>>> Another scenario: forcing the NIC to negotiate only full-duplex speeds. Not
>>> only fun if you try it against a hub, but possibly useful.
> [...]
>> I'm just worried (as in Fear Uncertainty and Doubt) that having people set the
>> allowed things to negotiate isn't really any more robust than stright-up
>> hardcodes and perpetuates the (IMO) myth that one shouldn't autoneg on general
>> principle.
>
> Older equipment, which may still be in use here and there, allowed
> full-duplex operation, but no auto-negotiation. The duplex setting was
> either fixed or selectable in a system-specific manner. In such a case
> you certainly want your modern other end to be forced to full-duplex, but
> still let it detect the link speed, so that you do not have to do
> reconfiguration whenever you move a link between a 10base-T and a
> 100base-Tx port.
in this case the new addition to ethtool will not help as it only changes the
modes that the NIC will advertise. In this specific case you will need to turn
of advertising/autonegotiation and force a speed/duplex pair anyway.
Advertising all half-duplex modes to a partner that does not do autonegotiation
is (by spec I think) an unsupported configuration (i.e. undetermined behaviour).
That's nothing new.
Auke
next prev parent reply other threads:[~2006-09-27 18:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-26 21:51 mii-tool gigabit support Stephen Hemminger
2006-09-26 21:55 ` Jeff Garzik
2006-09-26 22:09 ` Stephen Hemminger
2006-09-27 13:00 ` David Acker
2006-09-27 15:00 ` Auke Kok
2006-09-27 16:20 ` Jeff Kirsher
2006-09-27 17:08 ` Rick Jones
2006-09-27 17:50 ` Auke Kok
2006-09-27 17:57 ` Rick Jones
2006-09-27 18:05 ` Maciej W. Rozycki
2006-09-27 18:42 ` Auke Kok [this message]
2006-09-28 12:10 ` Maciej W. Rozycki
2006-09-27 20:26 ` David Acker
2006-09-27 19:24 ` dean gaudet
2006-09-27 19:31 ` Stephen Hemminger
2006-09-27 19:32 ` Auke Kok
2006-09-27 19:37 ` dean gaudet
2006-09-29 16:12 ` David Hollis
2006-09-29 17:12 ` Stephen Hemminger
2006-09-29 17:54 ` Rick Jones
2006-10-01 14:31 ` Michael Tokarev
2006-09-27 19:15 ` dean gaudet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=451AC630.2030509@intel.com \
--to=auke-jan.h.kok@intel.com \
--cc=dacker@roinet.com \
--cc=dhinds@pcmcia.sourceforge.org \
--cc=jgarzik@pobox.com \
--cc=macro@linux-mips.org \
--cc=netdev@vger.kernel.org \
--cc=rick.jones2@hp.com \
--cc=shemminger@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).