On 28 March 2016 at 03:54, Lu, Wenzhuo <wenzhuo.lu at intel.com> wrote:
> Hi Marc > > > > *From:* Marc Sune [mailto:marcdevel at gmail.com] > *Sent:* Saturday, March 26, 2016 9:43 AM > *To:* dev at dpdk.org; Lu, Wenzhuo > *Subject:* e1000: randomly loosing link change events triggered by the > peer > > > > I found that in the current HEAD in master testing it with an I218-LM in > autoneg mode, when link is forced to be renegociated by the peer (e.g. via > ethtool on a peer Linux box) _some_ change events are lost. > > > > It is quite random, but it seems to happen more while changing the speed > than when changing the duplex mode. > > > > However, when one or more link change events have been lost and the phy > medium is disconnected and reconnected, the link speed and duplex mode are > then correctly updated. > > > > Marc > > > > [Wenzhuo] Thanks for let us know this issue. May I ask some questions? Do > you mean this NIC 0x155A? > 0x15A2, I218-LM (rev 03) EAL: PCI device 0000:00:19.0 on NUMA socket -1 EAL: probe driver: 8086:15a2 rte_em_pmd EAL: PCI memory mapped at 0x7f85cf400000 EAL: PCI memory mapped at 0x7f85cf420000 PMD: eth_em_dev_init(): port_id 0 vendorID=0x8086 deviceID=0x15a2 I think this is not a NIC issue, but a general problem of the driver (or em code). > About how to reproduce this problem, you mean use these CLIs, ethtool ?s > xxx advertise xxx, ethtool ?s xxx duplex half/full, to change the peer > port?s configuration? > Correct. I modified l2fwd to check link status and print it on each port stats print iteration. Then from the peer I modified the link properties via ethtool. The result is that transitions from autoneg speeds and/or duplex mode settings are randomly not detected (rte_eth_link in rte_eth_dev_data is not updated), and it prints not-up-to-date state. Marc
