Re: mii-tool gigabit support.
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
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
On Fri, 29 Sep 2006 12:12:58 -0400 David Hollis [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
Stephen Hemminger wrote: On Tue, 26 Sep 2006 17:55:34 -0400 Jeff Garzik [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
David Acker wrote: Stephen Hemminger wrote: On Tue, 26 Sep 2006 17:55:34 -0400 Jeff Garzik [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
On 9/27/06, Auke Kok [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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.c2006-09-26 14:44:56.0 -0700
+++ mii-tool/mii-tool.c 2006-09-27 12:05:03.0 -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] == 0x) {
Index: mii-tool/mii.h
===
--- mii-tool.orig/mii.h 2006-09-26 14:44:59.0 -0700
+++ mii-tool/mii.h 2006-09-27 12:05:56.0 -0700
@@ -94,4 +94,7 @@
#define MII_LPA2_1000FULL0x0800
#define MII_LPA2_1000HALF0x0400
+/* Last register we need for show_basic_mii() */
+#define MII_BASIC_MAX (MII_STAT1000+1)
+
#endif /* _LINUX_MII_H */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
On Wed, 27 Sep 2006 12:24:59 -0700 (PDT) dean gaudet [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mii-tool gigabit support.
On Tue, 26 Sep 2006 17:55:34 -0400 Jeff Garzik [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
