Created attachment 3789 [details] crosstap.log Git rev: morty/d05941ae4567def4a288894717e5f550da246107 This bug is cloned from bug 10990 which already fixed in 2.3 branch. The patch http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=3f0037ce3c49ecc98c486ebf90844a4db4976b14 wasn't merged into morty branch. But after I cherry-picked it to morty manually, I got the following error: /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build In file included from /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build/tmp/sysroots/x86_64-linux/usr/share/systemtap/runtime/linux/runtime.h:209:0, from /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build/tmp/sysroots/x86_64-linux/usr/share/systemtap/runtime/runtime.h:24, from /tmp/stap0AR0YD/trace_open_src.c:25: /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build/tmp/sysroots/x86_64-linux/usr/share/systemtap/runtime/linux/access_process_vm.h: In function '__access_process_vm_': /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build/tmp/sysroots/x86_64-linux/usr/share/systemtap/runtime/linux/access_process_vm.h:35:29: error: passing argument 1 of 'get_user_pages' makes integer from pointer without a cast [-Werror=int-conversion] ret = get_user_pages (tsk, mm, addr, 1, write, 1, &page, &vma); ^~~ In file included from /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build/tmp/work-shared/qemuarm/kernel-source/include/linux/pid_namespace.h:6:0, from /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build/tmp/work-shared/qemuarm/kernel-source/include/linux/ptrace.h:8, from /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build/tmp/work-shared/qemuarm/kernel-source/include/linux/ftrace.h:13, from /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build/tmp/work-shared/qemuarm/kernel-source/include/linux/kprobes.h:42, from /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build/tmp/sysroots/x86_64-linux/usr/share/systemtap/runtime/linux/runtime.h:21, from /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build/tmp/sysroots/x86_64-linux/usr/share/systemtap/runtime/runtime.h:24, from /tmp/stap0AR0YD/trace_open_src.c:25: /buildarea/jenkins-yocto/workspace/Yocto2.2-kernel_module_compilation_crosstap/build/tmp/work-shared/qemuarm/kernel-source/include/linux/mm.h:1315:6: note: expected 'long unsigned int' but argument is of type 'struct task_struct *' long get_user_pages(unsigned long start, unsigned long nr_pages, ^~~~~~~~~~~~~~ The full error log is attached. I never encountered this error before. I suspect maybe the current systemtap 3.0 doesn't support kernel 4.8 ?
according to https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=summary 4.8 support happened after the 3.0 release. they bumped kernel support with commit https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commit;h=7d27ff5084d61a6f8c4843e934f666ed07832c30 6 months after 3.0 Linux version 4.4 seems to be the oldest kernel version support in 3.0 according to the release notes https://sourceware.org/ml/systemtap/2016-q1/msg00179.html = Examples of tested kernel versions 2.6.18 (RHEL 5 x86 and x86_64) 2.6.32 (RHEL 6 x86 and x86_64) 3.10.0 (RHEL 7 x86_64) 4.1.6 (Fedora 22 x86_64) 4.3.4 (Fedora 22 x86_64) 4.6.0-rc0 (Fedora rawhide x86_64) 3.1 supports = Examples of tested kernel versions 2.6.18 (RHEL 5 x86 and x86_64) 2.6.32 (RHEL 6 x86 and x86_64) 3.10.0 (RHEL 7 x86_64) 4.1.6 (Fedora 22 x86_64) 4.3.4 (Fedora 22 x86_64) 4.6.0-rc0 (Fedora rawhide x86_64) 4.6.0-rc6 (Fedora rawhide x86_64) 4.8.10-200 (Fedora 24 x86_64) 4.10.0-rc0 (Fedora rawhide x86_64) 4.10.0-rc6 (Fedora rawhide x86_64) 4.10.0-rc8 (Fedora rawhide x86_64)
I am leaning toward "invalid" configuration on a 4.8 kernel
Sounds like we might want to update to 3.1 in the next respin of 2.2.2?
(In reply to comment #3) > Sounds like we might want to update to 3.1 in the next respin of 2.2.2? can do. will do a dry run to see if its brings in more issues than what it may be fixing.
I backported the update from pyro
update sitting in akuster/morty-next http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/meta/recipes-kernel/systemtap?h=akuster/morty-next&id=8974fd4709336b532369b084fd8c803647af289a
code in motry. need to retest http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=morty&id=604b2b2c6c0a9c09098fccf958c94ea7ba8b082b
Verified with 2.2.2 rc2. Git rev: morty/60402978fe3648bf560b3386c6e9dd661cdf2083