From: Jerin Jacob <jerinjacobk@gmail.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "Jerin Jacob" <jerinj@marvell.com>, dpdk-dev <dev@dpdk.org>,
"David Marchand" <david.marchand@redhat.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Dmitry Kozlyuk" <dmitry.kozliuk@gmail.com>,
"Narcisa Ana Maria Vasile" <navasile@linux.microsoft.com>,
"Dmitry Malloy (MESHCHANINOV)" <dmitrym@microsoft.com>,
"Pallavi Kadam" <pallavi.kadam@intel.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"Ruifeng Wang (Arm Technology China)" <ruifeng.wang@arm.com>,
"David Christensen" <drc@linux.vnet.ibm.com>,
"Stephen Hemminger" <stephen@networkplumber.org>,
"Olivier Matz" <olivier.matz@6wind.com>,
"Ferruh Yigit" <ferruh.yigit@intel.com>,
"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
"Ajit Khaparde" <ajit.khaparde@broadcom.com>,
"Morten Brørup" <mb@smartsharesystems.com>
Subject: Re: [dpdk-dev] [PATCH v3 0/6] support oops handling
Date: Tue, 21 Sep 2021 23:24:13 +0530 [thread overview]
Message-ID: <CALBAE1N6L2iRsfzua_DzyR3PPD8u2ek5LkQQs-UZ37ebPiHAtA@mail.gmail.com> (raw)
In-Reply-To: <7007516.EuRbNVrdOy@thomas>
On Tue, Sep 21, 2021 at 11:00 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 06/09/2021 06:17, jerinj@marvell.com:
> > It is handy to get detailed OOPS information like Linux kernel
> > when DPDK application crashes without losing any of the features
> > provided by coredump infrastructure by the OS.
> >
> > This patch series introduces the APIs to handle OOPS in DPDK.
>
> I don't understand how it is related to DPDK.
It abstracts the execution environment/architecture(See Arch Info in
log)[1] details to capture
details on fault handlers to enable additional details on fault from
DPDK application for
additional debugging information. Just like Kernel prints its OOPS on fault.
> It looks something to be handled freely by the application
> without DPDK forcing anything.
This NOT enforcing application to use DPDK OOPS handler, instead, if
registered then
it uses the default handler.
Even if the default handler is registered it invokes the application
handler if the application registers
the fault handler. So there is not difference in behavior.
> What is the benefit for other DPDK features?
Could you clarify this question a bit more?
> Which problem is it solving?
Better debug trace on fault for DPDK application. Instead of faulting
with no information.
[1]
Backtrace:
----------
[ 0x55e8b56d5cee]: test_oops_generate()+0x75
[ 0x55e8b5459843]: unit_test_suite_runner()+0x1aa
[ 0x55e8b56d605c]: test_oops()+0x13
[ 0x55e8b544bdfc]: cmd_autotest_parsed()+0x55
[ 0x55e8b6063a0d]: cmdline_parse()+0x319
[ 0x55e8b6061dea]: cmdline_valid_buffer()+0x35
[ 0x55e8b6066bd8]: rdline_char_in()+0xc48
[ 0x55e8b606221c]: cmdline_in()+0x62
[ 0x55e8b6062495]: cmdline_interact()+0x56
[ 0x55e8b5459314]: main()+0x65e
[ 0x7f54b25d2b25]: __libc_start_main()+0xd5
[ 0x55e8b544bc9e]: _start()+0x2e
Arch info:
----------
R8 : 0x0000000000000000 R9 : 0x0000000000000000
R10: 0x00007f54b25b8b48 R11: 0x00007f54b25e7930
R12: 0x00007fffc695e610 R13: 0x0000000000000000
R14: 0x0000000000000000 R15: 0x0000000000000000
RAX: 0x0000000000000005 RBX: 0x0000000000000001
RCX: 0x00007f54b278a943 RDX: 0x3769043bf13a2594
RBP: 0x00007fffc6958340 RSP: 0x00007fffc6958330
RSI: 0x0000000000000000 RDI: 0x000055e8c4c1e380
RIP: 0x000055e8b56d5cee EFL: 0x0000000000010246
Stack dump:
----------
0x7fffc6958330: 0x6000000
0x7fffc6958334: 0x0
0x7fffc6958338: 0x30cfeac5
0x7fffc695833c: 0x0
0x7fffc6958340: 0xe08395c6
0x7fffc6958344: 0xff7f0000
0x7fffc6958348: 0x439845b5
0x7fffc695834c: 0xe8550000
0x7fffc6958350: 0x0
0x7fffc6958354: 0xb000000
0x7fffc6958358: 0x20445bb9
0x7fffc695835c: 0xe8550000
0x7fffc6958360: 0x925506b6
0x7fffc6958364: 0x0
0x7fffc6958368: 0x0
0x7fffc695836c: 0x0
Code dump:
----------
0x55e8b56d5cee: 0xc7000000
0x55e8b56d5cf2: 0xeb12
0x55e8b56d5cf6: 0xfb6054b
0x55e8b56d5cfa: 0x87540f84
0x55e8b56d5cfe: 0xc07407b8
0x55e8b56d5d02: 0x0
0x55e8b56d5d06: 0xeb05b8ff
0x55e8b56d5d0a: 0xffffffc9
0x55e8b56d5d0e: 0xc3554889
0x55e8b56d5d12: 0xe54881ec
0x55e8b56d5d16: 0xc0000000
0x55e8b56d5d1a: 0x89bd4cff
0x55e8b56d5d1e: 0xffff4889
0x55e8b56d5d22: 0xb540ffff
>
next prev parent reply other threads:[~2021-09-21 17:54 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-30 8:49 [dpdk-dev] " jerinj
2021-07-30 8:49 ` [dpdk-dev] 1/6] eal: introduce oops handling API jerinj
2021-08-17 3:27 ` [dpdk-dev] [PATCH v2 0/6] support oops handling jerinj
2021-08-17 3:27 ` [dpdk-dev] [PATCH v2 1/6] eal: introduce oops handling API jerinj
2021-08-17 3:53 ` Stephen Hemminger
2021-08-17 7:38 ` Jerin Jacob
2021-08-17 15:09 ` Stephen Hemminger
2021-08-17 15:27 ` Jerin Jacob
2021-08-17 15:52 ` Stephen Hemminger
2021-08-18 9:37 ` Jerin Jacob
2021-08-18 16:46 ` Stephen Hemminger
2021-08-18 18:04 ` Jerin Jacob
2021-08-17 3:27 ` [dpdk-dev] [PATCH v2 2/6] eal: oops handling API implementation jerinj
2021-08-17 3:52 ` Stephen Hemminger
2021-08-17 10:24 ` Jerin Jacob
2021-08-17 3:27 ` [dpdk-dev] [PATCH v2 3/6] eal: support libunwind based backtrace jerinj
2021-08-17 3:27 ` [dpdk-dev] [PATCH v2 4/6] eal/x86: support register dump for oops jerinj
2021-08-17 3:27 ` [dpdk-dev] [PATCH v2 5/6] eal/arm64: " jerinj
2021-08-17 3:27 ` [dpdk-dev] [PATCH v2 6/6] test/oops: support unit test case for oops handling APIs jerinj
2021-09-06 4:17 ` [dpdk-dev] [PATCH v3 0/6] support oops handling jerinj
2021-09-06 4:17 ` [dpdk-dev] [PATCH v3 1/6] eal: introduce oops handling API jerinj
2021-09-06 4:17 ` [dpdk-dev] [PATCH v3 2/6] eal: oops handling API implementation jerinj
2021-09-06 4:17 ` [dpdk-dev] [PATCH v3 3/6] eal: support libunwind based backtrace jerinj
2022-01-27 20:47 ` Stephen Hemminger
2022-01-28 4:33 ` Jerin Jacob
2022-01-28 8:41 ` Thomas Monjalon
2022-01-28 14:27 ` Jerin Jacob
2022-01-28 17:05 ` Stephen Hemminger
2021-09-06 4:17 ` [dpdk-dev] [PATCH v3 4/6] eal/x86: support register dump for oops jerinj
2021-09-06 4:17 ` [dpdk-dev] [PATCH v3 5/6] eal/arm64: " jerinj
2021-09-06 4:17 ` [dpdk-dev] [PATCH v3 6/6] test/oops: support unit test case for oops handling APIs jerinj
2021-09-21 17:30 ` [dpdk-dev] [PATCH v3 0/6] support oops handling Thomas Monjalon
2021-09-21 17:54 ` Jerin Jacob [this message]
2021-09-22 7:34 ` Thomas Monjalon
2021-09-22 8:03 ` Jerin Jacob
2021-09-22 8:33 ` Thomas Monjalon
2021-09-22 8:49 ` Jerin Jacob
2021-07-30 8:49 ` [dpdk-dev] 2/6] eal: oops handling API implementation jerinj
2021-08-02 22:46 ` David Christensen
2021-07-30 8:49 ` [dpdk-dev] 3/6] eal: support libunwind based backtrace jerinj
2021-07-30 8:49 ` [dpdk-dev] 4/6] eal/x86: support register dump for oops jerinj
2021-07-30 8:49 ` [dpdk-dev] 5/6] eal/arm64: " jerinj
2021-08-02 22:49 ` David Christensen
2021-08-16 16:24 ` Jerin Jacob
2021-07-30 8:49 ` [dpdk-dev] 6/6] test/oops: support unit test case for oops handling APIs jerinj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALBAE1N6L2iRsfzua_DzyR3PPD8u2ek5LkQQs-UZ37ebPiHAtA@mail.gmail.com \
--to=jerinjacobk@gmail.com \
--cc=ajit.khaparde@broadcom.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=dmitrym@microsoft.com \
--cc=drc@linux.vnet.ibm.com \
--cc=ferruh.yigit@intel.com \
--cc=jerinj@marvell.com \
--cc=konstantin.ananyev@intel.com \
--cc=mb@smartsharesystems.com \
--cc=navasile@linux.microsoft.com \
--cc=olivier.matz@6wind.com \
--cc=pallavi.kadam@intel.com \
--cc=ruifeng.wang@arm.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).