On 11/21/05, Martin Josefsson <[EMAIL PROTECTED]> wrote: <snip> > > Why do you need this? Basically this was a design decision in our > > driver to not report link when we haven't had a chance to initialize > > it (when the interface is brought up) > > If I configure an interface to disable autonegotiation I'd like to be > able to tell how the interface is configured, iow what will happen when > I connect it to a switch that is set to 100-full? Will I get a duplex > mismatch or not? Sometimes you don't connect a device just after you've
if you force one end it is impossible to tell from the other end what the remote config is, or whether you have a duplex mismatch. The only option is to review settings, as you're suggesting, and I believe you can get the info you need from ethtool -d. > configured it, sometimes you get interrupted by other things, and then > when you are about to connect the interface to the switch it's really > nice to be able to visually confirm (by visually confirm I mean read-out > the actual settings of the interface and see if that matches the other > end of the link) that the settings of both the interface and the switch > are really as they are supposed to be. ethtool -d eth0 will give you this information in the CTRL register, for an IFF_UP or IFF_DOWN interface. This is a semantic question really. Do we really need to report *configuration* or *status* when being asked for our link speed. ethtool eth0, shows what we're advertising, and when you force using ethtool -s autoneg off speed 100 duplex full, the command shows autoneg disabled. > The visual confirmation part is almost neccessary when you are under > time pressure to get things working and you are about to replace parts > of a production network. This is something you can do with almost all > network equipment out there. > > By bringing up an interface, do you mean setting IFF_UP or detecting a > link-beat? > if you mean the former your explanation and the current behaviour > doesn't match, simply setting IFF_UP doesn't make the driver report the > current settings when autoneg is turned off. > It only reports the current speed/duplex when a link-beat is detected, > doesn't matter if autoneg is turned on or off, the behaviour is the > same. Right, I mean the former. ethtool -d will give you information right now about current config. > > Unless you can give me a really good reason or precendent in the > > kernel to change our design decision, I don't think this change is > > worth it. > > Reading the source for drivers using mii_ethtool_gset() in order to get > the settings it doesn't seem like any of them behave diffrently if the > interface is up or down. This includes drivers like e100, 3c59x, > eepro100, 8139too, 8139cp. But, mii_ethtool_gset() doesn't set speed or > duplex to 0xffff (unknown) like e1000/ixgb does when autoneg is turned > on which I think is more correct. But they do appear to report the > speed/duplex even if the interface doesn't detect a link-beat, > e1000/ixgb doesn't do this (should only be done when autoneg is turned > off) mii-tool doesn't work at all for gigabit links, AFAIK. mii-tool directly reads phy registers to get its information for e100, this is not the case for e1000. > I use e1000 everywhere I use Linux and gigE, this has been an itch that > I now wanted to scratch. Thats cool, we're glad to hear you like e1000. I hope someone on netdev will weigh in on this? - 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
