From: Norbert Lange via lttng-dev <lttng-dev@lists.lttng.org> To: MONTET Julien <julien.montet@reseau.eseo.fr> Cc: Jan Kiszka <jan.kiszka@siemens.com>, lttng-dev <lttng-dev@lists.lttng.org>, Xenomai <xenomai@xenomai.org> Subject: Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read() Date: Tue, 25 May 2021 10:46:35 +0200 [thread overview] Message-ID: <CADYdroMmANMwnkfVMUOJuFJ-=_ggnE_4u=qoFSsdtgk_1SkTEQ@mail.gmail.com> (raw) In-Reply-To: <PR3PR02MB6202E077AEC8C62B022780EED1299@PR3PR02MB6202.eurprd02.prod.outlook.com> Am Fr., 21. Mai 2021 um 12:13 Uhr schrieb MONTET Julien <julien.montet@reseau.eseo.fr>: > > Hello Mathieu, Norbert and Jan, > > Thank you for all of your explainations and the overview of the system. > No I didn't change the ipipe patch for the vDSO, I may try this. > If I have correctly understood, this patch prevents Cobalt from entering in a deadlock when the kernel is using the vDSO and the program interrupts the kernel at the same time. On which kernel does it word (aroubd 4.19) ? > I currently try to avoid kernel 5.4 because I remember I faced some boot issues (but it is on another topic). That patch was for 4.19 AFAIR, but its specific to x86. The Linux kernel cleaned up the vdso handling to have a common base with some 5.x version, but back then its been separate for each arch > > Here the issues i faced (drawn on TraceCompass). Are these the deadlocks we are talking about ? > https://postimg.cc/BP4G3bF0 (on 11:02:56:380) > https://postimg.cc/q6wHvrcC Nope, if you get such a deadlock, then your only hope is Xenomai's Watchdog killing the process. It should happen very rarely (but thats not an argument if your software should run for years). Norbert _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
WARNING: multiple messages have this Message-ID (diff)
From: Norbert Lange <nolange79@gmail.com> To: MONTET Julien <julien.montet@reseau.eseo.fr> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, lttng-dev <lttng-dev@lists.lttng.org>, Jan Kiszka <jan.kiszka@siemens.com>, Xenomai <xenomai@xenomai.org> Subject: Re: [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read() Date: Tue, 25 May 2021 10:46:35 +0200 [thread overview] Message-ID: <CADYdroMmANMwnkfVMUOJuFJ-=_ggnE_4u=qoFSsdtgk_1SkTEQ@mail.gmail.com> (raw) In-Reply-To: <PR3PR02MB6202E077AEC8C62B022780EED1299@PR3PR02MB6202.eurprd02.prod.outlook.com> Am Fr., 21. Mai 2021 um 12:13 Uhr schrieb MONTET Julien <julien.montet@reseau.eseo.fr>: > > Hello Mathieu, Norbert and Jan, > > Thank you for all of your explainations and the overview of the system. > No I didn't change the ipipe patch for the vDSO, I may try this. > If I have correctly understood, this patch prevents Cobalt from entering in a deadlock when the kernel is using the vDSO and the program interrupts the kernel at the same time. On which kernel does it word (aroubd 4.19) ? > I currently try to avoid kernel 5.4 because I remember I faced some boot issues (but it is on another topic). That patch was for 4.19 AFAIR, but its specific to x86. The Linux kernel cleaned up the vdso handling to have a common base with some 5.x version, but back then its been separate for each arch > > Here the issues i faced (drawn on TraceCompass). Are these the deadlocks we are talking about ? > https://postimg.cc/BP4G3bF0 (on 11:02:56:380) > https://postimg.cc/q6wHvrcC Nope, if you get such a deadlock, then your only hope is Xenomai's Watchdog killing the process. It should happen very rarely (but thats not an argument if your software should run for years). Norbert
next prev parent reply other threads:[~2021-05-25 8:46 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-20 7:58 [lttng-dev] LTTng - Xenomai : different results between timestamp-lttng and rt_time_read() MONTET Julien via lttng-dev 2021-05-20 8:20 ` Norbert Lange via lttng-dev 2021-05-20 8:28 ` MONTET Julien via lttng-dev 2021-05-20 9:11 ` Norbert Lange via lttng-dev 2021-05-20 13:54 ` Mathieu Desnoyers via lttng-dev 2021-05-20 13:56 ` Mathieu Desnoyers via lttng-dev 2021-05-20 15:09 ` Mathieu Desnoyers via lttng-dev 2021-05-20 15:09 ` Mathieu Desnoyers 2021-05-20 15:34 ` Jan Kiszka via lttng-dev 2021-05-20 15:34 ` Jan Kiszka 2021-05-20 15:39 ` Norbert Lange via lttng-dev 2021-05-20 15:39 ` Norbert Lange 2021-05-21 10:13 ` MONTET Julien via lttng-dev 2021-05-21 10:13 ` MONTET Julien 2021-05-25 8:46 ` Norbert Lange via lttng-dev [this message] 2021-05-25 8:46 ` Norbert Lange
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='CADYdroMmANMwnkfVMUOJuFJ-=_ggnE_4u=qoFSsdtgk_1SkTEQ@mail.gmail.com' \ --to=lttng-dev@lists.lttng.org \ --cc=jan.kiszka@siemens.com \ --cc=julien.montet@reseau.eseo.fr \ --cc=nolange79@gmail.com \ --cc=xenomai@xenomai.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.