mii-tool gigabit support.

mii-tool gigabit support.

[Stephen Hemminger]

The mii-tool utility seems to be abandoned and unmaintained?

Here is a version that does standard 1000baseT support.
	http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2


-- 
Stephen Hemminger <shemminger@osdl.org>

Re: mii-tool gigabit support.

[Jeff Garzik]

Stephen Hemminger wrote:
> The mii-tool utility seems to be abandoned and unmaintained?
> 
> Here is a version that does standard 1000baseT support.
> 	http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2

Not really.  I would rather leave it as-is, and deprecate it in favor of 
ethtool.

I want to keep binary ABI compat, but long term, move away from having 
userspace directly bitbang hardware registers.

	Jeff

Re: mii-tool gigabit support.

[Stephen Hemminger]

On Tue, 26 Sep 2006 17:55:34 -0400
Jeff Garzik <jgarzik@pobox.com> wrote:

> Stephen Hemminger wrote:
> > The mii-tool utility seems to be abandoned and unmaintained?
> > 
> > Here is a version that does standard 1000baseT support.
> > 	http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2
> 
> Not really.  I would rather leave it as-is, and deprecate it in favor of 
> ethtool.
>

It does make a handy debug tool when driver isn't doing MII correctly.

-- 
Stephen Hemminger <shemminger@osdl.org>

Re: mii-tool gigabit support.

[David Acker]

Stephen Hemminger wrote:
> On Tue, 26 Sep 2006 17:55:34 -0400
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>> Stephen Hemminger wrote:
>>> The mii-tool utility seems to be abandoned and unmaintained?
>>>
>>> Here is a version that does standard 1000baseT support.
>>> 	http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2
>> Not really.  I would rather leave it as-is, and deprecate it in favor of 
>> ethtool.
>>
> 
> It does make a handy debug tool when driver isn't doing MII correctly.
> 

mii-tool supports some things that ethtool does not.  mii-tool -A lets 
you set the advertised speeds and can include a list of speeds.  The 
closest ethtool seems to have is ethtool -s but that seems to just set 
the advertised speed to a single value only.

We have instances where we want to limit the link of the ethernet port 
to no higher then 10 Mbps full duplex but also advertise support for 
half duplex.

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

Meanwhile if I use ethtool like the command below I will not work with a 
half duplex only hub.
ethtool -s eth0 speed 10 duplex full autoneg on

Perhaps the "speed" part of ethtool -s should take a list of speeds like 
mii-tool does.

-Ack

Re: mii-tool gigabit support.

[Auke Kok]

David Acker wrote:
> Stephen Hemminger wrote:
>> On Tue, 26 Sep 2006 17:55:34 -0400
>> Jeff Garzik <jgarzik@pobox.com> wrote:
>>
>>> Stephen Hemminger wrote:
>>>> The mii-tool utility seems to be abandoned and unmaintained?
>>>>
>>>> Here is a version that does standard 1000baseT support.
>>>>     http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2
>>> Not really.  I would rather leave it as-is, and deprecate it in favor 
>>> of ethtool.
>>>
>>
>> It does make a handy debug tool when driver isn't doing MII correctly.
>>
> 
> mii-tool supports some things that ethtool does not.  mii-tool -A lets 
> you set the advertised speeds and can include a list of speeds.  The 
> closest ethtool seems to have is ethtool -s but that seems to just set 
> the advertised speed to a single value only.

We sent a patch for this to Jeff recently that allows setting of 'arbitrary' 
speeds. Unfortunately the interface is rather crude but it works (for e1000, 
and possibly all other nics) to set any combination of advertised speeds.

e.g. `ethtool -s eth0 advertise 0x0f` advertises all non-gigabit speeds

I haven't seen the patch merged yet upstream though.

Cheers,

Auke

> 
> We have instances where we want to limit the link of the ethernet port 
> to no higher then 10 Mbps full duplex but also advertise support for 
> half duplex.
> 
> 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
> 
> Meanwhile if I use ethtool like the command below I will not work with a 
> half duplex only hub.
> ethtool -s eth0 speed 10 duplex full autoneg on
> 
> Perhaps the "speed" part of ethtool -s should take a list of speeds like 
> mii-tool does.
> 
> -Ack

Re: mii-tool gigabit support.

[Jeff Kirsher]

