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.