http://bugzilla.novell.com/show_bug.cgi?id=462816 User jeffm@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=462816#c20 Jeff Mahoney changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO CC| |jeffm@novell.com Info Provider| |hvogel@novell.com --- Comment #20 from Jeff Mahoney 2009-05-14 12:23:38 MDT --- No, it's not at that at all. "autoneg off" by itself doesn't make any sense. You need to tell it what it should use instead of autonegotiation, which means speed and duplex. The kernel expects all three values to be available, but each driver implements ethtool_ops->set_settings independently. In my network, I have access to tg3 and e1000e devices. The e1000e responds the same way as sky2 unless all three parameters are supplied. The tg3 doesn't respond -EINVAL but, looking at the code, it silently ignores it if the speed passed is invalid. When going from autoneg to non-autoneg, it considers the speed invalid unless it is passed on the same command line. I'm not certain if the device will be operable before it's passed all three values. In general, the caller should always pass all three values. It _may_ work with less than three, but it's not guaranteed to. Does ethtool silently pass the other fields to the kernel? For example, if autonegotiation has already set up the speed and duplex fields, does it use the ones advertised when passing autoneg off? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.