On 9/27/06, Auke Kok <auke-jan.h.kok@intel.com> wrote:
> David Acker wrote:
> >
> > mii-tool supports some things that ethtool does not.  mii-tool -A lets
> > you set the advertised speeds and can include a list of speeds.  The
> > closest ethtool seems to have is ethtool -s but that seems to just set
> > the advertised speed to a single value only.
>
> We sent a patch for this to Jeff recently that allows setting of 'arbitrary'
> speeds. Unfortunately the interface is rather crude but it works (for e1000,
> and possibly all other nics) to set any combination of advertised speeds.
>
> e.g. `ethtool -s eth0 advertise 0x0f` advertises all non-gigabit speeds
>
> I haven't seen the patch merged yet upstream though.
>
> Cheers,
>
> Auke
>
> >
> > We have instances where we want to limit the link of the ethernet port
> > to no higher then 10 Mbps full duplex but also advertise support for
> > half duplex.
> >
> > 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
> >
> > Meanwhile if I use ethtool like the command below I will not work with a
> > half duplex only hub.
> > ethtool -s eth0 speed 10 duplex full autoneg on
> >
> > Perhaps the "speed" part of ethtool -s should take a list of speeds like
> > mii-tool does.
> >
> > -Ack

Garzik has ACK and pulled in the ethtool patch which allows you to set
multiple auto-negotiation advertised speeds.

-- 
Cheers,
Jeff

Re: mii-tool gigabit support.

[Rick Jones]

> 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?

rick jones

Re: mii-tool gigabit support.

[Auke Kok]

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.

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.

Cheers,

Auke

Re: mii-tool gigabit support.

[Rick Jones]

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

Re: mii-tool gigabit support.

[Maciej W. Rozycki]

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.

  Maciej

Re: mii-tool gigabit support.

[Auke Kok]

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

Re: mii-tool gigabit support.

[dean gaudet]

On Tue, 26 Sep 2006, Stephen Hemminger wrote:

> The mii-tool utility seems to be abandoned and unmaintained?
> 
> Here is a version that does standard 1000baseT support.
> 	http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2

cool that's bugged me for a while...

there's an off-by-1 for the non-verbose basic output -- you need register 
10 but only read up to register 9.  patch below.

tested on various mobos with e1000, tg3, skge.

oh, two of my tyans show this (one e1000 one tg3):

  product info: vendor 00:08:18, model 25 rev 0

but i'm not physically at the boards so i can't find the PHY to see what 
model it is.

-dean


Index: mii-tool/mii-tool.c
===================================================================
--- mii-tool.orig/mii-tool.c	2006-09-26 14:44:56.000000000 -0700
+++ mii-tool/mii-tool.c	2006-09-27 12:05:03.000000000 -0700
@@ -233,7 +233,7 @@
     /* Some bits in the BMSR are latched, but we can't rely on being
        the only reader, so only the current values are meaningful */
     mdio_read(sock, MII_BMSR);
