Bug 639338
| Summary: | s390x kernel read faults in several testsuite testcases | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Petr Muller <pmuller> |
| Component: | systemtap | Assignee: | Frank Ch. Eigler <fche> |
| Status: | CLOSED ERRATA | QA Contact: | qe-baseos-tools-bugs |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.1 | CC: | dsmith, mjw, ohudlick, phan, wcohen |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | s390x | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | systemtap-1.7-1.el6 | Doc Type: | Bug Fix |
| Doc Text: |
SystemTap support code for the s390x architecture had custom deref()
and store_deref() functions in the runtime library to safely access
memory. These functions did not properly handle memory accesses and
would cause a number of testsuite tests to fail on the s390x
architecture. The SystemTap runtime was modified to use the kernel
version of those functions for all architectures. The SystemTap tests
now pass as expected on the s390x architecture.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-20 13:32:39 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Petr Muller
2010-10-01 13:45:11 UTC
The fails in sdt.exp manifests in systemtap.log as these failed expects: executing: stap /usr/share/systemtap/testsuite/systemtap.base/sdt.stp sdt.c.exe.0 -c ./sdt.c.exe.0 FAIL: sdt "" uprobe line 1: expected "1" Got "ERROR: kernel read fault at 0x000003ffffba8f9c (addr) near identifier '$arg1' at /usr/share/systemtap/testsuite/systemtap.base/sdt.stp:3:18" sdt_misc.exp seems to fail because of the same issue and externalvar.exp too: cmd output: ERROR: kernel read fault at 0x0000000080001c38 (addr) near identifier '$exevar_c' at /usr/share/systemtap/testsuite/systemtap.base/externalvar.stp:3:29 This one has 6.1.0? so we should probably decide what to do with this bug/RFE. The original issue still holds for RHEL6.1 candidate systemtap. Shall me move this to 6.2, close this for good, or is here a change this could still go in? After lots of debugging, it looks like this is most likely a symptom of sourceware.org pr12341 (deref()/store_deref() variations between arches). Basically, the s390x version of systemtap's deref() macro uses custom assembly language, which no longer works well under RHEL6. Resetting for RHEL6.3; upstream work still in progress. This has been fixed in current upstream systemtap git: Host: Linux ibm-z10-34.rhts.eng.bos.redhat.com 2.6.32-220.el6.s390x #1 SMP Wed Nov 9 08:20:08 EST 2011 s390x s390x s390x GNU/Linux Snapshot: version 1.7/0.152 commit release-1.6-573-g3128c0b GCC: 4.4.6 [gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)] Distro: Red Hat Enterprise Linux Server release 6.2 (Santiago) Running /root/systemtap/testsuite/systemtap.base/sdt.exp ... === systemtap Summary === # of expected passes 88 # of expected failures 8 This was part of a series of patches to make systemtap work better on s390x, including separating runtime access of user and kernel addresses. When systemtap 1.7 gets released and has been tested a bit more we can look into doing a rebase.
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:
SystemTap support code for the s390x architecture had custom deref()
and store_deref() functions in the runtime library to safely access
memory. These functions did not properly handle memory accesses and
would cause a number of testsuite tests to fail on the s390x
architecture. The SystemTap runtime was modified to use the kernel
version of those functions for all architectures. The SystemTap tests
now pass as expected on the s390x architecture.
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-2012-0820.html |