To the good folks at Intel:
Do you need more info on how to reproduce the issue below? Note, there are 2 issues - one being a larger ethtool semantic issue and the other being what i perceive to be a bug in the e1000. cheers, jamal On Thu, 2006-20-07 at 16:15 -0400, jamal wrote: > I went back to this today. I am typing this from a scribbled sticky > note in a big hurry - but i still believe I took the correct notes. > > It does seem there is no distinction between what ethernet advertises > for flow control capability vs what it ends up negotiating with its > partner i.e there is some ambiguity. I havent checked tg3, this on e1000 > only. > > On Fri, 2006-07-07 at 08:28 -0400, jamal wrote: > > On Thu, 2006-06-07 at 23:59 -0700, David Miller wrote: > > > > > > > > It's autonegotiated, check you kernel message logs when the link > > > came up, you'll see this: > > > > > > tg3: eth0: Flow control is on for TX and on for RX. > > > > > > > yikes - yes, this would be it. > > > > I could be wrong and i will double check: > > I think when the e1000 says via ethtool "rx is on" - it means that it > > is _advertising_ flow control as opposed to detecting partner has flow > > control capability. > > Auke, can you also check this as well? > > Semantic #1 > > For example, configure: > ethtool -A eth0 rx off > ethtool -A eth0 tx on > > debopolis:~# ethtool -a eth0 > Pause parameters for eth0: > Autonegotiate: on > RX: off > TX: on > > The other side was set to do symmetric TX flow control only. > > Now enforce autonegotiation: > ethtool -r eth0 > > ethtool -a eth0 > Pause parameters for eth0: > Autonegotiate: on > RX: off > TX: off > > Ok, this is what i expected if this thing (output of ethtool) was > supposed to store state as opposed to configuration. > But if it is state that is stored, then what about that the values > before autonegotian - surely that state is invalid, no? > > It would be nice (for debug/usability reasons) to be able to see what i > configured vs what i end up negotiating with the link partner. I think > this may be an ethtool issue, but it could also be a driver issue. > > I send 1 Mpps to eth0 and see no flow control packets back. good. So it > does store state > > #2: The other semantic > > debopolis:~# ethtool -A eth0 rx on > debopolis:~# ethtool -A eth0 tx on > > debopolis:~# ethtool -a eth0 > Pause parameters for eth0: > Autonegotiate: on > RX: on > TX: on > > Other side was set to do symmetric TX flow control only. > > Now enforce autonegotiation: > debopolis:~# ethtool -r eth0 > > lets see what we came up with: > debopolis:~# ethtool -a eth0 > Pause parameters for eth0: > Autonegotiate: on > RX: on > TX: on > > Now that is contradictory to #1 semantic - I would have expected this TX > flow control on the e1000 to be off. > Unless it is meant to store configuration info and not what you have > negotiated. > > Trying sending traffic to the e1000 at about 1Mpps. > I observe that the e1000 is sending out about 800Kpps of flow control > packets back ;-> > > So which semantics are correct? I would claim #2 flow control behavior > to be a bug. I just dont have time to chase a fix - hopefully whoever > reads this from the e1000 crowd can fix it. > > More importantly can we have two variables storing the two pieces on > information separately instead of the ambiguity of just one? > > > cheers, > jamal - 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