-    for (i = 0; i < ((verbose > 1) ? 32 : 10); i++)
+    for (i = 0; i < ((verbose > 1) ? 32 : MII_BASIC_MAX); i++)
 	mii_val[i] = mdio_read(sock, i);
 
     if (mii_val[MII_BMCR] == 0xffff) {
Index: mii-tool/mii.h
===================================================================
--- mii-tool.orig/mii.h	2006-09-26 14:44:59.000000000 -0700
+++ mii-tool/mii.h	2006-09-27 12:05:56.000000000 -0700
@@ -94,4 +94,7 @@
 #define   MII_LPA2_1000FULL	0x0800
 #define   MII_LPA2_1000HALF	0x0400
 
+/* Last register we need for show_basic_mii() */
+#define MII_BASIC_MAX		(MII_STAT1000+1)
+
 #endif /* _LINUX_MII_H */

Re: mii-tool gigabit support.

[dean gaudet]

On Tue, 26 Sep 2006, Jeff Garzik wrote:

> Stephen Hemminger wrote:
> > The mii-tool utility seems to be abandoned and unmaintained?
> > 
> > Here is a version that does standard 1000baseT support.
> > 	http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2
> 
> Not really.  I would rather leave it as-is, and deprecate it in favor of
> ethtool.

is there some ethtool (version 5) option i'm missing that will give a nice 
concise link negotation state report like mii-tool does?

on e1000 it seems i can find this info only via the -d option, which dumps 
a lot of other info.

on skge -d doesn't seem to dump the negotiation state.

on tg3 -d doesn't even interpret the registers...

maybe it's just that i haven't had caffeine but i think i've tried every 
reporting option i can find on the man page and can't find link 
negotiation state.

-dean

Re: mii-tool gigabit support.

[Stephen Hemminger]

On Wed, 27 Sep 2006 12:24:59 -0700 (PDT)
dean gaudet <dean@arctic.org> wrote:

> On Tue, 26 Sep 2006, Jeff Garzik wrote:
> 
> > Stephen Hemminger wrote:
> > > The mii-tool utility seems to be abandoned and unmaintained?
> > > 
> > > Here is a version that does standard 1000baseT support.
> > > 	http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2
> > 
> > Not really.  I would rather leave it as-is, and deprecate it in favor of
> > ethtool.
> 
> is there some ethtool (version 5) option i'm missing that will give a nice 
> concise link negotation state report like mii-tool does?
> 
> on e1000 it seems i can find this info only via the -d option, which dumps 
> a lot of other info.
> 
> on skge -d doesn't seem to dump the negotiation state.
>

Not possible because the PHY registers are accessed indirectly.

> on tg3 -d doesn't even interpret the registers...
> 
> maybe it's just that i haven't had caffeine but i think i've tried every 
> reporting option i can find on the man page and can't find link 
> negotiation state.
> 
> -dean


-- 
Stephen Hemminger <shemminger@osdl.org>

Re: mii-tool gigabit support.

[Auke Kok]

dean gaudet wrote:
> On Tue, 26 Sep 2006, Jeff Garzik wrote:
> 
>> Stephen Hemminger wrote:
>>> The mii-tool utility seems to be abandoned and unmaintained?
>>>
>>> Here is a version that does standard 1000baseT support.
>>> 	http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2
>> Not really.  I would rather leave it as-is, and deprecate it in favor of
>> ethtool.
> 
> is there some ethtool (version 5) option i'm missing that will give a nice 
> concise link negotation state report like mii-tool does?

how about `ethtool ethX` ? It doesn't report what happened during negotiotion 
but it shows status and advertised/autonegotiated/supported modes

> on e1000 it seems i can find this info only via the -d option, which dumps 
> a lot of other info.
> 
> on skge -d doesn't seem to dump the negotiation state.
> 
> on tg3 -d doesn't even interpret the registers...
> 
> maybe it's just that i haven't had caffeine but i think i've tried every 
> reporting option i can find on the man page and can't find link 
> negotiation state.

dumping registers in readable format is an extension that needs to be 
implemented per driver. Not all nics have done this - we just did it ourselves 
for ixgb, and I saw skge/sky2 just fly by this week.

Cheers,

Auke

> 
> -dean
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mii-tool gigabit support.

[dean gaudet]

On Wed, 27 Sep 2006, Auke Kok wrote:

> dean gaudet wrote:
> > On Tue, 26 Sep 2006, Jeff Garzik wrote:
> > 
> > > Stephen Hemminger wrote:
> > > > The mii-tool utility seems to be abandoned and unmaintained?
> > > > 
> > > > Here is a version that does standard 1000baseT support.
> > > > 	http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2
> > > Not really.  I would rather leave it as-is, and deprecate it in favor of
> > > ethtool.
> > 
> > is there some ethtool (version 5) option i'm missing that will give a nice
> > concise link negotation state report like mii-tool does?
> 
> how about `ethtool ethX` ? It doesn't report what happened during negotiotion
> but it shows status and advertised/autonegotiated/supported modes

well now don't i feel dumb, i didn't even try running it without an 
option.  yes must be the lack of caffeine.  thanks.

-dean

Re: mii-tool gigabit support.

[David Acker]

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?
> 
> rick jones
> 

Take a wifi router with only 802.11b radios and ethernet chips that do 
not support handling DMA to host memory.  In this case receives from 
ethernet cost a lot since the packets must be read into host memory by 
the CPU (instead of written there by the adapter).  Also, receiving 100 
Mbit in when you only have 802.11b pipes out isn't terrible useful.  UDP 
blasts from ethernet can hog the CPU and with some NICs cause soft lockups.

We could just set it to 10Mbit half duplex always but two 802.11b radios 
can saturate that with bidirectional traffic.  We have seen failures to 
send due to collisions.  Thus, we would like to be able advertise 10Mb 
full and half duplex so that we can get the appropriate speed when that 
the neighbor device supports.  We have seen various ethernet switches or 
NICs (like IP video cameras with ethernet) that will not run 10Mb full 
duplex but will do 100Mb full or 10Mb half.

We want it to be configurable at run time since sometimes the same 
software may run on a system that has 802.11G radios and and perhaps 
more capable ethernet devices.  We can detect our situation in our 
startup script and adjust the advertised speeds down only when needed.

-Ack

Re: mii-tool gigabit support.

[Maciej W. Rozycki]

On Wed, 27 Sep 2006, Auke Kok wrote:

> > 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.

 My whole point is to keep the speed negotiation enabled.  If you force a 
given speed and the partner only supports a different one, you will get no 
link.

> 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).

 Yes, but more reasonable PHYs will autosense the link speed if allowed 
