https://bugs.dpdk.org/show_bug.cgi?id=69
Bug ID: 69
Summary: Intel x550 SFP+ fails to update link state
Product: DPDK
Version: 18.05
Hardware: x86
OS: Linux
Status: CONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: mgsm...@netgate.com
Target Milestone: ---
Overview:
On a system with 2 x550 SFP+ ports (vendor 0x8086, device 0x15ac), when an
application calls rte_eth_dev_start() followed by rte_eth_link_get_nowait() the
call to rte_eth_link_get_nowait() fails and all subsequent calls to
rte_eth_link_get_nowait() also fail.
Steps to reproduce:
- Install CentOS 7.5 on a system with x550 SFP+ ports
- Install or build FD.io VPP on the system
- Make sure the link is down on the x550 devices (ip link set dev enoX down)
- Start vpp (systemctl start vpp)
- Bring one of the ports up in vpp (vppctl set interface state
TenGigabitEthernet3/0/0 up)
Actual results:
Link state information is never retrieved. When looking in gdb at the
rte_eth_link struct containing the results of rte_eth_link_get_nowait(), the
contents look like:
$1 = {link_speed = 0, link_duplex = 0, link_autoneg = 1, link_status = 0}
To VPP it looks like the interface is down. Running 'vppctl show
hardware-interface' always shows "carrier down" for that port.
Expected results:
Link state should be retrieved successfully and the link should show up. The
rte_eth_link struct containing the results of rte_eth_link_get_nowait() should
look like:
$1 = {link_speed = 10000, link_duplex = 1, link_autoneg = 1, link_status = 1}
The port should show "carrier up" when running 'vppctl show
hardware-interface'.
Build date and hardware:
DPDK - Issue observed with both 18.05 and 18.02
VPP - Issue observed with v18.04 and newer (up to current tip of master branch)
Xeon D-1537 SoC with 2 x550 SFP+ ports
CentOS 7.5
Additional information:
If the ports are detached from the uio driver and attached to the Linux kernel
ixgbe driver, they work without issue. Multiple cables, ports and switches were
tested, all with the same result.
Increasing the maximum delay in the link coming up in
ixgbe_setup_mac_link_multispeed_fiber() from 500ms to 1s seems to resolve the
issue.
--
You are receiving this mail because:
You are the assignee for the bug.
