The /systemtap.stress/conversions.exp test fails on ia64. the tests works for 0xffffffff. Below is the related part of the systemtap.log: exp conversions.stp 0xffffffffffffffff 0 ERROR: kernel long copy fault at 0xffffffffffffffff near identifier 'kernel_long' at /home/wcohen/stap_snap_200705231431/src/testsuite/systemtap.stress/conversions.stp:6:22 ERROR: kernel int copy fault at 0xffffffffffffffff near identifier 'kernel_int' at /home/wcohen/stap_snap_200705231431/src/testsuite/systemtap.stress/conversions.stp:7:22 ERROR: kernel short copy fault at 0xffffffffffffffff near identifier 'kernel_short' at /home/wcohen/stap_snap_200705231431/src/testsuite/systemtap.stress/conversions.stp:8:22 ERROR: kernel int copy fault at 0xffffffffffffffff near identifier 'kernel_int' at /home/wcohen/stap_snap_200705231431/src/testsuite/systemtap.stress/conversions.stp:10:22 WARNING: user string copy fault -14 at ffffffffffffffff 0<unknown><only suspected, not known><unknown><unknown> WARNING: Number of errors: 4, skipped probes: 0 done exp conversions.stp 0xffffffffffffffff 6 FAIL: conversions.stp 0xffffffffffffffff (6) done conversions.stp 0xffffffffffffffff 6 The test above seems to be missing the failures for: ERROR: kernel string copy fault ERROR: kernel char copy fault Page 149 of the "ia64 linux kernel", figure 4.11 shows that address mapping, 0xffffffffffffffff is a valid byte address. Might need to reconsider how this tests picks the addresses.
We already have customizations of that test for s390x. Think of something similar for ia64.
Put in test for ia64 in conversion.exp to use an address that is falls in region 5 if on ia64 machine.
Will put in the ia64 check, and it's been passing in weekly tests since then...
Test testsuite/.../conversions.exp currently fails on arm target with this output: FAIL: conversions.stp 0xffffffff (6) FAIL: conversions.stp 0xffffffffffffffff (6) This test depends on architecture-specific memory addressing conventions. There is no special treatment for ARM in this case. ps: This bug is the same as bug #4121.
Let's use a new ARM-specific bug for this. Please suggest a known-invalid address range if you can.