Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Cause
The --remote did not use the proper canonical names for the i686, ppc,
and s390x.
Consequence
SystemTap stap command would fail to build instrumentation
when the --remote options was used for i686, ppc, and s390x.
Fix
Systemtap fixed the session code to properly copy kernel/arch
information and avoid using implicit behavior for the --remote option.
Result
SystemTap stap command builds instrumentation
when the --remote options is for i686, ppc, and s390x.
Description of problem:
On these three architectures, --remote option fails to build the module:
i386:
# stap --remote root@$SERVERS -v ktest.stp
Pass 1: parsed user script and 73 library script(s) using 22164virt/13260res/2360shr kb, in 230usr/10sys/248real ms.
Pass 2: analyzed script: 5 probe(s), 2 function(s), 22 embed(s), 0 global(s) using 186220virt/28748res/3276shr kb, in 2020usr/870sys/3052real ms.
Pass 3: translated to C into "/tmp/stapixgULV/stap_5c411d06ef31bf575341f3fb8ab2b89e_13901.c" using 186220virt/32680res/7200shr kb, in 960usr/20sys/981real ms.
Makefile:558: /usr/src/kernels/2.6.32-131.0.15.el6.i686/arch/i686/Makefile: No such file or directory
make: *** No rule to make target `/usr/src/kernels/2.6.32-131.0.15.el6.i686/arch/i686/Makefile'. Stop.
Pass 4: compiled C into "stap_5c411d06ef31bf575341f3fb8ab2b89e_13901.ko" in 90usr/40sys/124real ms.
Pass 4: compilation failed. Try again with another '--vp 0001' option.
Segmentation fault (core dumped)
Indeed, there is no i686 directory in /usr/src/kernels/v-r/arch:
# ls /usr/src/kernels/2.6.32-131.0.15.el6.i686/arch/
alpha cris Kconfig microblaze powerpc sparc
arm frv m32r mips s390 um
avr32 h8300 m68k mn10300 score x86
blackfin ia64 m68knommu parisc sh xtensa
ppc:
# stap --remote root@$SERVERS -v ktest.stp
Pass 1: parsed user script and 73 library script(s) using 39168virt/31232res/9088shr kb, in 260usr/10sys/274real ms.
semantic error: ELF machine powerpc| (code 21) mismatch with target ppc64 in '/usr/lib/debug/lib/modules/2.6.32-131.0.15.el6.ppc64/vmlinux'
semantic error: no match while resolving probe point syscall.fcntl
Pass 2: analyzed script: 3 probe(s), 6 function(s), 0 embed(s), 0 global(s) using 146496virt/32960res/9920shr kb, in 10usr/0sys/32real ms.
Pass 2: analysis failed. Try again with another '--vp 01' option.
Segmentation fault (core dumped)
s390x:
# stap --remote root@$SERVERS -v ktest.stp
Pass 1: parsed user script and 73 library script(s) using 31552virt/21696res/2952shr kb, in 180usr/10sys/195real ms.
semantic error: ELF machine s390| (code 22) mismatch with target s390x in '/usr/lib/debug/lib/modules/2.6.32-131.0.15.el6.s390x/vmlinux'
semantic error: no match while resolving probe point syscall.fcntl
Pass 2: analyzed script: 3 probe(s), 6 function(s), 0 embed(s), 0 global(s) using 105964virt/22992res/3492shr kb, in 10usr/0sys/8real ms.
Pass 2: analysis failed. Try again with another '--vp 01' option.
Segmentation fault (core dumped)
Version-Release number of selected component (if applicable):
systemtap-debuginfo-1.4-6.el6_1.2
How reproducible:
seems always
Actual results:
failure to compile a stap kernel module
Expected results:
everything works, as on x86_64
Additional info:
- In all cases, SERVERS contained a valid --remote target: identical kernel{,-devel} packages and systemtap-runtime version, and accesible by ssh.
- Does not happen on x86_64
- Also, this seems to be fixed in current upstream systemtap. Filing this bug so
we can track if it is fixed in 6.2.
- The segmentation fault is filed as separate bug 723536
The same commit abc15290 which fixed the SEGV probably also fixed this bug, because it also makes sure that we normalize the remote target arch to match what the kernel build and ELF checks are expecting.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause
The --remote did not use the proper canonical names for the i686, ppc,
and s390x.
Consequence
SystemTap stap command would fail to build instrumentation
when the --remote options was for i686, ppc, and s390x.
Fix
Systemtap fixed the session code to properly copy kernel/arch
information and avoid using implicit behavior for the --remote option.
Result
SystemTap stap command builds instrumentation
when the --remote options is for i686, ppc, and s390x.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents:
@@ -3,7 +3,7 @@
and s390x.
Consequence
SystemTap stap command would fail to build instrumentation
- when the --remote options was for i686, ppc, and s390x.
+ when the --remote options was used for i686, ppc, and s390x.
Fix
Systemtap fixed the session code to properly copy kernel/arch
information and avoid using implicit behavior for the --remote option.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2011-1517.html
Description of problem: On these three architectures, --remote option fails to build the module: i386: # stap --remote root@$SERVERS -v ktest.stp Pass 1: parsed user script and 73 library script(s) using 22164virt/13260res/2360shr kb, in 230usr/10sys/248real ms. Pass 2: analyzed script: 5 probe(s), 2 function(s), 22 embed(s), 0 global(s) using 186220virt/28748res/3276shr kb, in 2020usr/870sys/3052real ms. Pass 3: translated to C into "/tmp/stapixgULV/stap_5c411d06ef31bf575341f3fb8ab2b89e_13901.c" using 186220virt/32680res/7200shr kb, in 960usr/20sys/981real ms. Makefile:558: /usr/src/kernels/2.6.32-131.0.15.el6.i686/arch/i686/Makefile: No such file or directory make: *** No rule to make target `/usr/src/kernels/2.6.32-131.0.15.el6.i686/arch/i686/Makefile'. Stop. Pass 4: compiled C into "stap_5c411d06ef31bf575341f3fb8ab2b89e_13901.ko" in 90usr/40sys/124real ms. Pass 4: compilation failed. Try again with another '--vp 0001' option. Segmentation fault (core dumped) Indeed, there is no i686 directory in /usr/src/kernels/v-r/arch: # ls /usr/src/kernels/2.6.32-131.0.15.el6.i686/arch/ alpha cris Kconfig microblaze powerpc sparc arm frv m32r mips s390 um avr32 h8300 m68k mn10300 score x86 blackfin ia64 m68knommu parisc sh xtensa ppc: # stap --remote root@$SERVERS -v ktest.stp Pass 1: parsed user script and 73 library script(s) using 39168virt/31232res/9088shr kb, in 260usr/10sys/274real ms. semantic error: ELF machine powerpc| (code 21) mismatch with target ppc64 in '/usr/lib/debug/lib/modules/2.6.32-131.0.15.el6.ppc64/vmlinux' semantic error: no match while resolving probe point syscall.fcntl Pass 2: analyzed script: 3 probe(s), 6 function(s), 0 embed(s), 0 global(s) using 146496virt/32960res/9920shr kb, in 10usr/0sys/32real ms. Pass 2: analysis failed. Try again with another '--vp 01' option. Segmentation fault (core dumped) s390x: # stap --remote root@$SERVERS -v ktest.stp Pass 1: parsed user script and 73 library script(s) using 31552virt/21696res/2952shr kb, in 180usr/10sys/195real ms. semantic error: ELF machine s390| (code 22) mismatch with target s390x in '/usr/lib/debug/lib/modules/2.6.32-131.0.15.el6.s390x/vmlinux' semantic error: no match while resolving probe point syscall.fcntl Pass 2: analyzed script: 3 probe(s), 6 function(s), 0 embed(s), 0 global(s) using 105964virt/22992res/3492shr kb, in 10usr/0sys/8real ms. Pass 2: analysis failed. Try again with another '--vp 01' option. Segmentation fault (core dumped) Version-Release number of selected component (if applicable): systemtap-debuginfo-1.4-6.el6_1.2 How reproducible: seems always Actual results: failure to compile a stap kernel module Expected results: everything works, as on x86_64 Additional info: - In all cases, SERVERS contained a valid --remote target: identical kernel{,-devel} packages and systemtap-runtime version, and accesible by ssh. - Does not happen on x86_64 - Also, this seems to be fixed in current upstream systemtap. Filing this bug so we can track if it is fixed in 6.2. - The segmentation fault is filed as separate bug 723536