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 EC2D343CA0; Wed, 13 Mar 2024 17:29:59 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3229142DD5; Wed, 13 Mar 2024 17:29:59 +0100 (CET) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by mails.dpdk.org (Postfix) with ESMTP id 5F5EF406BC for ; Wed, 13 Mar 2024 17:29:56 +0100 (CET) Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1dd97fd66cdso50325ad.1 for ; Wed, 13 Mar 2024 09:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1710347396; x=1710952196; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=+j3uZ2bYNZnzKuXvJ711CrOJgwu8tdQW4xon/w4EG9o=; b=0wy7AhubTZKXbErz0XnLVc0+Ou/Jv4OTJ/TbgIuUIZiy/Srz21nTqCwPUsBA7vDDX4 jThwNIMXNq3yMHPDFBXwiAExa7vSLi0Lb5Ls9L/AbQA5yvhwUx6EB+I2EkeakHcfkek8 KcLQpedjBmlbTH3k6sNbuPIx3DC21/qBVOMT1b+I/aGsL+SWWbN0+YrnRQjYuo5mCM0s aGlvPsSP9Q9UOP14wPDrRr/ttAtUPaZsskiV7x1/furuMTI3RbJzNi8oMAkI0E+eeNlf +kAliqDpo1e7LYpDulPrrW4TCA8bf/x2LOX/b2B7DeRyGbFnGkS/zGN/CtV4R4JrnrAq T4Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710347396; x=1710952196; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+j3uZ2bYNZnzKuXvJ711CrOJgwu8tdQW4xon/w4EG9o=; b=FPLAgQZDQ/MrhHtYp2NkwRFnM47Rx1BHlp0cX2DXy9JVNgcYVJYr9pz+SEEDx1S29k ueu967o7OCdWtwK65Xbq4kUG3wi9ZhPmYy3tYszAbIyZYf3IchSvU6SvutBFjEZJeLY2 pMfHq3foAv3NDeJ8+jPEHRNsjfQ2ny+5ef/DuUmufi2JhJKfL/mE4M56mtEDkiSBQagD b2N7Dipje+yS2F15odDQnvG3yxOqqy2CqLIH6zInJcoMrVZ2bcmCDoUyWrR3RZtk+hS4 f7wZjpJrB81RUmUdjRHr/h0qxP/ZZJmaUlwl5gjn4B29Uvh2rpjCsdmzEgToeZglVQ5Z UpJA== X-Gm-Message-State: AOJu0YwsQVexDjNLnsbrev1BFC+l6+rwYb/dp9YeujcMsogRypBoWWH6 GPu7MBDkoFJZPKWRYOOx/Aj8tBzCOt337DPyfrY/SLXMwyCx402VU65BOsRTjshJvEjf74NtzVk V X-Google-Smtp-Source: AGHT+IEGxrmrxQ+YD+Tgg8rNPw0cgYWcJ/lYBh6j7EmAl6rTPQkS5r6RL68KdSkSoSCqfTmw1XN7tA== X-Received: by 2002:a17:902:ec8f:b0:1dd:a314:7351 with SMTP id x15-20020a170902ec8f00b001dda3147351mr11640522plg.57.1710347395704; Wed, 13 Mar 2024 09:29:55 -0700 (PDT) Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id l6-20020a170902ec0600b001dd0a41447fsm8814555pld.233.2024.03.13.09.29.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Mar 2024 09:29:55 -0700 (PDT) Date: Wed, 13 Mar 2024 09:29:53 -0700 From: Stephen Hemminger To: "junwang01@cestc.cn" Cc: dev Subject: Re: dumpcap coredump for 82599 NIC Message-ID: <20240313092953.517ac6c7@hermes.local> In-Reply-To: <202403131000157988276@cestc.cn> References: <202403131000157988276@cestc.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Wed, 13 Mar 2024 10:00:17 +0800 "junwang01@cestc.cn" wrote: > Hi, when I use dumpcap to capture packets on the 82559 network card, coredump appears. > The network card bound to ovs-dpdk is 82599, but when I capture packets in other non-82599 network cards (mellanox CX5/C6 or Intel's E810), it is normal. , > the dpdk version I am using is 22.11.1, but I see that the call stack is strange, so I am asking you for help. > > > > > > I thought the new version of dpdk might solve it, so I upgraded the dpdk version to 23.11, but the problem is still the same, but the call stack is different and weirder. > > > > > > > junwang01@cestc.cn This is not an issue with dumpcap. The problem is in ixgbe driver. Some part of the code for checking link status is not safe to be called in secondary process. The backtrace looks a bit messed up, since ixgbe driver should not be calling i40e code. Maybe do a debug build (so more complete symbols available).