Test case ID : https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=319 Please find the logs : pankajsx@andromeda02:/data/pankajsx/2.6M1.RC1/poky/build$ crosstap root@192.168.7.4 trace_open.stp WARNING: cannot find module kernel debuginfo: No DWARF information found [man warning::debuginfo] logs at Qemu target: [ 991.809597] stap_d5fb6880184e693d95a69a3af202fd39_5_321: loading out-of-tree module traints kernel. Debug Information at Qemu target: Output of lsmod command : Tainted: G stap_d5fb6880184e693d95a69a3af202fd39_5_321 61440 2 - Live 0xffffffffc011c000 (0) vvesafb 28672 1 - Live 0xffffffffc0114000
While Regression, I am unable to see this issue with below mentioned cofiguration : Branch: master Build name: yocto-2.5_M1.rc1 poky commit: b73e96e7f3f5d1ba3a221d99792a7a3c7ef42c21 Architecture : x86-64
Does the test work other than showing a WARNING or are there other issues as well?
With 2.6_M1.RC1 : I don't see "crosstap" has related output on host machine with WARNING message. With 2.5_M1.RC1 (regression with previous build): I see "crosstap" has related output on host machine but with WARNING message.
The question appears to have been answered, if not put it back into NEEDINFO.
Regression with 2.5_M4.RC1 : I don't see "crosstap" has related output on host machine with WARNING message.
I am able to see this issue with below mentioned configuration : Build name: yocto-2.6M2.rc1 poky commit: b0f2f690a3513e4c9fa30fee1b8d7ac2d7140657 Architecture : x86-64
It seems it is another instance of non-bug also reported as [YOCTO #12974] https://bugzilla.yoctoproject.org/show_bug.cgi?id=12974. In short it seems that some output was expected from SystemTap script but since nothing in the system uses 'open' system call none of output was produced. Please look at 'Comment 2 of YOCTO #12974' https://bugzilla.yoctoproject.org/show_bug.cgi?id=12974#c2 for more details. Please note I am guessing that trace_open.stp script has the same content as it was reported in [YOCTO #12974]. To be 100% sure it is the case I put this PR in NEEDINFO state. Upon response if it is the same trace_open.stp script please consider putting this PR into RESOLVED state INVALID resolution based on the same rational as it was explained in [YOCTO #12974]
@Victor, we checked the behavior by testing with 2.6.1 rc1 release. The behavior is the same as what is described in the bug 12974. Moving the status of the bug to the RESOLVED state. Thanks for the explanation.