From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCh v2] clock_gettime04: print more info to help debugging
Date: Tue, 9 Mar 2021 12:52:34 +0100 [thread overview]
Message-ID: <YEdhgvXg/mYkppz6@pevik> (raw)
In-Reply-To: <20210309094525.4ggmppfpvavsvjzl@vireshk-i7>
Hi Li, Viresh,
> On 09-03-21, 08:00, Li Wang wrote:
> > We catch some sporadically failures[1] like below, but we don't know which
> > test loop it comes from. So adding more prints to help locate issue.
> > tst_test.c:1286: TINFO: Timeout per run is 0h 05m 00s
> > vdso_helpers.c:76: TINFO: Couldn't find vdso_gettime64()
> > clock_gettime04.c:157: TPASS: CLOCK_REALTIME: Difference between successive readings is reasonable
> > clock_gettime04.c:150: TFAIL: CLOCK_REALTIME_COARSE: Difference between successive readings greater than 5 ms (1): 8
> > clock_gettime04.c:157: TPASS: CLOCK_MONOTONIC: Difference between successive readings is reasonable
> > clock_gettime04.c:150: TFAIL: CLOCK_MONOTONIC_COARSE: Difference between successive readings greater than 5 ms (0): 5
> > clock_gettime04.c:157: TPASS: CLOCK_MONOTONIC_RAW: Difference between successive readings is reasonable
> > clock_gettime04.c:157: TPASS: CLOCK_BOOTTIME: Difference between successive readings is reasonable
> > After patching, it will show more details about the iteration:
> > tst_test.c:1288: TINFO: Timeout per run is 0h 05m 00s
> > vdso_helpers.c:76: TINFO: Couldn't find vdso_gettime64()
> > clock_gettime04.c:158: TPASS: CLOCK_REALTIME: Difference between successive readings is reasonable for following variants:
> > clock_gettime04.c:162: TINFO: - vDSO or syscall with libc spec
> > clock_gettime04.c:162: TINFO: - syscall with old kernel spec
> > clock_gettime04.c:162: TINFO: - vDSO with old kernel spec
> > clock_gettime04.c:162: TINFO: - gettimeofday
> > clock_gettime04.c:158: TPASS: CLOCK_REALTIME_COARSE: Difference between successive readings is reasonable for following variants:
> > clock_gettime04.c:162: TINFO: - vDSO or syscall with libc spec
> > clock_gettime04.c:162: TINFO: - syscall with old kernel spec
> > clock_gettime04.c:162: TINFO: - vDSO with old kernel spec
> > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC: Difference between successive readings is reasonable for following variants:
> > clock_gettime04.c:162: TINFO: - vDSO or syscall with libc spec
> > clock_gettime04.c:162: TINFO: - syscall with old kernel spec
> > clock_gettime04.c:162: TINFO: - vDSO with old kernel spec
> > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC_COARSE: Difference between successive readings is reasonable for following variants:
> > clock_gettime04.c:162: TINFO: - vDSO or syscall with libc spec
> > clock_gettime04.c:162: TINFO: - syscall with old kernel spec
> > clock_gettime04.c:162: TINFO: - vDSO with old kernel spec
> > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC_RAW: Difference between successive readings is reasonable for following variants:
> > clock_gettime04.c:162: TINFO: - vDSO or syscall with libc spec
> > clock_gettime04.c:162: TINFO: - syscall with old kernel spec
> > clock_gettime04.c:162: TINFO: - vDSO with old kernel spec
> > clock_gettime04.c:158: TPASS: CLOCK_BOOTTIME: Difference between successive readings is reasonable for following variants:
> > clock_gettime04.c:162: TINFO: - vDSO or syscall with libc spec
> > clock_gettime04.c:162: TINFO: - syscall with old kernel spec
> > clock_gettime04.c:162: TINFO: - vDSO with old kernel spec
Sorry for putting my opinion late. Instead of repeating variants (duplicity)
I'd prefer just print variants once at the beginning + print which variant
failed.
BTW Some time ago I planned to print test variants in the library,
so it does not have to be copy pasted in every test which uses variants.
Variants could deserve some code optimisation anyway.
Kind regards,
Petr
next prev parent reply other threads:[~2021-03-09 11:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-09 8:00 [LTP] [PATCh v2] clock_gettime04: print more info to help debugging Li Wang
2021-03-09 9:45 ` Viresh Kumar
2021-03-09 11:52 ` Petr Vorel [this message]
2021-03-09 11:56 ` Viresh Kumar
2021-03-10 8:34 ` Li Wang
2021-03-10 8:43 ` Viresh Kumar
2021-03-10 10:11 ` Petr Vorel
2021-03-10 12:12 ` Li Wang
2021-03-10 13:11 ` Petr Vorel
2021-03-10 13:32 ` Li Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YEdhgvXg/mYkppz6@pevik \
--to=pvorel@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.