Timers::oneshot() not reliable?

[mazunki]

The integration test for kernel/block is flaky on my end. Since it was failing for me a few times I decided to test it:

#!/bin/sh
# repeat-test.sh
count=$1; shift

run() {
  if "$@"; then ok=$((ok + 1))
  else err=$((err + 1))
  fi
}

echo "running test ${count} times: $*"

ok=0; err=0
while [ "$count" -gt 0 ]; do
  count=$((count - 1))
  run "$@" >/dev/null 2>/dev/null
done

printf "summary:\n  ok=%d\n  err=%d\n" "${ok}" "${err}"

./repeat-test.sh 100 \
  nix-build ./unikernel.nix \
    --argstr unikernel ./test/integration/kernel/block \
    --check \
    --arg doCheck true

Which reports 2 failures. I didn't dig too deep into the source of the fault, but the test does call Timers::oneshot() => Timers::periodic(). When it fails, it fails on the very first iteration of the test too from what I have observed (could be a coincidence).

@MagnusS Introducing a way to repeat tests to detect these sporadic failures is probably a good idea.

[fwsGonzo]

During startup the APIC timer resolution is being calculated using the PIT timer, which has a known frequency. It might be related.

[mazunki]

Interesting. Any ideas on how to confirm that's the issue?

[torgeiru]

Personally didn't have any issue with this,

Here is a exhibit from osdev about the oneshot mode:

The disadvantages are that it's harder to track real-time with one-shot mode and special care
needs to be taken to avoid race conditions; especially if a new count is set before the old count expires. 

Could you please demo the issue here? What does the failure look like? Is it an assert failure?

[mazunki]

@torgeiru It just times out, from what I've seen. I'd have to find a reproducible to spawn the bug to tell with certainty where and when it fails. Were you unable to reproduce it through repeated testing as I did?

[torgeiru]

I was unable to reproduce and I used the script you provided to run test multiple times.