stime01 from ubuntu_ltp_syscalls failed on D Power9

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1845620

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Issue found on D-KVM (5.0.0-1021.22-kvm)

 startup='Wed Oct 23 14:17:20 2019'
 tst_test.c:1137: INFO: Timeout per run is 0h 05m 00s
 stime_var.h:45: INFO: Testing libc stime()
 stime01.c:51: FAIL: system time not set to 1571840270 (got: 1571840240)
 tst_test.c:1137: INFO: Timeout per run is 0h 05m 00s
 stime_var.h:48: INFO: Testing SYS_stime syscall
 stime_var.h:27: CONF: syscall(-1) __NR_stime not supported
 tst_test.c:1137: INFO: Timeout per run is 0h 05m 00s
 stime_var.h:51: INFO: Testing SYS_settimeofday syscall
 stime01.c:46: INFO: pt.tv_sec: 1571840270
 stime01.c:47: PASS: system time was set to 1571840270

 Summary:
 passed 1
 failed 1
 skipped 0
 warnings 0

This issue can be found on B-GKE-5.0

but all 2 tests were failed:
 startup='Sat Nov 30 01:03:14 2019'
 tst_test.c:1217: INFO: Timeout per run is 0h 05m 00s
 stime_var.h:45: INFO: Testing libc stime()
 stime01.c:51: FAIL: system time not set to 1575075824 (got: 1575075794)
 tst_test.c:1217: INFO: Timeout per run is 0h 05m 00s
 stime_var.h:48: INFO: Testing SYS_stime syscall
 stime_var.h:27: CONF: syscall(-1) __NR_stime not supported
 tst_test.c:1217: INFO: Timeout per run is 0h 05m 00s
 stime_var.h:51: INFO: Testing SYS_settimeofday syscall
 stime01.c:51: FAIL: system time not set to 1575075824 (got: 1575075794)

 Summary:
 passed 0
 failed 2
 skipped 0
 warnings 0

Can be found on Eoan generic (5.3.0-25.27) P9 as well. This issue was not spotted on Eoan P8.

Not sure why I couldn't reproduce it on my amd64, but this does not fail after I stop systemd-timesyncd. Well, you managed to find it on GKE, which is not ppc64el, so good enough.

stime and settimeofday should not be fiddling with hwclock, only system time. Maybe we should stop systemd-timesync for anything that has time in it?

Cascardo.

Sounds like a good plan, please feel free to sent out the patch for ACT (or even better, to the upstream LTP project!)

Thanks

Well, we were already doing it on autotest-client-tests side, so I sent a patch that sfeole "acked", but didn't apply. So, I just applied it. Please, watch if future runs are still broken anyhow.

I have the patch tested on Power9 node "baltar" with Disco kernel (5.0.0-37).
It's still failing with this stime01 test.

 startup='Wed Dec 25 10:25:31 2019'
 tst_test.c:1217: INFO: Timeout per run is 0h 05m 00s
 stime_var.h:45: INFO: Testing libc stime()
 stime01.c:46: INFO: pt.tv_sec: 1577269561
 stime01.c:47: PASS: system time was set to 1577269561
 tst_test.c:1217: INFO: Timeout per run is 0h 05m 00s
 stime_var.h:48: INFO: Testing SYS_stime syscall
 stime01.c:51: FAIL: system time not set to 1577269591 (got: 1577269531)
 tst_test.c:1217: INFO: Timeout per run is 0h 05m 00s
 stime_var.h:51: INFO: Testing SYS_settimeofday syscall
 stime01.c:46: INFO: pt.tv_sec: 1577269561
 stime01.c:47: PASS: system time was set to 1577269561

 Summary:
 passed 2
 failed 1
 skipped 0
 warnings 0

Do you have a link to the entire result?

Cascardo.

Found out that we needed to fix how to verify the lines, so I pushed such a fix.

With the new patch landed, a manual test on Power9 shows positive result on stime01.
I think this can be closed now.
(Please feel free to re-open it if you still seeing this somewhere else)
Thanks!