From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <users-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 2F6BB42E53
	for <public@inbox.dpdk.org>; Wed, 12 Jul 2023 14:07:39 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id EA96F40A7D;
	Wed, 12 Jul 2023 14:07:38 +0200 (CEST)
Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188])
 by mails.dpdk.org (Postfix) with ESMTP id EE530406BA
 for <users@dpdk.org>; Wed, 12 Jul 2023 14:07:35 +0200 (CEST)
Received: from kwepemi500010.china.huawei.com (unknown [172.30.72.55])
 by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4R1GcZ6l1CzMqbW;
 Wed, 12 Jul 2023 20:04:14 +0800 (CST)
Received: from dggpeml500020.china.huawei.com (7.185.36.88) by
 kwepemi500010.china.huawei.com (7.221.188.191) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.27; Wed, 12 Jul 2023 20:07:31 +0800
Received: from dggpeml500020.china.huawei.com ([7.185.36.88]) by
 dggpeml500020.china.huawei.com ([7.185.36.88]) with mapi id 15.01.2507.027;
 Wed, 12 Jul 2023 20:07:31 +0800
From: "jiangheng (G)" <jiangheng14@huawei.com>
To: "matan@nvidia.com" <matan@nvidia.com>, Slava Ovsiienko
 <viacheslavo@nvidia.com>
CC: "users@dpdk.org" <users@dpdk.org>
Subject: dpdk coredump when i used mlx5 NIC send packets in secondary process
Thread-Topic: dpdk coredump when i used mlx5 NIC send packets in secondary
 process
Thread-Index: Adm0uTghKODOHpmMSrOdq+g/wkE4Uw==
Date: Wed, 12 Jul 2023 12:07:31 +0000
Message-ID: <d3c1ebcc564241eb906d186f4c04c158@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.117.195]
Content-Type: multipart/alternative;
 boundary="_000_d3c1ebcc564241eb906d186f4c04c158huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-BeenThere: users@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK usage discussions <users.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/users>,
 <mailto:users-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/users/>
List-Post: <mailto:users@dpdk.org>
List-Help: <mailto:users-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/users>,
 <mailto:users-request@dpdk.org?subject=subscribe>
Errors-To: users-bounces@dpdk.org

--_000_d3c1ebcc564241eb906d186f4c04c158huaweicom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi matan and Slava:
I observed dpdk coredump when I used mlx5 NIC send packets in secondary pro=
cess:

Thread 6 received signal SIGSEGV, Segmentation fault.
[Switching to LWP 593263]
0x00007ffff7f5b44e in rte_eth_tx_burst (port_id=3D0, queue_id=3D3, tx_pkts=
=3D0x7fffefff7f28, nb_pkts=3D1)
at /usr/local/include/rte_ethdev.h:5777
5777 qd =3D p->txq.data[queue_id];
(gdb) bt
#0 0x00007ffff7f5b44e in rte_eth_tx_burst (port_id=3D0, queue_id=3D3, tx_pk=
ts=3D0x7fffefff7f28, nb_pkts=3D1)
at /usr/local/include/rte_ethdev.h:5777
#1 0x00007ffff7f5ed7a in vdev_tx_xmit (stack=3D0x7fffe8000b20, pkts=3D0x7ff=
fefff7f28, nr_pkts=3D1) at netif/lstack_vdev.c:142
#2 0x00007ffff7f4bd77 in eth_dev_output (netif=3D0x7fffe8002528, pbuf=3D0x0=
) at netif/lstack_ethdev.c:876
#3 0x00007ffff7e84ab8 in etharp_raw (netif=3D0x7fffe8002528, ethsrc_addr=3D=
0x7fffe8002564,
ethdst_addr=3D0x7ffff7f775da <ethbroadcast>, hwsrc_addr=3D0x7fffe8002564, i=
psrc_addr=3D0x7fffe8002530,
hwdst_addr=3D0x7ffff7f775d4 <ethzero>, ipdst_addr=3D0x7fffe8002530, opcode=
=3D1) at core/ipv4/etharp.c:1179
#4 0x00007ffff7e84ec8 in etharp_request_dst (hw_dst_addr=3D<optimized out>,=
 ipaddr=3D<optimized out>, netif=3D<optimized out>)
at core/ipv4/etharp.c:1206
#5 etharp_request (netif=3D<optimized out>, ipaddr=3D<optimized out>) at co=
re/ipv4/etharp.c:1224

(gdb) p *p
$1 =3D {rx_pkt_burst =3D 0x7ffff63288c0 <mlx5_rx_burst_vec>, rx_queue_count=
 =3D 0x0,
rx_descriptor_status =3D 0x7ffff61709d0 <mlx5_rx_descriptor_status>, rxq =
=3D {data =3D 0x0,
clbk =3D 0x7ffff6e515a8 <rte_eth_devices+104>}, reserved1 =3D {0, 0, 0}, tx=
_pkt_burst =3D 0x7ffff623ba60 <mlx5_tx_burst_none>,
tx_pkt_prepare =3D 0x0, tx_descriptor_status =3D 0x7ffff618a870 <mlx5_tx_de=
scriptor_status>, txq =3D {data =3D 0x0,
clbk =3D 0x7ffff6e535a8 <rte_eth_devices+8296>}, reserved2 =3D {0, 0, 0}}
(gdb) p p->txq.data
$2 =3D (void **) 0x0
(gdb)


