Re: [OE-core] [PATCH 23/23] ptest-packagelists.inc: exclude lttng-tools-ptest
Hi, > This is the patch that disables the sporadically failing stuff: > [ > http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/lttng/lttng-tools/0001-tests-regression-disable-the-tools-live-tests.patch > | > http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/lttng/lttng-tools/0001-tests-regression-disable-the-tools-live-tests.patch > ] I suspect that some of these tests are not that sporadic anymore since a lot of work was done on the live feature. Still, it is not up to you to prove this. > And this is the bug I had filed upstream: > [ https://bugs.lttng.org/issues/1217 | https://bugs.lttng.org/issues/1217 ] Well, time goes by fast. > As no movement occurred on that bug since Jan, I am not keen on filing > additional bugs, but you can see the additional, I'm okay with taking responsibility regarding the long time to fix but not so much in not fixing bug/issues that are simply not reported. Not all issues are of the same nature and require the same amount of work to fix. > currently occuring failures here: > [ > https://autobuilder.yocto.io/pub/non-release/20201204-4/testresults/qemux86-64-ptest/lttng-tools.log > | > https://autobuilder.yocto.io/pub/non-release/20201204-4/testresults/qemux86-64-ptest/lttng-tools.log > ] Thanks for the link. Any link or doc that would allow me to easily setup a similar build (conf file, ram size etc.). Is core-image-sato-sdk-ptest a good image to reproduce this? Cheers -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145320): https://lists.openembedded.org/g/openembedded-core/message/145320 Mute This Topic: https://lists.openembedded.org/mt/78718062/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 23/23] ptest-packagelists.inc: exclude lttng-tools-ptest
Hi, Upstream here. Always happy to give input as long as we are put in the loop. Also bugs/sporadic test failure can be reported on our mailing list [1] and bug tracker[2]. [1] https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev [2] https://bugs.lttng.org/ We understand that the burden can be quite high for a project such as lttng given we end up doing weird testing due to the nature of our work and that we are human ;). Still we are always interested in getting info about "sporadic" failures. To be clear, we are not against this patch. We understand the burden associated with testing lttng. Cheers - Original Message - > From: "Alexander Kanavin" > To: "openembedded-core" > Cc: "Alexander Kanavin" > Sent: Friday, December 4, 2020 3:07:36 PM > Subject: [OE-core] [PATCH 23/23] ptest-packagelists.inc: exclude > lttng-tools-ptest > These tests have been failing for a long time (and even more failing > tests are already patched out); no one in YP has the > expertise to fix the issues, so until upstream steps in, let's take > them out, and try to reach the goal of hard ptest failures so that > ptest regressions are caught as they happen. > > Signed-off-by: Alexander Kanavin > --- > meta/conf/distro/include/ptest-packagelists.inc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/conf/distro/include/ptest-packagelists.inc > b/meta/conf/distro/include/ptest-packagelists.inc > index ce13368c2e..90272a70af 100644 > --- a/meta/conf/distro/include/ptest-packagelists.inc > +++ b/meta/conf/distro/include/ptest-packagelists.inc > @@ -60,6 +60,7 @@ PTESTS_FAST_remove_mips64 = "qemu-ptest" > #bash-ptest \ # Test outcomes are non-deterministic by design > #ifupdown-ptest \ # Tested separately in > lib/oeqa/selftest/cases/imagefeatures.py > #mdadm-ptest \ # Tests rely on non-deterministic sleep() amounts > +#lttng-tools-ptest \ # multiple sporadic failures, lack of expertise in > the > project to look into them > #" > > PTESTS_SLOW = "\ > @@ -73,7 +74,6 @@ PTESTS_SLOW = "\ > gstreamer1.0-ptest \ > libevent-ptest \ > libinput-ptest \ > -lttng-tools-ptest \ > openssh-ptest \ > openssl-ptest \ > perl-ptest \ > -- > 2.29.2 > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145318): https://lists.openembedded.org/g/openembedded-core/message/145318 Mute This Topic: https://lists.openembedded.org/mt/78718062/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] lttng-tools: Do not build for riscv64
Hi,
LTTng does not have a hard requirement on lttng-modules (on paper), when kernel
modules
(tracer) is not present kernel tracing is disabled and only userspace tracing is
available.
Was there any report that lttng-ust (userspace tracing) is not working as
intended on riscv64?
Cheers
On Tue, Aug 25, 2020 at 10:41:01PM -0700, Khem Raj wrote:
> Since lttng-modules are not buildable, there is no point of building
> tools either
>
> Signed-off-by: Khem Raj
> ---
> .../packagegroups/packagegroup-core-tools-profile.bb | 1 +
> meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb| 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git
> a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> index ca35af1ec3..608e406f83 100644
> --- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> +++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
> @@ -41,6 +41,7 @@ LTTNGUST_arc = ""
>
> LTTNGTOOLS = "lttng-tools"
> LTTNGTOOLS_arc = ""
> +LTTNGTOOLS_riscv64 = ""
>
> LTTNGMODULES = "lttng-modules"
> LTTNGMODULES_arc = ""
> diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
> b/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
> index e9c8e18e22..0614e86713 100644
> --- a/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
> +++ b/meta/recipes-kernel/lttng/lttng-tools_2.12.2.bb
> @@ -162,3 +162,6 @@ do_install_ptest () {
> esac
> done
> }
> +
> +COMPATIBLE_HOST_riscv64 = "null"
> +
> --
> 2.28.0
>
>
--
Jonathan Rajotte-Julien
EfficiOS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#141863):
https://lists.openembedded.org/g/openembedded-core/message/141863
Mute This Topic: https://lists.openembedded.org/mt/76422926/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] babletrace2: make manpages multilib identical
On Fri, Mar 13, 2020 at 07:22:03AM +, Richard Purdie wrote: > On Thu, 2020-03-12 at 10:25 -0400, Jonathan Rajotte-Julien wrote: > > Is this something upstream (lttng-dev mailing list) should be > > interested in? > > Its a tough one as the man page is technically correct but the > references give us a challenge in packaging it. I can therefore > understand upstreams not accepting changes like this but if they were > open to some kind of tweak it does help us not have to have patches... Jeremy does plan to send us a version for upstream (bt2) someday, or at least start the discussion on how to help yocto packaging on that end. We will see how we can make everyone happy then. Cheers -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] babeltrace2: initialize the other_entry pointer
Hi Mingli,
Thanks for also posting this on the lttng-dev mailing list. I'm sure we can get
this in fairly quickly upstream.
This is more a question for Richard and other core members of oe, is this kind
of
patch pertinent for upstream oe considering it is only silencing a
warning (based on [1])?
[1] https://lists.lttng.org/pipermail/lttng-dev/2020-March/029550.html
On Wed, Mar 11, 2020 at 09:49:33PM +0800, mingli...@windriver.com wrote:
> From: Mingli Yu
>
> When add below line to local.conf to enable debug build:
>
> DEBUG_BUILD = "1"
>
> There comes below failure when run "bitbake babeltrace2"
> | ../../../../../git/src/plugins/ctf/fs-src/fs.c: In function
> 'ds_index_insert_ds_index_entry_sorted':
> | ../../../../../git/src/plugins/ctf/fs-src/fs.c:702:5: error: 'other_entry'
> may be used uninitialized in this function [-Werror=maybe-uninitialized]
> | 702 |!ds_index_entries_equal(entry, other_entry)) {
>
> So initialize the other_entry pointer to fix the above error.
>
> Signed-off-by: Mingli Yu
> ---
> .../0001-fs.c-initialize-other_entry.patch | 33
> ++
> meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb | 1 +
> 2 files changed, 34 insertions(+)
> create mode 100644
> meta/recipes-kernel/lttng/babeltrace2/0001-fs.c-initialize-other_entry.patch
>
> diff --git
> a/meta/recipes-kernel/lttng/babeltrace2/0001-fs.c-initialize-other_entry.patch
>
> b/meta/recipes-kernel/lttng/babeltrace2/0001-fs.c-initialize-other_entry.patch
> new file mode 100644
> index 000..b56b3bd
> --- /dev/null
> +++
> b/meta/recipes-kernel/lttng/babeltrace2/0001-fs.c-initialize-other_entry.patch
> @@ -0,0 +1,33 @@
> +From 42dae692b9057d03ce9a0651f061472e9dd90130 Mon Sep 17 00:00:00 2001
> +From: Mingli Yu
> +Date: Wed, 11 Mar 2020 08:44:42 +
> +Subject: [PATCH] fs.c: initialize the other_entry variable
> +
> +Initialize the pointer other_entry to fix the below error:
> +| ../../../../../git/src/plugins/ctf/fs-src/fs.c: In function
> 'ds_index_insert_ds_index_entry_sorted':
> +| ../../../../../git/src/plugins/ctf/fs-src/fs.c:702:5: error: 'other_entry'
> may be used uninitialized in this function [-Werror=maybe-uninitialized]
> +| 702 |!ds_index_entries_equal(entry, other_entry)) {
> +
> +Upstream-Status: Submitted
> [https://lists.lttng.org/pipermail/lttng-dev/2020-March/029549.html]
> +
> +Signed-off-by: Mingli Yu
> +---
> + src/plugins/ctf/fs-src/fs.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/src/plugins/ctf/fs-src/fs.c b/src/plugins/ctf/fs-src/fs.c
> +index e87523a3..a6b5315f 100644
> +--- a/src/plugins/ctf/fs-src/fs.c
> b/src/plugins/ctf/fs-src/fs.c
> +@@ -680,7 +680,7 @@ void ds_index_insert_ds_index_entry_sorted(
> + struct ctf_fs_ds_index_entry *entry)
> + {
> + guint i;
> +-struct ctf_fs_ds_index_entry *other_entry;
> ++struct ctf_fs_ds_index_entry *other_entry = NULL;
> +
> + /* Find the spot where to insert this index entry. */
> + for (i = 0; i < index->entries->len; i++) {
> +--
> +2.24.1
> +
> diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb
> b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb
> index 16953d6..c027d8b 100644
> --- a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb
> +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb
> @@ -10,6 +10,7 @@ DEPENDS = "glib-2.0 util-linux popt bison-native
> flex-native"
> SRC_URI =
> "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0 \
> file://run-ptest \
> file://0001-tests-do-not-run-test-applications-from-.libs.patch \
> +file://0001-fs.c-initialize-other_entry.patch \
> "
> SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910"
> UPSTREAM_CHECK_GITTAGREGEX = "v(?P2(\.\d+)+)$"
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] babletrace2: make manpages multilib identical
Hi Is this something upstream (lttng-dev mailing list) should be interested in? Cheers On Wed, Mar 11, 2020 at 03:22:48PM -0700, Jeremy A. Puhlman wrote: > From: Jeremy Puhlman > > Signed-off-by: Jeremy A. Puhlman > --- > .../0001-Make-manpages-multilib-identical.patch| 28 > ++ > meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb | 1 + > 2 files changed, 29 insertions(+) > create mode 100644 > meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch > > diff --git > a/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch > > b/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch > new file mode 100644 > index 00..2401b176e6 > --- /dev/null > +++ > b/meta/recipes-kernel/lttng/babeltrace2/0001-Make-manpages-multilib-identical.patch > @@ -0,0 +1,28 @@ > +From 56986190e4b0c10945ce6aaa7ca10d6bd8a26a39 Mon Sep 17 00:00:00 2001 > +From: Jeremy Puhlman > +Date: Mon, 9 Mar 2020 21:10:35 + > +Subject: [PATCH] Make manpages multilib identical > + > +Upstream-Status: Pending > +Signed-off-by: Jeremy Puhlman > +--- > + doc/man/asciidoc-attrs.conf.in | 4 ++-- > + 1 file changed, 2 insertions(+), 2 deletions(-) > + > +diff --git a/doc/man/asciidoc-attrs.conf.in b/doc/man/asciidoc-attrs.conf.in > +index ad1183f1..e11c7031 100644 > +--- a/doc/man/asciidoc-attrs.conf.in > b/doc/man/asciidoc-attrs.conf.in > +@@ -1,7 +1,7 @@ > + [attributes] > + # default values > +-system_plugin_path="@LIBDIR@/babeltrace2/plugins" > +-system_plugin_provider_path="@LIBDIR@/babeltrace2/plugin-providers" > ++system_plugin_path="@prefix@/lib*/babeltrace2/plugins" > ++system_plugin_provider_path="@prefix@/lib*/babeltrace2/plugin-providers" > + babeltrace_version="@PACKAGE_VERSION@" > + enable_debug_info="@ENABLE_DEBUG_INFO_VAL@" > + defrdport=5344 > +-- > +2.24.1 > + > diff --git a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > index 16953d6807..61bc7f5e6b 100644 > --- a/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > +++ b/meta/recipes-kernel/lttng/babeltrace2_2.0.1.bb > @@ -10,6 +10,7 @@ DEPENDS = "glib-2.0 util-linux popt bison-native > flex-native" > SRC_URI = > "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-2.0 \ > file://run-ptest \ > file://0001-tests-do-not-run-test-applications-from-.libs.patch \ > + file://0001-Make-manpages-multilib-identical.patch \ > " > SRCREV = "06df58f89ee51b1a2c6a2c187ec3f15691633910" > UPSTREAM_CHECK_GITTAGREGEX = "v(?P2(\.\d+)+)$" > -- > 2.13.3 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lttng-modules: Check the pid_ns before using it because it may be NULL
Hi, We released patch level release for our stable branch [1]. These release includes the fix proposed here. Please validate that it fixes your issues. [1] https://lists.linuxfoundation.org/pipermail/diamon-discuss/2020-February/000196.html Cheers - Original Message - > From: "Li Zhou" > To: "Jonathan Rajotte-Julien" > Cc: "openembedded-core" > Sent: Tuesday, February 25, 2020 3:41:58 AM > Subject: Re: [OE-core] [PATCH] lttng-modules: Check the pid_ns before using > it because it may be NULL > On 2/20/20 10:47 PM, Jonathan Rajotte-Julien wrote: >> Hi, >> >> Can we get more info on the kernel version and config? >> >> Did you submit this on our mailing list?(lttng-dev). If not I would highly >> recommend that you do so in the future so we can eliminate *custom* patches >> and >> get to the bottom of the issue at hand so that the whole community benefit >> from >> it. > > > Hi, Jonathan: > > Thank you for you help and suggestion on this. This issue is > seen on linux 4.18 + lttng-modules 2.10. > > >> >> Cheers >> >> - Li Zhou wrote: >>> Check the pid_ns before using it because it may be NULL to fix below >>> issue: >>> <1>[ 22.637196] Unable to handle kernel NULL pointer dereference at >>> virtual address 0080 >>> <1>[ 22.645982] Mem abort info: >>> <1>[ 22.648769] ESR = 0x9607 >>> <1>[ 22.651817] Exception class = DABT (current EL), IL = 32 bits >>> <1>[ 22.657730] SET = 0, FnV = 0 >>> <1>[ 22.660777] EA = 0, S1PTW = 0 >>> <1>[ 22.663910] Data abort info: >>> <1>[ 22.666784] ISV = 0, ISS = 0x0007 >>> <1>[ 22.670611] CM = 0, WnR = 0 >>> <1>[ 22.673574] user pgtable: 4k pages, 39-bit VAs, pgdp = >>> 12378f78 >>> <1>[ 22.680180] [0080] pgd=7f023003, >>> pud=7f023003, pmd=7f01f003, pte= >>> <0>[ 22.690794] Internal error: Oops: 9607 [#1] PREEMPT SMP >>> <4>[ 22.690797] Modules linked in: adkNetD ncp >>> lttng_ring_buffer_client_overwrite(C) >>> lttng_ring_buffer_metadata_client(C) lttng_ring_buffer_client_discard(C) >>> lttng_ring_buffer_client_mmap_overwrite(C) >>> lttng_ring_buffer_client_mmap_discard(C) >>> lttng_ring_buffer_metadata_mmap_client(C) lttng_probe_signal(C) >>> lttng_probe_printk(C) lttng_probe_sched(C) lttng_probe_irq(C) >>> lttng_tracer(C) lttng_statedump(C) lttng_ftrace(C) >>> lttng_lib_ring_buffer(C) lttng_clock_plugin_arm_cntpct(C) lttng_clock(C) >>> <0>[ 22.690823] Process lttng-sessiond (pid: 3093, stack limit = >>> 0x5d27910f) >>> <4>[ 22.690828] CPU: 1 PID: 3093 Comm: lttng-sessiond Tainted: G C >>> 4.18.37-rt820-custom #1 >>> <4>[ 22.690830] Hardware name: DUS33 (CPM2-20) (DT) >>> <4>[ 22.690833] pstate: 6005 (nZCv daif -PAN -UAO) >>> <4>[ 22.690845] pc : do_lttng_statedump+0xcc/0x8a8 [lttng_statedump] >>> <4>[ 22.690849] lr : do_lttng_statedump+0xc4/0x8a8 [lttng_statedump] >>> <4>[ 22.690851] sp : ffc07fe57ad0 >>> <4>[ 22.690852] x29: ffc07fe57ad0 x28: ffc008ae2700 >>> <4>[ 22.690856] x27: ff8000724000 x26: 0001 >>> <4>[ 22.690859] x25: ff80089c9620 x24: >>> <4>[ 22.690862] x23: ffc008ae2e10 x22: ff80089d3380 >>> <4>[ 22.690865] x21: ffc07f45 x20: ffc008ae2700 >>> <4>[ 22.690869] x19: 0007 x18: fffe >>> <4>[ 22.690871] x17: x16: ff800824b980 >>> <4>[ 22.690874] x15: x14: 736162203b656e6f >>> <4>[ 22.690877] x13: 6e203d20676e6964 x12: >>> <4>[ 22.690880] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f >>> <4>[ 22.690882] x9 : 3c1f647968721eff x8 : ffc0877504c8 >>> <4>[ 22.690886] x7 : 09093a7c093a7c08 x6 : ff8010c4b317 >>> <4>[ 22.690888] x5 : x4 : 0040a7575000 >>> <4>[ 22.690891] x3 : ffc008ae2e28 x2 : >>> <4>[ 22.690894] x1 : x0 : >>> <4>[ 22.690896] Call trace: >>> <4>[ 22.690902] do_lttng_statedump+0xcc/0x8a8 [lttng_statedump] >>> <4>[ 22.690905] lttng_statedump_start+0x20/0x30 [lttng_statedump] >>> <4>[ 22.690981] lttng_session_enable+0xf0/0x120 [lttng_tracer
Re: [OE-core] [PATCH] lttng-modules: Check the pid_ns before using it because it may be NULL
Hi, Can we get more info on the kernel version and config? Did you submit this on our mailing list?(lttng-dev). If not I would highly recommend that you do so in the future so we can eliminate *custom* patches and get to the bottom of the issue at hand so that the whole community benefit from it. Cheers - Li Zhou wrote: > Check the pid_ns before using it because it may be NULL to fix below > issue: > <1>[ 22.637196] Unable to handle kernel NULL pointer dereference at > virtual address 0080 > <1>[ 22.645982] Mem abort info: > <1>[ 22.648769] ESR = 0x9607 > <1>[ 22.651817] Exception class = DABT (current EL), IL = 32 bits > <1>[ 22.657730] SET = 0, FnV = 0 > <1>[ 22.660777] EA = 0, S1PTW = 0 > <1>[ 22.663910] Data abort info: > <1>[ 22.666784] ISV = 0, ISS = 0x0007 > <1>[ 22.670611] CM = 0, WnR = 0 > <1>[ 22.673574] user pgtable: 4k pages, 39-bit VAs, pgdp = > 12378f78 > <1>[ 22.680180] [0080] pgd=7f023003, > pud=7f023003, pmd=7f01f003, pte= > <0>[ 22.690794] Internal error: Oops: 9607 [#1] PREEMPT SMP > <4>[ 22.690797] Modules linked in: adkNetD ncp > lttng_ring_buffer_client_overwrite(C) > lttng_ring_buffer_metadata_client(C) lttng_ring_buffer_client_discard(C) > lttng_ring_buffer_client_mmap_overwrite(C) > lttng_ring_buffer_client_mmap_discard(C) > lttng_ring_buffer_metadata_mmap_client(C) lttng_probe_signal(C) > lttng_probe_printk(C) lttng_probe_sched(C) lttng_probe_irq(C) > lttng_tracer(C) lttng_statedump(C) lttng_ftrace(C) > lttng_lib_ring_buffer(C) lttng_clock_plugin_arm_cntpct(C) lttng_clock(C) > <0>[ 22.690823] Process lttng-sessiond (pid: 3093, stack limit = > 0x5d27910f) > <4>[ 22.690828] CPU: 1 PID: 3093 Comm: lttng-sessiond Tainted: G C > 4.18.37-rt820-custom #1 > <4>[ 22.690830] Hardware name: DUS33 (CPM2-20) (DT) > <4>[ 22.690833] pstate: 6005 (nZCv daif -PAN -UAO) > <4>[ 22.690845] pc : do_lttng_statedump+0xcc/0x8a8 [lttng_statedump] > <4>[ 22.690849] lr : do_lttng_statedump+0xc4/0x8a8 [lttng_statedump] > <4>[ 22.690851] sp : ffc07fe57ad0 > <4>[ 22.690852] x29: ffc07fe57ad0 x28: ffc008ae2700 > <4>[ 22.690856] x27: ff8000724000 x26: 0001 > <4>[ 22.690859] x25: ff80089c9620 x24: > <4>[ 22.690862] x23: ffc008ae2e10 x22: ff80089d3380 > <4>[ 22.690865] x21: ffc07f45 x20: ffc008ae2700 > <4>[ 22.690869] x19: 0007 x18: fffe > <4>[ 22.690871] x17: x16: ff800824b980 > <4>[ 22.690874] x15: x14: 736162203b656e6f > <4>[ 22.690877] x13: 6e203d20676e6964 x12: > <4>[ 22.690880] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f > <4>[ 22.690882] x9 : 3c1f647968721eff x8 : ffc0877504c8 > <4>[ 22.690886] x7 : 09093a7c093a7c08 x6 : ff8010c4b317 > <4>[ 22.690888] x5 : x4 : 0040a7575000 > <4>[ 22.690891] x3 : ffc008ae2e28 x2 : > <4>[ 22.690894] x1 : x0 : > <4>[ 22.690896] Call trace: > <4>[ 22.690902] do_lttng_statedump+0xcc/0x8a8 [lttng_statedump] > <4>[ 22.690905] lttng_statedump_start+0x20/0x30 [lttng_statedump] > <4>[ 22.690981] lttng_session_enable+0xf0/0x120 [lttng_tracer] > <4>[ 22.691018] lttng_session_ioctl+0x22c/0x328 [lttng_tracer] > <4>[ 22.691026] compat_sys_ioctl+0x110/0x778 > > Signed-off-by: Li Zhou > --- > ...es-Check-the-pid_ns-before-using-it-becau.patch | 86 > ++ > meta/recipes-kernel/lttng/lttng-modules_2.11.1.bb | 2 + > 2 files changed, 88 insertions(+) > create mode 100644 > meta/recipes-kernel/lttng/lttng-modules/0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch > > diff --git > a/meta/recipes-kernel/lttng/lttng-modules/0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch > > b/meta/recipes-kernel/lttng/lttng-modules/0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch > new file mode 100644 > index 000..5306c79 > --- /dev/null > +++ > b/meta/recipes-kernel/lttng/lttng-modules/0001-lttng-modules-Check-the-pid_ns-before-using-it-becau.patch > @@ -0,0 +1,86 @@ > +From 0c0072e005ce9d591518d1819a39264859132561 Mon Sep 17 00:00:00 2001 > +From: Li Zhou > +Date: Wed, 19 Feb 2020 11:14:38 +0800 > +Subject: [PATCH] lttng-modules: Check the pid_ns before using it because it > + may be NULL > + > +<1>[ 22.637196] Unable to handle kernel NULL pointer dereference at > +virtual address 0080 > +<1>[ 22.645982] Mem abort info: > +<1>[ 22.648769] ESR = 0x9607 > +<1>[ 22.651817] Exception class = DABT (current EL), IL = 32 bits > +<1>[ 22.657730] SET = 0, FnV = 0 > +<1>[ 22.660777] EA = 0, S1PTW = 0 > +<1>[ 22.663910] Data abort info: > +<1>[ 22.666784] ISV = 0, ISS = 0x0007 > +<1>[ 22.670611] CM = 0, WnR = 0 > +<1>[ 22.673574] user pgtable: 4k pages, 39-bit VAs, pgdp = > +12378f78 > +<1>[ 22.680180] [0080] pgd=7f023003, > +pud=7f023003,
Re: [OE-core] [PATCH] lttng-modules: Check the pid_ns before using it because it may be NULL
I forwarded it to lttng-modules maintainer. I'll get back to you as soon as I get feedback. - Richard Purdie wrote: > On Thu, 2020-02-20 at 10:26 +0800, Li Zhou wrote: > > Check the pid_ns before using it because it may be NULL to fix below > > issue: > > <1>[ 22.637196] Unable to handle kernel NULL pointer dereference at > > virtual address 0080 > > <1>[ 22.645982] Mem abort info: > > <1>[ 22.648769] ESR = 0x9607 > > <1>[ 22.651817] Exception class = DABT (current EL), IL = 32 bits > > <1>[ 22.657730] SET = 0, FnV = 0 > > <1>[ 22.660777] EA = 0, S1PTW = 0 > > <1>[ 22.663910] Data abort info: > > <1>[ 22.666784] ISV = 0, ISS = 0x0007 > > <1>[ 22.670611] CM = 0, WnR = 0 > > <1>[ 22.673574] user pgtable: 4k pages, 39-bit VAs, pgdp = > > 12378f78 > > <1>[ 22.680180] [0080] pgd=7f023003, > > pud=7f023003, pmd=7f01f003, pte= > > <0>[ 22.690794] Internal error: Oops: 9607 [#1] PREEMPT SMP > > <4>[ 22.690797] Modules linked in: adkNetD ncp > > lttng_ring_buffer_client_overwrite(C) > > lttng_ring_buffer_metadata_client(C) > > lttng_ring_buffer_client_discard(C) > > lttng_ring_buffer_client_mmap_overwrite(C) > > lttng_ring_buffer_client_mmap_discard(C) > > lttng_ring_buffer_metadata_mmap_client(C) lttng_probe_signal(C) > > lttng_probe_printk(C) lttng_probe_sched(C) lttng_probe_irq(C) > > lttng_tracer(C) lttng_statedump(C) lttng_ftrace(C) > > lttng_lib_ring_buffer(C) lttng_clock_plugin_arm_cntpct(C) > > lttng_clock(C) > > <0>[ 22.690823] Process lttng-sessiond (pid: 3093, stack limit = > > 0x5d27910f) > > <4>[ 22.690828] CPU: 1 PID: 3093 Comm: lttng-sessiond Tainted: G C > > 4.18.37-rt820-custom #1 > > <4>[ 22.690830] Hardware name: DUS33 (CPM2-20) (DT) > > <4>[ 22.690833] pstate: 6005 (nZCv daif -PAN -UAO) > > <4>[ 22.690845] pc : do_lttng_statedump+0xcc/0x8a8 [lttng_statedump] > > <4>[ 22.690849] lr : do_lttng_statedump+0xc4/0x8a8 [lttng_statedump] > > <4>[ 22.690851] sp : ffc07fe57ad0 > > <4>[ 22.690852] x29: ffc07fe57ad0 x28: ffc008ae2700 > > <4>[ 22.690856] x27: ff8000724000 x26: 0001 > > <4>[ 22.690859] x25: ff80089c9620 x24: > > <4>[ 22.690862] x23: ffc008ae2e10 x22: ff80089d3380 > > <4>[ 22.690865] x21: ffc07f45 x20: ffc008ae2700 > > <4>[ 22.690869] x19: 0007 x18: fffe > > <4>[ 22.690871] x17: x16: ff800824b980 > > <4>[ 22.690874] x15: x14: 736162203b656e6f > > <4>[ 22.690877] x13: 6e203d20676e6964 x12: > > <4>[ 22.690880] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f > > <4>[ 22.690882] x9 : 3c1f647968721eff x8 : ffc0877504c8 > > <4>[ 22.690886] x7 : 09093a7c093a7c08 x6 : ff8010c4b317 > > <4>[ 22.690888] x5 : x4 : 0040a7575000 > > <4>[ 22.690891] x3 : ffc008ae2e28 x2 : > > <4>[ 22.690894] x1 : x0 : > > <4>[ 22.690896] Call trace: > > <4>[ 22.690902] do_lttng_statedump+0xcc/0x8a8 [lttng_statedump] > > <4>[ 22.690905] lttng_statedump_start+0x20/0x30 [lttng_statedump] > > <4>[ 22.690981] lttng_session_enable+0xf0/0x120 [lttng_tracer] > > <4>[ 22.691018] lttng_session_ioctl+0x22c/0x328 [lttng_tracer] > > <4>[ 22.691026] compat_sys_ioctl+0x110/0x778 > > > > Signed-off-by: Li Zhou > > Are upstream aware of this issue? I'd really like their opinion on this > before we merge anything. > > Cheers, > > Richard > > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] babeltrace2: added 2.0.1
> Let me try a different question. What is the ultimate intent here? > > Will babeltrace and babeltrace2 coexist in the future or do you plan to > rename babeltrace2 -> babeltrace at some point? We plan on deprecating Babeltrace 1.X in the long term but Babeltrace 2 and Babeltrace 1 will always co-exist. > > There are some things where the namespaces are quite specific (python > vs python3, gtk(+) 2/3/4, qt) but they're fairly few and far between. > > If babeltrace2 will replace babeltrace and become babeltrace, we > probably want to keep PN as babeltrace. If it will be known as > babeltrace2 always, we probably change PN. Babeltrace 2 executable will be forever named babeltrace2. Hope this clear up this part a bit. -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] babeltrace2: added 2.0.1
On Wed, Feb 19, 2020 at 11:06:12AM +0100, Anders Wallin wrote: > Hi Alex, > > I think it's better to use babeltrace2 since it's a new version of > babeltrace. > The dist packages uses babeltrace2 and the main application/program is > called babeltrace2. > > Jonatan; Do you have any comment on the naming? Me? Don't care much about the naming. The major issue here is the dependency for ptest of lttng-tools that depends on a "babeltrace" executable and not on the "babeltrace2" executable. Currently on our CI we create a symlink from "babeltrace2" to "babeltrace". This is something we plan on addressing shortly. Cheers -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] babeltrace: update to 1.5.8
Hi,
On Mon, Feb 17, 2020 at 12:43:43PM +0100, Alexander Kanavin wrote:
> Also, there’s now a babeltrace 2, so we should update to that rather ?
Babeltrace 1.5.x and Babeltrace 2 are "setup" to be co-installed.
Currently lttng-tools depends on babeltrace 1.5 for testing (the "babeltrace"
excutable). We plan to make the switch officialy in the upcoming months.
We recommend (upstream) that if a Babeltrace2 recipe is to be exposed that it is
done so in parallel to a Babeltrace 1.5.x recipe and that the default be
Babeltrace 1.5.x for now. AFAIK all tests from lttng-tools do pass when using
Babeltrace2 and babeltrace2 is full compatible (CLI) with babeltrace 1.5.x.
Still, we recommended that for now 1.5.x be the default.
Cheers
>
> Alex
>
> On Mon 17. Feb 2020 at 12.03, Jacob Kroon wrote:
>
> > On 2/17/20 11:59 AM, Anders Wallin wrote:
> > > updated HOMEPAGE to http://babeltrace.org/
> > > updated LICENSE to include LGPLv2.1
> > >
> > > Signed-off-by: Anders Wallin
> > > ---
> > > meta/recipes-kernel/lttng/babeltrace_1.5.8.bb | 20 +++
> > > 1 file changed, 20 insertions(+)
> > > create mode 100644 meta/recipes-kernel/lttng/babeltrace_1.5.8.bb
> > >
> > > diff --git a/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb
> > b/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb
> > > new file mode 100644
> > > index 00..b6b7653037
> > > --- /dev/null
> > > +++ b/meta/recipes-kernel/lttng/babeltrace_1.5.8.bb
> > > @@ -0,0 +1,20 @@
> > > +SUMMARY = "Babeltrace - Trace Format Babel Tower"
> > > +DESCRIPTION = "Babeltrace provides trace read and write libraries in
> > host side, as well as a trace converter, which used to convert LTTng 2.0
> > traces into human-readable log."
> > > +HOMEPAGE = "http://babeltrace.org/;
> > > +BUGTRACKER = "https://bugs.lttng.org/projects/babeltrace;
> > > +LICENSE = "MIT & GPLv2 & LGPLv2.1"
> > > +LIC_FILES_CHKSUM = "file://LICENSE;md5=76ba15dd76a248e1dd526bca0e2125fa"
> > > +
> > > +DEPENDS = "glib-2.0 util-linux popt bison-native flex-native"
> > > +
> > > +SRC_URI = "git://
> > git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-1.5"
> > > +SRCREV = "054a54ae10b01a271afc4f19496c041b10fb414c"
> > > +UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)$"
> > > +
> > > +S = "${WORKDIR}/git"
> > > +
> > > +inherit autotools pkgconfig
> > > +
> > > +EXTRA_OECONF = "--disable-debug-info"
> > > +
> > > +ASNEEDED = ""
> > >
> >
> > Looks like this patch adds a new recipe for 1.5.8, and keeps the 1.5.7
> > recipe. Was that intentional ?
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 9/9] lttng-tools: disable tests that sporadically fail
Hi,
On Mon, Jan 27, 2020 at 03:19:08PM +0100, Alexander Kanavin wrote:
> Upstream is aware, and will investigate and fix.
For reference: https://bugs.lttng.org/issues/1217
Acked-by: Jonathan Rajotte-Julien
>
> Signed-off-by: Alexander Kanavin
> ---
> ...ression-disable-the-tools-live-tests.patch | 29 +++
> .../lttng/lttng-tools_2.11.0.bb | 1 +
> 2 files changed, 30 insertions(+)
> create mode 100644
> meta/recipes-kernel/lttng/lttng-tools/0001-tests-regression-disable-the-tools-live-tests.patch
>
> diff --git
> a/meta/recipes-kernel/lttng/lttng-tools/0001-tests-regression-disable-the-tools-live-tests.patch
>
> b/meta/recipes-kernel/lttng/lttng-tools/0001-tests-regression-disable-the-tools-live-tests.patch
> new file mode 100644
> index 000..a558a0993f9
> --- /dev/null
> +++
> b/meta/recipes-kernel/lttng/lttng-tools/0001-tests-regression-disable-the-tools-live-tests.patch
> @@ -0,0 +1,29 @@
> +From 5f0ef3e007ed83c1ce7ae817308e5942decc1230 Mon Sep 17 00:00:00 2001
> +From: Alexander Kanavin
> +Date: Fri, 24 Jan 2020 18:03:25 +0100
> +Subject: [PATCH] tests/regression: disable the tools/live tests
> +
> +They have been found to sporadically fail; the issue has been
> +reported upstream and they will work to investigate and fix:
> +https://bugs.lttng.org/issues/1217
> +
> +Upstream-Status: Inappropriate [upstream is working on a real fix]
> +Signed-off-by: Alexander Kanavin
> +---
> + tests/regression/Makefile.am | 3 ---
> + 1 file changed, 3 deletions(-)
> +
> +diff --git a/tests/regression/Makefile.am b/tests/regression/Makefile.am
> +index 73eb9f7..92fc18f 100644
> +--- a/tests/regression/Makefile.am
> b/tests/regression/Makefile.am
> +@@ -9,9 +9,6 @@ TESTS = tools/filtering/test_invalid_filter \
> + tools/filtering/test_valid_filter \
> + tools/streaming/test_ust \
> + tools/health/test_thread_ok \
> +-tools/live/test_ust \
> +-tools/live/test_ust_tracefile_count \
> +-tools/live/test_lttng_ust \
> + tools/tracefile-limits/test_tracefile_count \
> + tools/tracefile-limits/test_tracefile_size \
> + tools/exclusion/test_exclusion \
> diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.11.0.bb
> b/meta/recipes-kernel/lttng/lttng-tools_2.11.0.bb
> index 639d4b62114..9cb896314b8 100644
> --- a/meta/recipes-kernel/lttng/lttng-tools_2.11.0.bb
> +++ b/meta/recipes-kernel/lttng/lttng-tools_2.11.0.bb
> @@ -33,6 +33,7 @@ SRC_URI =
> "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
> file://0001-tests-do-not-strip-a-helper-library.patch \
> file://run-ptest \
> file://lttng-sessiond.service \
> + file://0001-tests-regression-disable-the-tools-live-tests.patch \
> "
>
> SRC_URI[md5sum] = "e6c23244a36e2a09783d03a362eb63cb"
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 10/24] ptests: exclude lttng-tools
On Fri, Jan 24, 2020 at 01:47:48PM +0100, Alexander Kanavin wrote: > I have traced the failing tests to missing supplementary shell scripts that > apparently are newly added, and weren't packaged to the target. > > Also, /tmp indeed wasn't big enough. > > With those issues addressed (patch is coming), I am still having two > failures: Thanks for that effort. > > # Failed test > (../../../../../lttng-tools-2.11.0/tests/regression/tools/live/live_test.c:main() > at line 707) > # Got first packet index with offset 0 and len 4096 > not ok 6 - Get metadata, received 0 bytes > FAIL: tools/live/test_ust_tracefile_count 6 - Get metadata, received 0 bytes > > # Got first packet index with offset 0 and len 4096 > not ok 6 - Get metadata, received 0 bytes > FAIL: tools/live/test_ust 6 - Get metadata, received 0 bytes > > What's weird is that sometimes they pass. Could there be a race or some > timing issue in the test? This indeed seems suspicious. Are you able to reproduce it rather quickly? If so we can continue this in private for the instruction on the base setup so I can reproduce it and get working on it. These tests have a lot of moving parts. Cheers > > Alex > > On Mon, 20 Jan 2020 at 18:37, Jonathan Rajotte-Julien < > jonathan.rajotte-jul...@efficios.com> wrote: > > > Could you point me toward reports for the failing tests? > > > > I just want to make sure they are not actual regression. > > > > A yocto specific patch was dropped that allowed ptest to pass when > > lttng-ust is not present. This can be a source of problems. > > OE commit:015aea5d93614676decd18578a8ae2d68417cfc5 > > > > Also some tests required a minimum requirement for /tmp that could lead to > > problem for image/test setup with limited memory since AFAIK /tmp size is > > derived from the available memory (at least when using qemu test image). > > > > Cheers > > > > On Mon, Jan 20, 2020 at 06:24:56PM +0100, Alexander Kanavin wrote: > > > These tests are producing failures that appear and > > > disappear randomly. This requires investigation > > > by someone with expertise, so let's disable until then. > > > > > > Signed-off-by: Alexander Kanavin > > > --- > > > meta/conf/distro/include/ptest-packagelists.inc | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/meta/conf/distro/include/ptest-packagelists.inc > > b/meta/conf/distro/include/ptest-packagelists.inc > > > index 49cb9046c6c..f42e90bd187 100644 > > > --- a/meta/conf/distro/include/ptest-packagelists.inc > > > +++ b/meta/conf/distro/include/ptest-packagelists.inc > > > @@ -58,6 +58,7 @@ PTESTS_FAST = "\ > > > #rt-tests-ptest \ # Needs to be checked whether it runs at all > > > #bash-ptest \ # Test outcomes are non-deterministic by design > > > #mdadm-ptest \ # Multiple failures; mdmon crashes in at least one > > of the tests > > > +#lttng-tools-ptest \ # Random failures that are difficult to > > reproduce > > > #" > > > > > > PTESTS_SLOW = "\ > > > @@ -67,7 +68,6 @@ PTESTS_SLOW = "\ > > > glib-2.0-ptest \ > > > gstreamer1.0-ptest \ > > > libevent-ptest \ > > > -lttng-tools-ptest \ > > > openssh-ptest \ > > > openssl-ptest \ > > > perl-ptest \ > > > -- > > > 2.17.1 > > > > > > -- > > > ___ > > > Openembedded-core mailing list > > > Openembedded-core@lists.openembedded.org > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > -- > > Jonathan Rajotte-Julien > > EfficiOS > > -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 10/24] ptests: exclude lttng-tools
Could you point me toward reports for the failing tests? I just want to make sure they are not actual regression. A yocto specific patch was dropped that allowed ptest to pass when lttng-ust is not present. This can be a source of problems. OE commit:015aea5d93614676decd18578a8ae2d68417cfc5 Also some tests required a minimum requirement for /tmp that could lead to problem for image/test setup with limited memory since AFAIK /tmp size is derived from the available memory (at least when using qemu test image). Cheers On Mon, Jan 20, 2020 at 06:24:56PM +0100, Alexander Kanavin wrote: > These tests are producing failures that appear and > disappear randomly. This requires investigation > by someone with expertise, so let's disable until then. > > Signed-off-by: Alexander Kanavin > --- > meta/conf/distro/include/ptest-packagelists.inc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/conf/distro/include/ptest-packagelists.inc > b/meta/conf/distro/include/ptest-packagelists.inc > index 49cb9046c6c..f42e90bd187 100644 > --- a/meta/conf/distro/include/ptest-packagelists.inc > +++ b/meta/conf/distro/include/ptest-packagelists.inc > @@ -58,6 +58,7 @@ PTESTS_FAST = "\ > #rt-tests-ptest \ # Needs to be checked whether it runs at all > #bash-ptest \ # Test outcomes are non-deterministic by design > #mdadm-ptest \ # Multiple failures; mdmon crashes in at least one of the > tests > +#lttng-tools-ptest \ # Random failures that are difficult to reproduce > #" > > PTESTS_SLOW = "\ > @@ -67,7 +68,6 @@ PTESTS_SLOW = "\ > glib-2.0-ptest \ > gstreamer1.0-ptest \ > libevent-ptest \ > -lttng-tools-ptest \ > openssh-ptest \ > openssl-ptest \ > perl-ptest \ > -- > 2.17.1 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lttng-modules: fix NULL pointer deference error when testing rpc_task_running
d_create_on_node+0x110/0x110
> + [ 139.269915] [] ret_from_fork+0x7c/0xb0
> + [ 139.269915] [] ?
> kthread_create_on_node+0x110/0x110
> + [ 139.269915] Code: 4c 8b 45 c8 48 8d 7d d0 89 4d c4 41 89 c9 b9 28 00
> 00 00 e8 9d b4 e9
> + e0 48 85 c0 49 89 c5 74 a2 48 89 c7 e8 9d 3f e9 e0 48 89 c2 <41> 8b 46
> 04 48 8b 7d d0 4c
> + 89 e9 4c 89 e6 89 42 0c 0f b7 83 d4
> + [ 139.269915] RIP []
> ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
> + [ 139.269915] RSP
> + [ 139.269915] CR2: 0004
> + [ 140.946406] ---[ end trace ba486328b98d7622 ]---
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Quanyang Wang
> +---
> + instrumentation/events/lttng-module/rpc.h | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/instrumentation/events/lttng-module/rpc.h
> b/instrumentation/events/lttng-module/rpc.h
> +index 3798e8e..fb13106 100644
> +--- a/instrumentation/events/lttng-module/rpc.h
> b/instrumentation/events/lttng-module/rpc.h
> +@@ -139,7 +139,7 @@ LTTNG_TRACEPOINT_EVENT_CLASS(rpc_task_running,
> +
> + TP_FIELDS(
> + ctf_integer(unsigned int, task_id, task->tk_pid)
> +-ctf_integer(unsigned int, client_id, task->tk_client->cl_clid)
> ++ctf_integer(unsigned int, client_id, task->tk_client ?
> task->tk_client->cl_clid : -1)
> + ctf_integer_hex(const void *, action, action)
> + ctf_integer(unsigned long, runstate, task->tk_runstate)
> + ctf_integer(int, status, task->tk_status)
> +@@ -208,7 +208,7 @@ LTTNG_TRACEPOINT_EVENT_CLASS(rpc_task_running,
> +
> + TP_FIELDS(
> + ctf_integer(unsigned int, task_id, task->tk_pid)
> +-ctf_integer(unsigned int, client_id, task->tk_client->cl_clid)
> ++ctf_integer(unsigned int, client_id, task->tk_client ?
> task->tk_client->cl_clid : -1)
> + ctf_integer_hex(const void *, action, action)
> + ctf_integer(unsigned long, runstate, task->tk_runstate)
> + ctf_integer(int, status, task->tk_status)
> +--
> +2.17.1
> +
> diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.10.11.bb
> b/meta/recipes-kernel/lttng/lttng-modules_2.10.11.bb
> index c116fddc60..494b2031c1 100644
> --- a/meta/recipes-kernel/lttng/lttng-modules_2.10.11.bb
> +++ b/meta/recipes-kernel/lttng/lttng-modules_2.10.11.bb
> @@ -14,6 +14,7 @@ COMPATIBLE_HOST =
> '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm|riscv).*-linux'
> SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
> file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch
> \
> file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
> +
> file://0001-Fix-SUNRPC-Fix-oops-when-trace-sunrpc_task-events-in.patch \
> "
>
> SRC_URI[md5sum] = "c618fb646514dfc1bf910cfd7cda4256"
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lttng: babeltrace: Fix negative clock offset
Hi, This patch breaks the API of stable-1.5. It is clearly mentioned in the commit message: It introduces API-breaking changes in the C and Python APIs, since we need to be able to return negative time values, which were previously used as errors (-1ULL). You can have it in your layer but it should never be upstreamed to yocto/oe in any case for the stable 1.5 branch of babeltrace. The change you are referencing (61cf588beae752e5ddfc60b6b5310f769ac9e852) is queued to be in Babeltrace 2.0.0. Richard: as part of the lttng/babeltrace team I advice against using this patch in OE. Cheers - Original Message - > From: "zhe he" > To: "openembedded-core" > Sent: Monday, September 2, 2019 11:09:24 PM > Subject: [OE-core] [PATCH] lttng: babeltrace: Fix negative clock offset > From: He Zhe > > Backport a patch to fix negative clock offset with the following errors, when > when using lttng to view traces. > [error] ctf_clock_declaration_visit: unexpected unary expression for clock > offset > [error] ctf_visitor_construct_metadata: clock declaration error > [error] Error in CTF metadata constructor -22 > > Signed-off-by: He Zhe > --- > meta/recipes-kernel/lttng/babeltrace_1.5.7.bb | 4 +- > ...andle-negative-time-and-offset-from-Epoch.patch | 853 + > 2 files changed, 856 insertions(+), 1 deletion(-) > create mode 100644 > meta/recipes-kernel/lttng/files/0001-Handle-negative-time-and-offset-from-Epoch.patch > > diff --git a/meta/recipes-kernel/lttng/babeltrace_1.5.7.bb > b/meta/recipes-kernel/lttng/babeltrace_1.5.7.bb > index 05ef6d0..4b9343d 100644 > --- a/meta/recipes-kernel/lttng/babeltrace_1.5.7.bb > +++ b/meta/recipes-kernel/lttng/babeltrace_1.5.7.bb > @@ -7,7 +7,9 @@ LIC_FILES_CHKSUM = > "file://LICENSE;md5=76ba15dd76a248e1dd526bca0e2125fa" > > DEPENDS = "glib-2.0 util-linux popt bison-native flex-native" > > -SRC_URI = > "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-1.5" > +SRC_URI = > "git://git.linuxfoundation.org/diamon/babeltrace.git;branch=stable-1.5 \ > + file://0001-Handle-negative-time-and-offset-from-Epoch.patch \ > + " > SRCREV = "d4014aeef4b89a4aaab1af42d7b0d143d62da0ff" > UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)$" > > diff --git > a/meta/recipes-kernel/lttng/files/0001-Handle-negative-time-and-offset-from-Epoch.patch > b/meta/recipes-kernel/lttng/files/0001-Handle-negative-time-and-offset-from-Epoch.patch > new file mode 100644 > index 000..f93fea7 > --- /dev/null > +++ > b/meta/recipes-kernel/lttng/files/0001-Handle-negative-time-and-offset-from-Epoch.patch > @@ -0,0 +1,853 @@ > +From d6480f9dc6a6f6536da6c3df59006ba67ef0f622 Mon Sep 17 00:00:00 2001 > +From: Mathieu Desnoyers > +Date: Wed, 14 Aug 2019 13:24:31 +0800 > +Subject: [PATCH] Handle negative time and offset from Epoch > + > +Handle cases where a trace have a negative offset from Epoch. > +If Epoch is arbitrary (e.g. embedded system starting at 0, without any > +network access), the "0" can be used as correlation point between > +various components, and some components could start before the > +correlation point. Therefore, especially in traces where the time is > +meant to be shown in nanoseconds or cycles from the correlation point, > +it also makes sense to have a negative time value. > + > +It introduces API-breaking changes in the C and Python APIs, since we > +need to be able to return negative time values, which were previously > +used as errors (-1ULL). > + > +The --offset and --offset-ns command line parameters can now take > +negative offset (seconds and nanoseconds) values too. > + > +The [sec.ns] format is used as fallback so we don't attempt to pass > +a negative time value to POSIX time-formatting APIs. > + > +This also fixes an inaccurate return value in an error path of > +bt_ctf_event_populate_event_header(). > + > +Signed-off-by: Mathieu Desnoyers > + > +Upstream-Status: Backport[61cf588beae752e5ddfc60b6b5310f769ac9e852] > + > +Signed-off-by: He Zhe > +--- > + converter/babeltrace.c | 4 +- > + formats/ctf-text/ctf-text.c| 2 +- > + formats/ctf/ctf.c | 115 > +++-- > + formats/ctf/events-private.h | 11 +- > + formats/ctf/events.c | 11 +- > + .../ctf/metadata/ctf-visitor-generate-io-struct.c | 2 +- > + include/babeltrace/babeltrace-internal.h | 8 +- > + include/babeltrace/clock-internal.h| 2 +- > + include/babeltrace/ctf-ir/clock-internal.h | 2 +- > + include/babeltrace/ctf/events.h| 8 +- > + include/babeltrace/ctf/types.h | 6 +- > + include/babeltrace/format.h| 10 +- > + include/babeltrace/trace-handle-internal.h | 8 +- > + include/babeltrace/trace-handle.h | 25 +++-- > + lib/context.c
Re: [OE-core] [PATCH 0/5] kernel-yocto: misc build / config changes
> > FWIW: lttng-ust builds fine for me with the 5.2 kernel + 5.2 headers, > it is one of the things I build and test as part of > core-image-kernel-dev. Even on ppc? It seems related to the y2038 safe socket merge (a98dc6aee784a5daf84a4781dcf02feab9ad5999) from the kernel but from the code I cannot find a reason why SO_SNDTIMEO would be missing. The powerpc socket header relies on the generic one for proper backward definition of SO_SNDTIMEO: #define SO_SNDTIMEO (sizeof(time_t) == sizeof(__kernel_long_t) ? SO_SNDTIMEO_OLD : SO_SNDTIMEO_NEW) Not sure what is going on here. > I just rebuilt it here this morning and didn't see any errors. > > > > > > > qemuarm is erroring due to /dev/fb0 disappearing, which is probably > > > kernel? > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/975 > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/38/builds/976 > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/986 > > > > > > and we also have an unintended side effect multilib build failure: > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/995 > > > > > > which might be due to changed dependencies, I need to check into that one > > > further. > > > > > > Cheers, > > > > > > Richard > > > > > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lttng-ust:upgrade 2.10.3 -> 2.10.4
le_cpus = result;
> -+}
> -+#endif
> ---
> -2.17.1
> -
> diff --git a/meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
> b/meta/recipes-kernel/lttng/lttng-ust_2.10.4.bb
> similarity index 89%
> rename from meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
> rename to meta/recipes-kernel/lttng/lttng-ust_2.10.4.bb
> index d546104129..a8eebb223b 100644
> --- a/meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
> +++ b/meta/recipes-kernel/lttng/lttng-ust_2.10.4.bb
> @@ -27,11 +27,10 @@ PE = "2"
>
> SRC_URI = "https://lttng.org/files/lttng-ust/lttng-ust-${PV}.tar.bz2 \
> file://lttng-ust-doc-examples-disable.patch \
> -
> file://0001-compat-work-around-broken-_SC_NPROCESSORS_CONF-on-MU.patch \
>"
>
> -SRC_URI[md5sum] = "ffcfa8c1ba9a52f002d240e936e9afa2"
> -SRC_URI[sha256sum] =
> "9e8420f90d5f963f7aa32bc6d44adc1e491136f687c69ffb7a3075d33b40852b"
> +SRC_URI[md5sum] = "19916ff0dec23c90f985586a8cbd1fd2"
> +SRC_URI[sha256sum] =
> "75d5b4bb205c444a343e1297e14cd3a2503fc645a26710531cbd319c72c1a967"
>
> CVE_PRODUCT = "ust"
>
> --
> 2.20.1
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] lttng-modules: Add git based recipe
Hi,
> +BBCLASSEXTEND = "devupstream:target"
> +LIC_FILES_CHKSUM_class-devupstream =
> "file://LICENSE;md5=3f882d431dc0f32f1f44c0707aa41128"
> +DEFAULT_PREFERENCE_class-devupstream = "-1"
> +SRC_URI_class-devupstream = "git://git.lttng.org/lttng-modules;branch=master
> \
> + file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch
> \
> + file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
> + "
Please use the head of the stable release. 2.10 in this case.
> +SRCREV_class-devupstream = "${AUTOREV}"
> +PV_class-devupstream = "2.11.0-rc+git${SRCPV}"
This should be 2.10.
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1
On Wed, Jun 12, 2019 at 10:52:36AM -0400, Jonathan Rajotte-Julien wrote: > Hi, > > > > Please don't base distributions on -rc tags. They are not meant for this. > > > > > > We always integrate support for newer kernel versions instrumentation back > > > into our current stable release. So as soon as 5.2 final comes out, we > > > will > > > release a 2.10.x version including support for it in lttng-modules. > > > > I'm one of the people who need to use lttng-modules on rc kernel. > > If so, please use a git based recipe building the HEAD of the latest released > stable branch (stable-2.10 currently since 2.11 is in currently in the RC > stage). If you have problem, report them on our mailing list [1] or our bug > tracker [2]. We have extensive CI jobs for lttng-modules against the vanilla > kernel [3] and other usual suspects [4]. We normally catch those problems > quite quickly. Keep in mind that in no way should a production image be built > with a non tagged release. > > As for the oe-core recipe, please send us a quick email to let us know, patch > level releases are cheap. Keep in mind that we are chasing a moving target > here. > > To add to Mathieu statement, not only do we integrate support for newer > kernels into > the current stable branch but also in all the supported stable branch when > possible. The supported stable release are normally the 3 latest minor-level > releases. 3 -> 2 latest release. > Currently this set is : 2.8, 2.9, 2.10 . Slight correction : 2.9, 2.10 > > [1] https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > [2] https://bugs.lttng.org/ > [3] An example of such job running: > https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_master_build-vanilla/648/console > This job validate that lttng-modules master builds against the following > vanilla kernel tags. We have > similar jobs for master, stable 2.11, stable 2.10, stable 2.9, stable > 2.10 lttng-modules branch. > v3.0.101 > v3.1.10 > v3.2.102 > v3.3.8 > v3.4.113 > v3.5.7 > v3.6.11 > v3.7.10 > v3.8.13 > v3.9.11 > v3.10.108 > v3.11.10 > v3.12.74 > v3.13.11 > v3.14.79 > v3.15.10 > v3.16.68 > v3.17.8 > v3.18.140 > v3.19.8 > v4.0.9 > v4.1.52 > v4.2.8 > v4.3.6 > v4.4.181 > v4.5.7 > v4.6.7 > v4.7.10 > v4.8.17 > v4.9.181 > v4.10.17 > v4.11.12 > v4.12.14 > v4.13.16 > v4.14.125 > v4.15.18 > v4.16.18 > v4.17.19 > v4.18.20 > v4.19.50 > v4.20.17 > v5.0.21 > v5.1.9 > v5.2-rc4 > [4] https://ci.lttng.org/view/LTTng-modules/ > > -- > Jonathan Rajotte-Julien > EfficiOS -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] lttng-modules: Backport patches to fix compilation failures since kernel v5.1
Hi, > > Please don't base distributions on -rc tags. They are not meant for this. > > > > We always integrate support for newer kernel versions instrumentation back > > into our current stable release. So as soon as 5.2 final comes out, we will > > release a 2.10.x version including support for it in lttng-modules. > > I'm one of the people who need to use lttng-modules on rc kernel. If so, please use a git based recipe building the HEAD of the latest released stable branch (stable-2.10 currently since 2.11 is in currently in the RC stage). If you have problem, report them on our mailing list [1] or our bug tracker [2]. We have extensive CI jobs for lttng-modules against the vanilla kernel [3] and other usual suspects [4]. We normally catch those problems quite quickly. Keep in mind that in no way should a production image be built with a non tagged release. As for the oe-core recipe, please send us a quick email to let us know, patch level releases are cheap. Keep in mind that we are chasing a moving target here. To add to Mathieu statement, not only do we integrate support for newer kernels into the current stable branch but also in all the supported stable branch when possible. The supported stable release are normally the 3 latest minor-level releases. Currently this set is : 2.8, 2.9, 2.10 . [1] https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev [2] https://bugs.lttng.org/ [3] An example of such job running: https://ci.lttng.org/view/LTTng-modules/job/lttng-modules_master_build-vanilla/648/console This job validate that lttng-modules master builds against the following vanilla kernel tags. We have similar jobs for master, stable 2.11, stable 2.10, stable 2.9, stable 2.10 lttng-modules branch. v3.0.101 v3.1.10 v3.2.102 v3.3.8 v3.4.113 v3.5.7 v3.6.11 v3.7.10 v3.8.13 v3.9.11 v3.10.108 v3.11.10 v3.12.74 v3.13.11 v3.14.79 v3.15.10 v3.16.68 v3.17.8 v3.18.140 v3.19.8 v4.0.9 v4.1.52 v4.2.8 v4.3.6 v4.4.181 v4.5.7 v4.6.7 v4.7.10 v4.8.17 v4.9.181 v4.10.17 v4.11.12 v4.12.14 v4.13.16 v4.14.125 v4.15.18 v4.16.18 v4.17.19 v4.18.20 v4.19.50 v4.20.17 v5.0.21 v5.1.9 v5.2-rc4 [4] https://ci.lttng.org/view/LTTng-modules/ -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ptest with BBCLASSEXTEND
Hi, > I think Jonathan Rajotte might be able to help us with lttng-tools. Finally had some time for this. See [1][2]. [2] does bring the matter of forcing lttng-ust support of lttng-tools when ptest is deployed. "lttng-ust" is already set in PACKAGECONFIG by default but is there any way to "enforce" the lttng-ust config & dependency when lttng-tools-ptest is used? [1] http://lists.openembedded.org/pipermail/openembedded-core/2019-May/282733.html [2] http://lists.openembedded.org/pipermail/openembedded-core/2019-May/282734.html Cheers -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] lttng-tools: prevent test timeout when lttng-modules is not present
Clearly the actual patch is missing, sending v2 shortly.
On Wed, May 22, 2019 at 10:06:44PM +, Jonathan Rajotte wrote:
> Signed-off-by: Jonathan Rajotte
> ---
> meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> index a3fabb20ec..f1bb7224f3 100644
> --- a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> +++ b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> @@ -39,6 +39,7 @@ SRC_URI =
> "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
>
> file://0005-Tests-use-modprobe-to-test-for-the-presence-of-lttng.patch \
> file://0006-Tests-check-for-lttng-modules-presence.patch \
> file://0007-Fix-getgrnam-is-not-MT-Safe-use-getgrnam_r.patch \
> +
> file://0008-Fix-check-for-lttng-modules-presence-before-testing.patch \
> "
>
> SRC_URI[md5sum] = "e88c521b5da6bb48a8187af66ecc"
> --
> 2.17.1
>
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ptest with BBCLASSEXTEND
> Its not fast to parse this creates about 59 variants of the image. Its > (ab)using the mcextend class to an image and add the ptest to that > image for each ptest in the PTESTS_SLOW and PTESTS_FAST variables. It > also adds openssh since we need an ssh client in the images for > testimage to work. I also had to add extra space and memory to the > image config so all the tests could work. > > You can get a list of the target images with: > For the non-initiated, you will need to have the following in your local.conf for this to work. DISTRO_FEATURES_append = " ptest" That said, I should be able to take a look at the problem related to lttng-tools. Thanks -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Recipes with ptest dependency problems
On Apr 17, 2019 5:56 PM, Richard Purdie wrote:I mentioned differences in numbers of pass/fail depending on whichimage you install ptests into. The recipes which have the issues andthe numbers are:core-image-sato with ptest installed:Recipe | Passed | Failed | Skipped | diffutils| 20 | 0| 1 | elfutils | 31 | 6| 166 | flex | 0 | 0| 0 | gzip | 3 | 19 | 0 | libxml-parser-perl | 0 | 15 | 0 | lttng-tools | 3397| 626 | 1 | TDo you have a link to this run logs?nettle | 95 | 2| 2 | openssh | 0 | 0| 1 | perl | 2425| 20 | 235 | python | 304 | 6| 39| python3 | 30321 | 2| 1019 | quilt| 23 | 34 | 0 | tcl | 148 | 1| 0 | util-linux | 378 | 2| 58| valgrind | 0 | 0| 0 | core-image-sato-sdk with ptest installed:Recipe | Passed | Failed | Skipped | diffutils| 21 | 0| 0 | elfutils | 31 | 4| 168 | flex | 114 | 0| 0 | gzip | 22 | 0| 0 | libxml-parser-perl | 15 | 0| 0 | lttng-tools | 4693| 1| 412 | nettle | 96 | 1| 2 | openssh | 67 | 0| 3 | perl | 2430| 19 | 231 | python | 131 | 1| 17| python3 | 30329 | 2| 1011 | quilt| 57 | 0| 0 | tcl | 149 | 0| 0 | util-linux | 473 | 2| 52| valgrind | 297 | 251 | 31| I appreciate some of the numbers don't add up e.g. valgrind skips 0tests? or the util-linux skip counts. I cropped the time taken countsout as they confuse the diff other than to note the timeout/hang inlttng-tools.We probably need bugzilla entries for each one of these to look intoand fix the ptest package dependencies so the pass/fail counts are thesame in a core-image-sato to core-image-sato-sdk.Cheers,Richard-- ___Openembedded-core mailing listOpenembedded-core@lists.openembedded.orghttp://lists.openembedded.org/mailman/listinfo/openembedded-core-- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] gdb: Do not disable lttng-ust on risc-v
Hi Khem,
On Mon, Mar 18, 2019 at 01:11:19PM -0400, Jonathan Rajotte-Julien wrote:
> On Mon, Mar 18, 2019 at 09:58:03AM -0700, Khem Raj wrote:
> > Signed-off-by: Khem Raj
> > ---
> > meta/recipes-devtools/gdb/gdb-common.inc | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/meta/recipes-devtools/gdb/gdb-common.inc
> > b/meta/recipes-devtools/gdb/gdb-common.inc
> > index 57bc0dc773..a07625bb8d 100644
> > --- a/meta/recipes-devtools/gdb/gdb-common.inc
> > +++ b/meta/recipes-devtools/gdb/gdb-common.inc
> > @@ -6,7 +6,6 @@ DEPENDS = "expat zlib ncurses virtual/libiconv ${LTTNGUST}
> > bison-native"
> > LTTNGUST = "lttng-ust"
>
> I did not know that gdb depends on lttng-ust, I know gdb can depend on
> libbabeltrace*. I'll check that a bit more.
Gdb can indeed depend on lttng-ust for gdbserver for tracpoint.
This answer my question.
>
> Cheers.
>
> > LTTNGUST_arc = ""
> > LTTNGUST_aarch64 = ""
> > -LTTNGUST_riscv64 = ""
> > LTTNGUST_mipsarch = ""
> > LTTNGUST_sh4 = ""
> > LTTNGUST_libc-musl = ""
> > --
> > 2.21.0
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> --
> Jonathan Rajotte-Julien
> EfficiOS
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] packagegroup-core-tools-profile: Do not remove lttng-ust for musl and risc-v
On Mon, Mar 18, 2019 at 09:58:02AM -0700, Khem Raj wrote: > Signed-off-by: Khem Raj > --- > .../packagegroups/packagegroup-core-tools-profile.bb | 3 --- > 1 file changed, 3 deletions(-) > > diff --git > a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb > b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb > index 762c046636..3d8e0c2ed7 100644 > --- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb > +++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb > @@ -39,16 +39,13 @@ SYSTEMTAP_riscv64 = "" > LTTNGUST = "lttng-ust" > LTTNGUST_libc-musl = "" Looks like you missed this, based on the commit msg. > LTTNGUST_arc = "" > -LTTNGUST_riscv64 = "" > > LTTNGTOOLS = "lttng-tools" > LTTNGTOOLS_libc-musl = "" Looks like you missed this, based on the commit msg. > LTTNGTOOLS_arc = "" > -LTTNGTOOLS_riscv64 = "" > > LTTNGMODULES = "lttng-modules" > LTTNGMODULES_arc = "" > -LTTNGMODULES_riscv64 = "" > > BABELTRACE = "babeltrace" > > -- > 2.21.0 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] gdb: Do not disable lttng-ust on risc-v
On Mon, Mar 18, 2019 at 09:58:03AM -0700, Khem Raj wrote:
> Signed-off-by: Khem Raj
> ---
> meta/recipes-devtools/gdb/gdb-common.inc | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/gdb/gdb-common.inc
> b/meta/recipes-devtools/gdb/gdb-common.inc
> index 57bc0dc773..a07625bb8d 100644
> --- a/meta/recipes-devtools/gdb/gdb-common.inc
> +++ b/meta/recipes-devtools/gdb/gdb-common.inc
> @@ -6,7 +6,6 @@ DEPENDS = "expat zlib ncurses virtual/libiconv ${LTTNGUST}
> bison-native"
> LTTNGUST = "lttng-ust"
I did not know that gdb depends on lttng-ust, I know gdb can depend on
libbabeltrace*. I'll check that a bit more.
Cheers.
> LTTNGUST_arc = ""
> LTTNGUST_aarch64 = ""
> -LTTNGUST_riscv64 = ""
> LTTNGUST_mipsarch = ""
> LTTNGUST_sh4 = ""
> LTTNGUST_libc-musl = ""
> --
> 2.21.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] lttng: Enable on musl and riscv
Hi Khem,
This looks good, still please take some moment to read this thread from musl
mailing list regarding lttng-ust usage of _SC_NPROCESSORS_CONF. For now I would
maintain the disabling of lttng-ust when musl is used. I should have CC'ed you,
I forgot.
The modification for riscv64 seems good to me. We do support lttng-* for
riscv64 [2] on debian.
[1] https://www.openwall.com/lists/musl/2019/03/15/5
[2] https://packages.debian.org/sid/utils/lttng-tools
On Mon, Mar 18, 2019 at 09:58:01AM -0700, Khem Raj wrote:
> Latest version compiles on musl as well as on risv64 now
>
> Signed-off-by: Khem Raj
> ---
> meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb | 2 +-
> meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb | 2 --
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
> b/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
> index 086254d3d3..15e75e51c9 100644
> --- a/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
> +++ b/meta/recipes-kernel/lttng/lttng-modules_2.10.8.bb
> @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM =
> "file://LICENSE;md5=c4613d1f8a9587bd7b366191830364b3 \
>
> inherit module
>
> -COMPATIBLE_HOST = '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm).*-linux'
> +COMPATIBLE_HOST =
> '(x86_64|i.86|powerpc|aarch64|mips|nios2|arm|riscv).*-linux'
>
> #https://lttng.org/files/lttng-modules/lttng-modules-2.10.7.tar.bz2
> SRC_URI = "https://lttng.org/files/${BPN}/${BPN}-${PV}.tar.bz2 \
> diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> index 151e35e3c3..d544f8e206 100644
> --- a/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> +++ b/meta/recipes-kernel/lttng/lttng-tools_2.10.6.bb
> @@ -26,9 +26,7 @@ PACKAGECONFIG[python] = "--enable-python-bindings
> ${PYTHON_OPTION},,python3 swig
> PACKAGECONFIG[lttng-ust] = "--with-lttng-ust, --without-lttng-ust, lttng-ust"
> PACKAGECONFIG[kmod] = "--with-kmod, --without-kmod, kmod"
> PACKAGECONFIG[manpages] = "--enable-man-pages, --disable-man-pages,
> asciidoc-native xmlto-native libxslt-native"
> -PACKAGECONFIG_remove_libc-musl = "lttng-ust"
> PACKAGECONFIG_remove_arc = "lttng-ust"
> -PACKAGECONFIG_remove_riscv64 = "lttng-ust"
>
> SRC_URI = "https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
> file://x32.patch \
> --
> 2.21.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] lttng-tools ptest: add missing dependencies
> Since the patches with a couple of fixes were passing the tests, I've > merged the patches with the glibc/muslc tweak and also a tweak to make > disabled ust work. I'd normally wait for v2 resubmission but I wanted > to get this fix into M3 and the M3 build is already behind schedule. Sounds good. > > I was at a conference last week so a bit distracted, just catching up > now. > > > Also, I saw that lttng-ust is removed from PACKAGECONFIG when using > > musl, not sure why the commit history is not particularly verbose > > regarding why it was a problem. Still, it seems to build fine but we > > are seeing issue regarding musl. > > I think when we originally merged musl, lttng didn't build with it or > there were some kind of issues. I suspect lttng-ust still doesn't work > on all the architectures we build for so we likely need to be able to > optionally disable it. I'd be happy to see patches enabling it where it > does work though. Well lttng-ust does work on musl as long as users do not fiddle with sched_affinity... I cc'ed you on the musl thread about this [1]. [1] https://www.openwall.com/lists/musl/2019/03/15/5 For now we can leave the disable statement there. We will revisit when musl is fixed and/or when lttng-ust have a fallback (most likely to happen) when using musl. > > > > We checked with Alpine since they also use musl and see similar > > problem. I'm investigating on that front. I'll let you know what I > > find. See [1]. We also found a dynamic linker problem on our side for the notification test. We will upstream it in the following weeks. > > > > Side note, gdb simply segfault (at start) for me on a core-image- > > minirmnal build using musl. > > How would someone open the corefile generated on the build system > > with the proper libs and all? > > I saw other discussion about this so it looks like you're making > progress on this front. If not, Khem would be the person to ask about > this as our musl expert... Do you have a link to said discussion? I ended up debugging using print statement since even on Alpine gdb is "broken" (not working as expected). I'm not sure how much time I can use on this. Will let you know if any progress is made to at least get a backtrace for the gdb coredump. Thanks again! -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] lttng-tools ptest: add missing dependencies
> Firstly, I wanted to say thanks for looking at this, there are some
> really great fixes in here.
>
> It failed in automated testing as glibc-utils is glibc specific and
> musl builds couldn't cope with that.
>
> We can certainly do:
>
> RDEPENDS_${PN}-ptest_append_libc-glibc = " glibc-utils"
Sure, since we mostly need getconf from glibc-utils, we can use musl-utils
to provide it when building with musl.
RDEPENDS_${PN}-ptest_append_libc-musl = " musl-utils"
Also, I saw that lttng-ust is removed from PACKAGECONFIG when using musl, not
sure why the commit history is not particularly verbose regarding why it was a
problem. Still, it seems to build fine but we are seeing issue regarding musl.
We checked with Alpine since they also use musl and see similar problem. I'm
investigating on that front. I'll let you know what I find.
Side note, gdb simply segfault (at start) for me on a core-image-minirmnal
build using musl.
How would someone open the corefile generated on the build system with the
proper libs and all?
Thanks!
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][Thud][PATCH 1/3] lttng-ust: update to 2.10.3
> > Disregard this series. It does not follow the project guideline regarding > > recipe > > update for stable release. > There are exceptions when a package update is a bugfix only change. I > know the kernel, openssl, bind, curl and a few others fall into that > category. Many minor version updates tend to be bug fix only but that > all depends on the upstream project policies. Binutils does not follow > that scheme as they add features in minor version updates. This is what > I know from personal experience. What helps the project along with the > maintainer is having a brief summary of the changes in the commit > message. I am at the mercy of commit message. I get that. I assumed that most project are *sane* and stick to something similar to SemVer. Sorry for that. We follow SemVer [1] for the following projects: Babeltrace LTTng-tools LTTng-ust LTTng-modules userspace-rcu This series contains only PATCH level update (MAJOR.MINOR.PATCH). You will note that the lttng-tools recipes was not updated to the 2.10.x release in this series. Side note, as a project (lttng) we recommend that lttng-tools and lttng-ust be upgraded in lockstep (MINOR == MINOR). But since we also conform to SemVer there is no problem using an older MINOR version of lttng-tools with a newer MINOR version of lttng-ust. The other way around is not recommended and will simply not build most of the time. lttng-modules is *special* since we fix thing to allow support of newer kernel as time goes by. Again, we do not add features across PATCH level release. Still, I think I understand a bit more the constraint oe-core and yocto stable branch are facing and would not mind if the recipes stay at the version they are now. [1] https://semver.org/ > > Can you confirm this is bug fix only update? > Yes it is. Cheers -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][Sumo][PATCH 1/3] lttng-ust: update to 2.10.3
Confusion on my end, disregard this series and the following [1] [2].
[1]
http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280107.html
[2]
http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280110.html
As for the confusion more info here [3].
[3]
http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280112.html
Cheers
On Wed, Mar 13, 2019 at 04:08:42PM -0700, akuster808 wrote:
>
>
> On 3/13/19 1:53 PM, Jonathan Rajotte wrote:
> > Signed-off-by: Jonathan Rajotte
>
> please provide more info on the update. is this fixing something? is it
> a bug fix only release?
>
> - armin
> > ---
> > .../lttng/{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}| 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> > rename meta/recipes-kernel/lttng/{lttng-ust_2.10.1.bb =>
> > lttng-ust_2.10.3.bb} (90%)
> >
> > diff --git a/meta/recipes-kernel/lttng/lttng-ust_2.10.1.bb
> > b/meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
> > similarity index 90%
> > rename from meta/recipes-kernel/lttng/lttng-ust_2.10.1.bb
> > rename to meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
> > index d79a47931c..b5c43200d6 100644
> > --- a/meta/recipes-kernel/lttng/lttng-ust_2.10.1.bb
> > +++ b/meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
> > @@ -23,8 +23,8 @@ PE = "2"
> > SRC_URI = "https://lttng.org/files/lttng-ust/lttng-ust-${PV}.tar.bz2 \
> > file://lttng-ust-doc-examples-disable.patch \
> >"
> > -SRC_URI[md5sum] = "4863cc2f9f0a070b42438bb646bbba06"
> > -SRC_URI[sha256sum] =
> > "07cc3c0b71e7b77f1913d5b7f340a78a9af414440e4662712aef2d635b88ee9d"
> > +SRC_URI[md5sum] = "ffcfa8c1ba9a52f002d240e936e9afa2"
> > +SRC_URI[sha256sum] =
> > "9e8420f90d5f963f7aa32bc6d44adc1e491136f687c69ffb7a3075d33b40852b"
> >
> > CVE_PRODUCT = "ust"
> >
>
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][Thud][PATCH 1/3] lttng-ust: update to 2.10.3
Hi,
Disregard this series. It does not follow the project guideline regarding recipe
update for stable release.
Thanks
On Wed, Mar 13, 2019 at 08:55:53PM +, Jonathan Rajotte wrote:
> Signed-off-by: Jonathan Rajotte
> ---
> .../lttng/{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}| 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-kernel/lttng/{lttng-ust_2.10.1.bb =>
> lttng-ust_2.10.3.bb} (90%)
>
> diff --git a/meta/recipes-kernel/lttng/lttng-ust_2.10.1.bb
> b/meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
> similarity index 90%
> rename from meta/recipes-kernel/lttng/lttng-ust_2.10.1.bb
> rename to meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
> index d79a47931c..b5c43200d6 100644
> --- a/meta/recipes-kernel/lttng/lttng-ust_2.10.1.bb
> +++ b/meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
> @@ -23,8 +23,8 @@ PE = "2"
> SRC_URI = "https://lttng.org/files/lttng-ust/lttng-ust-${PV}.tar.bz2 \
> file://lttng-ust-doc-examples-disable.patch \
>"
> -SRC_URI[md5sum] = "4863cc2f9f0a070b42438bb646bbba06"
> -SRC_URI[sha256sum] =
> "07cc3c0b71e7b77f1913d5b7f340a78a9af414440e4662712aef2d635b88ee9d"
> +SRC_URI[md5sum] = "ffcfa8c1ba9a52f002d240e936e9afa2"
> +SRC_URI[sha256sum] =
> "9e8420f90d5f963f7aa32bc6d44adc1e491136f687c69ffb7a3075d33b40852b"
>
> CVE_PRODUCT = "ust"
>
> --
> 2.17.1
>
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][Sumo][PATCH] babeltrace: update to 1.5.6
Hi,
Disregard this patch. It does not follow the project guideline regarding recipe
update for stable release.
Thanks,
On Wed, Mar 13, 2019 at 09:30:08PM +, Jonathan Rajotte wrote:
> Signed-off-by: Jonathan Rajotte
> ---
> .../lttng/{babeltrace_1.5.4.bb => babeltrace_1.5.6.bb}| 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> rename meta/recipes-kernel/lttng/{babeltrace_1.5.4.bb =>
> babeltrace_1.5.6.bb} (82%)
>
> diff --git a/meta/recipes-kernel/lttng/babeltrace_1.5.4.bb
> b/meta/recipes-kernel/lttng/babeltrace_1.5.6.bb
> similarity index 82%
> rename from meta/recipes-kernel/lttng/babeltrace_1.5.4.bb
> rename to meta/recipes-kernel/lttng/babeltrace_1.5.6.bb
> index a29402adb1..254b5f652a 100644
> --- a/meta/recipes-kernel/lttng/babeltrace_1.5.4.bb
> +++ b/meta/recipes-kernel/lttng/babeltrace_1.5.6.bb
> @@ -15,5 +15,5 @@ SRC_URI =
> "http://www.efficios.com/files/babeltrace/babeltrace-${PV}.tar.bz2 \
>
> EXTRA_OECONF = "--disable-debug-info"
>
> -SRC_URI[md5sum] = "3e8cdafec3ac0346a389870e87bf1344"
> -SRC_URI[sha256sum] =
> "9643039923a0abc75a25b3d594cee0017423b57f10d2b625e96ed1e8d4891fc1"
> +SRC_URI[md5sum] = "8ce610461e73f48b9c6beec9ba95dcc3"
> +SRC_URI[sha256sum] =
> "5308bc217828dd571b3259f482a85533554064d4563906ff3c5774ecf915bbb7"
> --
> 2.17.1
>
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-Core][Sumo][PATCH 1/3] lttng-ust: update to 2.10.3
On Wed, Mar 13, 2019 at 09:55:04PM +, Burton, Ross wrote:
> You need a *very* good reason to upgrade in stable releases, so please
> explain the rationale.
Yeah we got good reason, these are bugfix stable release, as a project we would
like our user to experience a good experience out-of-the box when using yocto.
More seriously, I simply skipped this part of the wiki...
...
No recipe upgrades unless:
The old version is completely broken
The new version contains a security patch or other critical bugfix that
is too difficult to
backport to the version already in the stable branch
...
Sorry for the noise. These patches are "useless". I'll make sure to nack the
other series.
Still the modules update might be interesting to cover more kernel but at the
same time if the default kernels are also "frozen" there is not point in
updating.
I guess the yocto/bitbake way to ensure our user get the latest stablest is to
provide a meta-lttng layers and instruct them to use it.
Again sorry for the noise.
Cheers
>
> Ross
>
> On Wed, 13 Mar 2019 at 20:54, Jonathan Rajotte
> wrote:
> >
> > Signed-off-by: Jonathan Rajotte
> > ---
> > .../lttng/{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}| 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> > rename meta/recipes-kernel/lttng/{lttng-ust_2.10.1.bb =>
> > lttng-ust_2.10.3.bb} (90%)
> >
> > diff --git a/meta/recipes-kernel/lttng/lttng-ust_2.10.1.bb
> > b/meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
> > similarity index 90%
> > rename from meta/recipes-kernel/lttng/lttng-ust_2.10.1.bb
> > rename to meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
> > index d79a47931c..b5c43200d6 100644
> > --- a/meta/recipes-kernel/lttng/lttng-ust_2.10.1.bb
> > +++ b/meta/recipes-kernel/lttng/lttng-ust_2.10.3.bb
> > @@ -23,8 +23,8 @@ PE = "2"
> > SRC_URI = "https://lttng.org/files/lttng-ust/lttng-ust-${PV}.tar.bz2 \
> > file://lttng-ust-doc-examples-disable.patch \
> >"
> > -SRC_URI[md5sum] = "4863cc2f9f0a070b42438bb646bbba06"
> > -SRC_URI[sha256sum] =
> > "07cc3c0b71e7b77f1913d5b7f340a78a9af414440e4662712aef2d635b88ee9d"
> > +SRC_URI[md5sum] = "ffcfa8c1ba9a52f002d240e936e9afa2"
> > +SRC_URI[sha256sum] =
> > "9e8420f90d5f963f7aa32bc6d44adc1e491136f687c69ffb7a3075d33b40852b"
> >
> > CVE_PRODUCT = "ust"
> >
> > --
> > 2.17.1
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/6] lttng: add 5.x fixup patches to 2.10.8 release
Hi Bruce, We just release LTTng-modules 2.10.9 that should remove the need for most if not all of this patches. Could you try it out? Cheers -- Jonathan Rajotte-Julien EfficiOS -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] glibc: add ld.so locks in _libc_fork
[ Not Author See bugzilla]
> +
> +Signed-off-by: Damodar Sonone
> +Signed-off-by: Yuanjie Huang
> +---
> + sysdeps/nptl/fork.c | 3 ++-
> + 1 file changed, 2 insertions(+), 1 deletion(-)
> +
> +diff --git a/sysdeps/nptl/fork.c b/sysdeps/nptl/fork.c
> +index 2b9ae4b..3d0b8da 100644
> +--- a/sysdeps/nptl/fork.c
> b/sysdeps/nptl/fork.c
> +@@ -174,8 +174,9 @@ __libc_fork (void)
> + /* Reset locks in the I/O code. */
> + _IO_list_resetlock ();
> +
> +- /* Reset the lock the dynamic loader uses to protect its data. */
> ++ /* Reset the locks the dynamic loader uses to protect its data. */
> + __rtld_lock_initialize (GL(dl_load_lock));
> ++ __rtld_lock_initialize (GL(dl_load_write_lock));
> +
> + /* Run the handlers registered for the child. */
> + while (allp != NULL)
> +--
> +1.9.1
> diff --git
> a/meta/recipes-core/glibc/glibc/0028-Bug-4578-add-ld.so-lock-while-fork.patch
> b/meta/recipes-core/glibc/glibc/0028-Bug-4578-add-ld.so-lock-while-fork.patch
> new file mode 100644
> index 000..f76237a
> --- /dev/null
> +++
> b/meta/recipes-core/glibc/glibc/0028-Bug-4578-add-ld.so-lock-while-fork.patch
> @@ -0,0 +1,57 @@
> +The patch in this Bugzilla entry was requested by a customer:
> + https://sourceware.org/bugzilla/show_bug.cgi?id=4578
> +
> +If a thread happens to hold dl_load_lock and have r_state set to RT_ADD or
> +RT_DELETE at the time another thread calls fork(), then the child exit code
> +from fork (in nptl/sysdeps/unix/sysv/linux/fork.c in our case) re-initializes
> +dl_load_lock but does not restore r_state to RT_CONSISTENT. If the child
> +subsequently requires ld.so functionality before calling exec(), then the
> +assertion will fire.
> +
> +The patch acquires dl_load_lock on entry to fork() and releases it on exit
> +from the parent path. The child path is initialized as currently done.
> +This is essentially pthreads_atfork, but forced to be first because the
> +acquisition of dl_load_lock must happen before malloc_atfork is active
> +to avoid a deadlock.
> +The patch has not yet been integrated upstream.
> +
> +Upstream-Status: Pending [ Not Author See bugzilla]
> +
> +Signed-off-by: Raghunath Lolur
> +Signed-off-by: Yuanjie Huang
> +Signed-off-by: Zhixiong Chi
> +
> +Index: git/sysdeps/nptl/fork.c
> +===
> +--- git.orig/sysdeps/nptl/fork.c 2017-08-03 16:02:15.674704080 +0800
> git/sysdeps/nptl/fork.c2017-08-04 18:15:02.463362015 +0800
> +@@ -25,6 +25,7 @@
> + #include
> + #include
> + #include
> ++#include
> + #include
> + #include
> + #include
> +@@ -60,6 +61,10 @@
> + but our current fork implementation is not. */
> + bool multiple_threads = THREAD_GETMEM (THREAD_SELF,
> header.multiple_threads);
> +
> ++ /* grab ld.so lock BEFORE switching to malloc_atfork */
> ++ __rtld_lock_lock_recursive (GL(dl_load_lock));
> ++ __rtld_lock_lock_recursive (GL(dl_load_write_lock));
> ++
> + /* Run all the registered preparation handlers. In reverse order.
> + While doing this we build up a list of all the entries. */
> + struct fork_handler *runp;
> +@@ -247,6 +252,10 @@
> +
> + allp = allp->next;
> + }
> ++
> ++ /* unlock ld.so last, because we locked it first */
> ++ __rtld_lock_unlock_recursive (GL(dl_load_write_lock));
> ++ __rtld_lock_unlock_recursive (GL(dl_load_lock));
> + }
> +
> + return pid;
> diff --git a/meta/recipes-core/glibc/glibc_2.26.bb
> b/meta/recipes-core/glibc/glibc_2.26.bb
> index d453d8f..135ec4f 100644
> --- a/meta/recipes-core/glibc/glibc_2.26.bb
> +++ b/meta/recipes-core/glibc/glibc_2.26.bb
> @@ -41,6 +41,8 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
>
> file://0024-elf-dl-deps.c-Make-_dl_build_local_scope-breadth-fir.patch \
> file://0025-locale-fix-hard-coded-reference-to-gcc-E.patch \
>
> file://0026-assert-Suppress-pedantic-warning-caused-by-statement.patch \
> + file://0027-glibc-reset-dl-load-write-lock-after-forking.patch \
> + file://0028-Bug-4578-add-ld.so-lock-while-fork.patch \
> "
>
> NATIVESDKFIXES ?= ""
--
Jonathan Rajotte-Julien
EfficiOS
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Babeltrace - Backport fix to fido (as-needed.inc: add babeltrace exception)
Hi, Reposting to mailing list since I was not allowed without a subscription. Both Alexander Kanavin (Babeltrace recipe maintainer) and Richard Purdie were CC on the initial message. Original Message -- Hi, The following commit [1] is present since Jethro but the issue is also present in Fido. Since the commit apply cleanly, could it be possible to backport it to Fido? Cheers [1] http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=3006cb260004a7bd88cfd4ea3e2cbcac600347bc -- Jonathan R. Julien Efficios -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