to, even if the partner is not capable of negotiating.  It is useful, so 
why should we limit people so that they cannot do it?

 And as I wrote, it is not half-duplex operation that is problematic as it 
is the default if the partner does not negotiate anyway.

  Maciej

Re: mii-tool gigabit support.

[David Hollis]

On Wed, 2006-09-27 at 12:32 -0700, Auke Kok wrote:
> dumping registers in readable format is an extension that needs to be 
> implemented per driver. Not all nics have done this - we just did it
> ourselves 
> for ixgb, and I saw skge/sky2 just fly by this week. 

This has always bothered me a bit with ethtool.  It really stinks that
we have to actually write code and generate patches and get everyone to
update a utility just to be able to get this type of access.  I see two
ways to make the situation better:  1) add extensions to the drivers
themselves to be able to report this which would likely lead to a lot of
driver bloat and too much user-space style info (like verbose
descriptions of the register and it's purpose) or 2) develop some style
of register description definition type of text file, maybe XML, maybe
INI style or something stored in /etc/ethtool as <drivername>.conf or
something like that.  This way, ethtool doesn't have to be
changed/updated/patched/likely-bug-added for every single device known
to man.  

Just a thought.

-- 
David Hollis <dhollis@davehollis.com>

Re: mii-tool gigabit support.

[Stephen Hemminger]

On Fri, 29 Sep 2006 12:12:58 -0400
David Hollis <dhollis@davehollis.com> wrote:

> On Wed, 2006-09-27 at 12:32 -0700, Auke Kok wrote:
> > dumping registers in readable format is an extension that needs to be 
> > implemented per driver. Not all nics have done this - we just did it
> > ourselves 
> > for ixgb, and I saw skge/sky2 just fly by this week. 
> 
> This has always bothered me a bit with ethtool.  It really stinks that
> we have to actually write code and generate patches and get everyone to
> update a utility just to be able to get this type of access.  I see two
> ways to make the situation better:  1) add extensions to the drivers
> themselves to be able to report this which would likely lead to a lot of
> driver bloat and too much user-space style info (like verbose
> descriptions of the register and it's purpose) or 2) develop some style
> of register description definition type of text file, maybe XML, maybe
> INI style or something stored in /etc/ethtool as <drivername>.conf or
> something like that.  This way, ethtool doesn't have to be
> changed/updated/patched/likely-bug-added for every single device known
> to man.  
> 
> Just a thought.
 
We could switch to shared libraries like 'tc' uses.


-- 
Stephen Hemminger <shemminger@osdl.org>

Re: mii-tool gigabit support.

[Rick Jones]

2) develop some style
>>of register description definition type of text file, maybe XML, maybe
>>INI style or something stored in /etc/ethtool as <drivername>.conf or
>>something like that.  This way, ethtool doesn't have to be
>>changed/updated/patched/likely-bug-added for every single device known
>>to man.  
>>
>>Just a thought.
> 
>  
> We could switch to shared libraries like 'tc' uses.

 From a practical standpoint is shipping a new config file or a new shared 
library all that much different from a new ethtool binary?

rick

Re: mii-tool gigabit support.

[Michael Tokarev]

Rick Jones wrote:
> 2) develop some style
>>> of register description definition type of text file, maybe XML, maybe
>>> INI style or something stored in /etc/ethtool as <drivername>.conf or
>>> something like that.  This way, ethtool doesn't have to be
>>> changed/updated/patched/likely-bug-added for every single device known
>>> to man. 
>>> Just a thought.
>>  
>> We could switch to shared libraries like 'tc' uses.
> 
> From a practical standpoint is shipping a new config file or a new
> shared library all that much different from a new ethtool binary?

New config - certainly yes.  After all, it's trivial to change a line
in a config file locally.  But yes, new shared lib is the same as a
new binary.

. o O { /sys/class/net/$iface/config.xml }    ;)

But seriously, I don't think it's that a bad idea.  Maybe not xml,
but a plain list of registers with their names - a static string
known to each driver isn't much a bloat really.  I think anyway.

/mjt