[LTP] [PATCh v2] clock_gettime04: print more info to help debugging

[LTP] [PATCh v2] clock_gettime04: print more info to help debugging

[Li Wang]

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

[1] it occurs on a x86_64 (not virtualized) with kernel 5.11.0.

Signed-off-by: Li Wang <liwang@redhat.com>
---
 .../kernel/syscalls/clock_gettime/clock_gettime04.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/testcases/kernel/syscalls/clock_gettime/clock_gettime04.c b/testcases/kernel/syscalls/clock_gettime/clock_gettime04.c
index 5f8264cc6..4a395f394 100644
--- a/testcases/kernel/syscalls/clock_gettime/clock_gettime04.c
+++ b/testcases/kernel/syscalls/clock_gettime/clock_gettime04.c
@@ -147,15 +147,20 @@ static void run(unsigned int i)
 			diff /= 1000000;
 
 			if (diff >= delta) {
-				tst_res(TFAIL, "%s: Difference between successive readings greater than %lld ms (%d): %lld",
-					tst_clock_name(clks[i]), delta, j, diff);
+				tst_res(TFAIL, "%s(%s): Difference between successive readings greater than %lld ms (%d): %lld",
+					tst_clock_name(clks[i]), tv->desc, delta, j, diff);
 				return;
 			}
 		}
 	} while (--count);
 
