From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 75EA146AD9; Mon, 7 Jul 2025 22:39:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1AC6940287; Mon, 7 Jul 2025 22:39:33 +0200 (CEST) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id 1802C4025D for ; Mon, 7 Jul 2025 22:39:31 +0200 (CEST) Received: by inbox.dpdk.org (Postfix, from userid 33) id E714D46B1F; Mon, 7 Jul 2025 22:39:30 +0200 (CEST) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [DPDK/ethdev Bug 1750] ixgbe: X553 link remains down (NO-CARRIER) Date: Mon, 07 Jul 2025 20:39:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: ethdev X-Bugzilla-Version: 24.11 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: clinton@netgate.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: multipart/alternative; boundary=17519207700.b4DDb6F70.505092 Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --17519207700.b4DDb6F70.505092 Date: Mon, 7 Jul 2025 22:39:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All https://bugs.dpdk.org/show_bug.cgi?id=3D1750 Bug ID: 1750 Summary: ixgbe: X553 link remains down (NO-CARRIER) Product: DPDK Version: 24.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: clinton@netgate.com Target Milestone: --- Ethernet Connection X553 10 GbE SFP+ link can get stuck in a DOWN/NO-CARRIER state when starting an application (testpmd or VPP). The interface remains in a DOWN/NO-CARRIER state, even when unbinding the N= IC from vfio-pci followed by binding to the ixgbe kernel driver. The only way = I've been able to bring the interface back up is by rebooting the system. I've tested with multiple systems, SFP+ modules, switches, etc... I initially ran into this when running CSIT tests against VPP. After some t= ime, failures would start occurring because of the link issue. I found that starting/stopping VPP multiple times eventually resulted in the interface s= tate getting stuck down. I replicated this with testpmd as well.=20 Steps to Reproduce: 1. Bind X553 interfaces to vfio-pci driver 2. Compile testpmd application if not already compiled 3. Create a file (ie: testpmd-flap.txt) with the following contents: port stop all set link-up port 0 set link-up port 1 port reset all port start all 4. Create a script to rerun the dpdk-testpmd application while true; do echo | ./dpdk-testpmd -a 0000:03:00.0 -a 0000:03:00.1 -l 1-4 -- --disable-link-check --disable-device-start --cmdline=3Dtestpmd-flap.txt sleep .5 done 5. Run the script. The time it takes to fail can vary...sometimes it only t= akes a minute or so and other times it can take 30+ minutes. You'll need to stop= the script to check the port state (testpmd> show port info all). I'm using two interfaces and generally when this happens only one of the two interfaces shows in the down state. --=20 You are receiving this mail because: You are the assignee for the bug.= --17519207700.b4DDb6F70.505092 Date: Mon, 7 Jul 2025 22:39:30 +0200 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All
Bug ID 1750
Summary ixgbe: X553 link remains down (NO-CARRIER)
Product DPDK
Version 24.11
Hardware x86
OS Linux
Status UNCONFIRMED
Severity normal
Priority Normal
Component ethdev
Assignee dev@dpdk.org
Reporter clinton@netgate.com
Target Milestone --- 

Ethernet Connection X553 10 GbE SF=
P+ link can get stuck in a DOWN/NO-CARRIER
state when starting an application (testpmd or VPP).

The interface remains in a DOWN/NO-CARRIER state, even when unbinding the N=
IC
from vfio-pci followed by binding to the ixgbe kernel driver. The only way =
I've
been able to bring the interface back up is by rebooting the system.

I've tested with multiple systems, SFP+ modules, switches, etc...

I initially ran into this when running CSIT tests against VPP. After some t=
ime,
failures would start occurring because of the link issue. I found that
starting/stopping VPP multiple times eventually resulted in the interface s=
tate
getting stuck down.

I replicated this with testpmd as well.=20

Steps to Reproduce:
1. Bind X553 interfaces to vfio-pci driver
2. Compile testpmd application if not already compiled
3. Create a file (ie: testpmd-flap.txt) with the following contents:
port stop all
set link-up port 0
set link-up port 1
port reset all
port start all

4. Create a script to rerun the dpdk-testpmd application
while true; do
        echo | ./dpdk-testpmd -a 0000:03:00.0 -a 0000:03:00.1 -l 1-4 --
--disable-link-check --disable-device-start --cmdline=3Dtestpmd-flap.txt
        sleep .5
done

5. Run the script. The time it takes to fail can vary...sometimes it only t=
akes
a minute or so and other times it can take 30+ minutes. You'll need to stop=
 the
script to check the port state (testpmd> show port info all).

I'm using two interfaces and generally when this happens only one of the two
interfaces shows in the down state.

You are receiving this mail because:
  • You are the assignee for the bug.
=20=20=20=20=20=20=20=20=20=20
= --17519207700.b4DDb6F70.505092--