netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: Auke Kok <auke-jan.h.kok@intel.com>
Cc: 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 10:57:07 -0700	[thread overview]
Message-ID: <451ABB73.1050606@hp.com> (raw)
In-Reply-To: <451AB9CB.6010906@intel.com>

Auke Kok wrote:
> Rick Jones wrote:
> 
>>> With mii-tool we can do the command below and work with a half duplex 
>>> hub and a full duplex switch.
>>> mii-tool -A 10baseT-FD,10baseT-HD eth0
>>
>>
>> Why, and how often, is that really necessary?
> 
> 
> This is a bit of a hypothetical discussion of course, but I can imagine 
> a lot of users with 100mbit switches in their homes (imagine all the 
> DSL/cable routers out there...) that want to stop their nic from 
> attempting to negotiate 1000mbit.

That would be covered by autosense right?  IIRC there haven't been issues with 
speed sensing, just duplex negotiation right?

> Another scenario: forcing the NIC to negotiate only full-duplex speeds. 
> Not only fun if you try it against a hub, but possibly useful.
> 
> For us it's much more interesting because we try every damn impossible 
> configuration anyway and see what gives (or breaks).
> 
> Anyway, a patch to make ethtool do this was merged as Jeff Kirsher 
> pointed out, so you can do this now with ethool too.

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.

rick

> 
> Cheers,
> 
> Auke


  reply	other threads:[~2006-09-27 17:57 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 [this message]
2006-09-27 18:05             ` Maciej W. Rozycki
2006-09-27 18:42               ` Auke Kok
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=451ABB73.1050606@hp.com \
    --to=rick.jones2@hp.com \
    --cc=auke-jan.h.kok@intel.com \
    --cc=dacker@roinet.com \
    --cc=dhinds@pcmcia.sourceforge.org \
    --cc=jgarzik@pobox.com \
    --cc=netdev@vger.kernel.org \
    --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).