-	tst_res(TPASS, "%s: Difference between successive readings is reasonable",
-		tst_clock_name(clks[i]));
+	tst_res(TPASS, "%s: Difference between successive readings is reasonable for following variants:",
+			tst_clock_name(clks[i]));
+	for (j = 0; j < ARRAY_SIZE(variants); j++) {
+		if (variants[j].clock_gettime == my_gettimeofday && clks[i] != CLOCK_REALTIME)
+			continue;
+		tst_res(TINFO, "\t- %s", variants[j].desc);
+	}
 }
 
 static struct tst_test test = {
-- 
2.21.3

[LTP] [PATCh v2] clock_gettime04: print more info to help debugging

[Viresh Kumar]

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
> 
> [1] it occurs on a x86_64 (not virtualized) with kernel 5.11.0.
> 
> Signed-off-by: Li Wang <liwang@redhat.com>
> ---
>  .../kernel/syscalls/clock_gettime/clock_gettime04.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

[LTP] [PATCh v2] clock_gettime04: print more info to help debugging

[Petr Vorel]

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

[LTP] [PATCh v2] clock_gettime04: print more info to help debugging

[Viresh Kumar]

On 09-03-21, 12:52, Petr Vorel wrote:
> 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.

I too thought about that, but then realized that the variant list
isn't same for all the clocks, like gettimeofday only there for
CLOCK_REALTIME and so let it go.

-- 
viresh

[LTP] [PATCh v2] clock_gettime04: print more info to help debugging

[Li Wang]

Viresh Kumar <viresh.kumar@linaro.org> wrote:

> ...
> > > >   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.
>
> I too thought about that, but then realized that the variant list
> isn't same for all the clocks, like gettimeofday only there for
> CLOCK_REALTIME and so let it go.
>

But we can put the printing behind the 'gettimeofday+CLOCK_REALTIME'
checking.
Just similar to what I did in patch V1, is that your mean, Petr?

--- a/testcases/kernel/syscalls/clock_gettime/clock_gettime04.c
+++ b/testcases/kernel/syscalls/clock_gettime/clock_gettime04.c
@@ -108,6 +108,9 @@ static void run(unsigned int i)
                        if (tv->clock_gettime == my_gettimeofday && clks[i]
!= CLOCK_REALTIME)
                                continue;

+                       if (count == 10000)
+                                tst_res(TINFO, "\t- %s", tv->desc);
+
                        ret = tv->clock_gettime(clks[i], tst_ts_get(&ts));
                        if (ret) {
                                /*
@@ -139,8 +142,8 @@ static void run(unsigned int i)

                        diff = end + slack - start;
                        if (diff < 0) {
-                               tst_res(TFAIL, "%s: Time travelled
backwards (%d): %lld ns",
-                                       tst_clock_name(clks[i]), j, diff);
+                               tst_res(TFAIL, "%s(%s): Time travelled
backwards (%d): %lld ns",
+                                       tst_clock_name(clks[i]), tv->desc,
j, diff);
                                return;
                        }



-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210310/52a86054/attachment.htm>

[LTP] [PATCh v2] clock_gettime04: print more info to help debugging

[Viresh Kumar]

On 10-03-21, 16:34, Li Wang wrote:
> But we can put the printing behind the 'gettimeofday+CLOCK_REALTIME'
> checking.
> Just similar to what I did in patch V1, is that your mean, Petr?
> 
> --- a/testcases/kernel/syscalls/clock_gettime/clock_gettime04.c
> +++ b/testcases/kernel/syscalls/clock_gettime/clock_gettime04.c
> @@ -108,6 +108,9 @@ static void run(unsigned int i)
>                         if (tv->clock_gettime == my_gettimeofday && clks[i]
> != CLOCK_REALTIME)
>                                 continue;
> 
> +                       if (count == 10000)
> +                                tst_res(TINFO, "\t- %s", tv->desc);
> +
>                         ret = tv->clock_gettime(clks[i], tst_ts_get(&ts));
>                         if (ret) {
>                                 /*
> @@ -139,8 +142,8 @@ static void run(unsigned int i)
> 
>                         diff = end + slack - start;
>                         if (diff < 0) {
> -                               tst_res(TFAIL, "%s: Time travelled
> backwards (%d): %lld ns",
> -                                       tst_clock_name(clks[i]), j, diff);
> +                               tst_res(TFAIL, "%s(%s): Time travelled
> backwards (%d): %lld ns",
> +                                       tst_clock_name(clks[i]), tv->desc,
> j, diff);
>                                 return;
>                         }

I think it would be worth keeping it simple then and just print all
variants only once from setup(). Leave the special case of REALTIME
clock.

-- 
viresh

[LTP] [PATCh v2] clock_gettime04: print more info to help debugging

[Petr Vorel]

Hi Li, Viresh, Cyril,

> On 10-03-21, 16:34, Li Wang wrote:
> > But we can put the printing behind the 'gettimeofday+CLOCK_REALTIME'
> > checking.
> > Just similar to what I did in patch V1, is that your mean, Petr?

> > --- a/testcases/kernel/syscalls/clock_gettime/clock_gettime04.c
> > +++ b/testcases/kernel/syscalls/clock_gettime/clock_gettime04.c
> > @@ -108,6 +108,9 @@ static void run(unsigned int i)
> >                         if (tv->clock_gettime == my_gettimeofday && clks[i]
> > != CLOCK_REALTIME)
> >                                 continue;

> > +                       if (count == 10000)
> > +                                tst_res(TINFO, "\t- %s", tv->desc);
> > +
> >                         ret = tv->clock_gettime(clks[i], tst_ts_get(&ts));
> >                         if (ret) {
> >                                 /*
> > @@ -139,8 +142,8 @@ static void run(unsigned int i)

> >                         diff = end + slack - start;
> >                         if (diff < 0) {
> > -                               tst_res(TFAIL, "%s: Time travelled
> > backwards (%d): %lld ns",
> > -                                       tst_clock_name(clks[i]), j, diff);
> > +                               tst_res(TFAIL, "%s(%s): Time travelled
> > backwards (%d): %lld ns",
> > +                                       tst_clock_name(clks[i]), tv->desc,
> > j, diff);
> >                                 return;
> >                         }

> I think it would be worth keeping it simple then and just print all
> variants only once from setup(). Leave the special case of REALTIME
> clock.
+1.

From a long term, I'd like some easy solution when printing would be handled in
the library. Some time ago I posted a patch which turned .test_variants from int
into array of string description [1]. Cyril didn't see much value at it and
didn't like that it introduced more ifdefs (together with Viresh).
But now we have docparse, could we reconsider this approach? Maybe we could keep
.test_variants and introduce .test_variants_desc for tests which are simple enough.
Or, maybe there is a cleaner solution for clock_adjtime0* tests which I don't
see.

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/patch/20200519120725.25750-1-pvorel@suse.cz/

[LTP] [PATCh v2] clock_gettime04: print more info to help debugging

[Li Wang]

Hi Petr,

Petr Vorel <pvorel@suse.cz> wrote:

...
>
> > I think it would be worth keeping it simple then and just print all
> > variants only once from setup(). Leave the special case of REALTIME
> > clock.
> +1.
>
> From a long term, I'd like some easy solution when printing would be
> handled in
> the library. Some time ago I posted a patch which turned .test_variants
> from int
> into array of string description [1]. Cyril didn't see much value at it and
>

I look back at patch[1], IMHO, splitting the test variant struct is not a
good idea.
I'd rather go print variants[i].desc in the library directly but not split
it to make
struct here and there :).


> didn't like that it introduced more ifdefs (together with Viresh).
> But now we have docparse, could we reconsider this approach? Maybe we
> could keep
> .test_variants and introduce .test_variants_desc for tests which are
> simple enough.
> Or, maybe there is a cleaner solution for clock_adjtime0* tests which I
> don't
> see.
>

Maybe there is.  We can have more time to thinking/discussing this.

So, would you mind if I merge this V2 patch first?

(Since we're encountering a sporadical(we can't reproduce it manually)
failure. Hope this can print more useful info to locate the issue.)


>
> Kind regards,
> Petr
>
> [1]
> https://patchwork.ozlabs.org/project/ltp/patch/20200519120725.25750-1-pvorel@suse.cz/
>
>

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210310/57019987/attachment.htm>

[LTP] [PATCh v2] clock_gettime04: print more info to help debugging

[Petr Vorel]

Hi Li,

> > From a long term, I'd like some easy solution when printing would be
> > handled in
> > the library. Some time ago I posted a patch which turned .test_variants
> > from int
> > into array of string description [1]. Cyril didn't see much value at it and

> I look back at patch[1], IMHO, splitting the test variant struct is not a
> good idea.
> I'd rather go print variants[i].desc in the library directly but not split
> it to make
> struct here and there :).
Thanks a lot for having a look. Make sense, I'll try to send v2 soon.

> > didn't like that it introduced more ifdefs (together with Viresh).
> > But now we have docparse, could we reconsider this approach? Maybe we
> > could keep
> > .test_variants and introduce .test_variants_desc for tests which are
> > simple enough.
> > Or, maybe there is a cleaner solution for clock_adjtime0* tests which I
> > don't
> > see.


> Maybe there is.  We can have more time to thinking/discussing this.

> So, would you mind if I merge this V2 patch first?

> (Since we're encountering a sporadical(we can't reproduce it manually)
> failure. Hope this can print more useful info to locate the issue.)

Although I'd slightly prefer if it printed everything once in the setup, it's
not important and we've already spent quite a lot of time with it, so sure,
go ahead :)

Reviewed-by: Petr Vorel <pvorel@suse.cz>

Kind regards,
Petr

[LTP] [PATCh v2] clock_gettime04: print more info to help debugging

[Li Wang]

Petr Vorel <pvorel@suse.cz> wrote:

...
>
> > So, would you mind if I merge this V2 patch first?
>
> > (Since we're encountering a sporadical(we can't reproduce it manually)
> > failure. Hope this can print more useful info to locate the issue.)
>
> Although I'd slightly prefer if it printed everything once in the setup,
> it's
> not important and we've already spent quite a lot of time with it, so sure,
> go ahead :)
>
> Reviewed-by: Petr Vorel <pvorel@suse.cz>
>

Thank you so much, Petr!  Merged.


-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210310/55890a8b/attachment.htm>