https://bugzilla.kernel.org/show_bug.cgi?id=217516 vkuznets@xxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bonzini@xxxxxxx, | |vkuznets@xxxxxxxxxx --- Comment #4 from vkuznets@xxxxxxxxxx --- It seems this is just an unstable test. It merges the divergence between MSR based clock and TSC page over one second and then expects delta to stay within the measured range over another two seconds. This works well for a completely idle system but if tasks get scheduled out, rescheduled to a different CPU,... the test fails. Widening the range help, e.g.: diff --git a/x86/hyperv_clock.c b/x86/hyperv_clock.c index f1e7204a8ea9..57d25770a2d0 100644 --- a/x86/hyperv_clock.c +++ b/x86/hyperv_clock.c @@ -79,7 +79,7 @@ static void hv_clock_test(void *data) min_delta = delta < min_delta ? delta : min_delta; if (t < msr_sample) { max_delta = delta > max_delta ? delta: max_delta; - } else if (delta < 0 || delta > max_delta * 3 / 2) { + } else if (delta < 0 || delta > max_delta * 1024) { printf("suspecting drift on CPU %d? delta = %d, acceptable [0, %d)\n", smp_id(), delta, max_delta); ok[i] = false; but I wouldn't be surprised if on a busy system even '1024 * max_delta' is not going to be sufficient. Maybe we should make this a warning and not fail the whole test as I don't see how we can make it reliable. Paolo (as you're the author), wdyt? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