P->txq.data is NULL

I used dpdk-21.11. (https://github.com/DPDK/dpdk/tree/v22.11), I looked up =
the stable branch, and there doesn't seem to be a relevant bugfix patch.
The same app does not have this coredump on i40e/ixgbe NIC.


Thanks

--_000_d3c1ebcc564241eb906d186f4c04c158huaweicom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
/* Page Definitions */
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"#0563C1" vlink=3D"#954F72" style=3D"text-justi=
fy-trim:punctuation">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US">Hi matan and Slava:<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I observed dpdk coredump when I=
 used mlx5 NIC send packets in secondary process:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Thread 6 received signal SIGSEG=
V, Segmentation fault.<br>
[Switching to LWP 593263]<br>
0x00007ffff7f5b44e in rte_eth_tx_burst (port_id=3D0, queue_id=3D3, tx_pkts=
=3D0x7fffefff7f28, nb_pkts=3D1)<br>
at /usr/local/include/rte_ethdev.h:5777<br>
5777 qd =3D p-&gt;txq.data[queue_id];<br>
(gdb) bt<br>
#0 0x00007ffff7f5b44e in rte_eth_tx_burst (port_id=3D0, queue_id=3D3, tx_pk=
ts=3D0x7fffefff7f28, nb_pkts=3D1)<br>
at /usr/local/include/rte_ethdev.h:5777<br>
#1 0x00007ffff7f5ed7a in vdev_tx_xmit (stack=3D0x7fffe8000b20, pkts=3D0x7ff=
fefff7f28, nr_pkts=3D1) at netif/lstack_vdev.c:142<br>
#2 0x00007ffff7f4bd77 in eth_dev_output (netif=3D0x7fffe8002528, pbuf=3D0x0=
) at netif/lstack_ethdev.c:876<br>
#3 0x00007ffff7e84ab8 in etharp_raw (netif=3D0x7fffe8002528, ethsrc_addr=3D=
0x7fffe8002564,
<br>
ethdst_addr=3D0x7ffff7f775da &lt;ethbroadcast&gt;, hwsrc_addr=3D0x7fffe8002=
564, ipsrc_addr=3D0x7fffe8002530,
<br>
hwdst_addr=3D0x7ffff7f775d4 &lt;ethzero&gt;, ipdst_addr=3D0x7fffe8002530, o=
pcode=3D1) at core/ipv4/etharp.c:1179<br>
#4 0x00007ffff7e84ec8 in etharp_request_dst (hw_dst_addr=3D&lt;optimized ou=
t&gt;, ipaddr=3D&lt;optimized out&gt;, netif=3D&lt;optimized out&gt;)<br>
at core/ipv4/etharp.c:1206<br>
#5 etharp_request (netif=3D&lt;optimized out&gt;, ipaddr=3D&lt;optimized ou=
t&gt;) at core/ipv4/etharp.c:1224<br>
<br>
(gdb) p *p<br>
$1 =3D {rx_pkt_burst =3D 0x7ffff63288c0 &lt;mlx5_rx_burst_vec&gt;, rx_queue=
_count =3D 0x0, <br>
rx_descriptor_status =3D 0x7ffff61709d0 &lt;mlx5_rx_descriptor_status&gt;, =
rxq =3D {data =3D 0x0,
<br>
clbk =3D 0x7ffff6e515a8 &lt;rte_eth_devices&#43;104&gt;}, reserved1 =3D {0,=
 0, 0}, tx_pkt_burst =3D 0x7ffff623ba60 &lt;mlx5_tx_burst_none&gt;,
<br>
tx_pkt_prepare =3D 0x0, tx_descriptor_status =3D 0x7ffff618a870 &lt;mlx5_tx=
_descriptor_status&gt;, txq =3D {data =3D 0x0,
<br>
clbk =3D 0x7ffff6e535a8 &lt;rte_eth_devices&#43;8296&gt;}, reserved2 =3D {0=
, 0, 0}}<br>
(gdb) p p-&gt;txq.data<br>
$2 =3D (void **) 0x0<br>
(gdb)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">P-&gt;txq.data is NULL <o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I used dpdk-21.11. (<a href=3D"=
https://github.com/DPDK/dpdk/tree/v22.11">https://github.com/DPDK/dpdk/tree=
/v22.11</a>), I looked up the stable branch, and there doesn't seem to be a=
 relevant bugfix patch.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The same app does not have this=
 coredump on i40e/ixgbe NIC.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Thanks<o:p></o:p></span></p>
</div>
</body>
</html>

--_000_d3c1ebcc564241eb906d186f4c04c158huaweicom_--