Repository navigation
Timers::oneshot() not reliable? #2356
Description
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 trueWhich 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.
Activity
fwsGonzo commentedon Nov 1, 2025
During startup the APIC timer resolution is being calculated using the PIT timer, which has a known frequency. It might be related.
mazunki commentedon Nov 2, 2025
Interesting. Any ideas on how to confirm that's the issue?
torgeiru commentedon Nov 3, 2025
Personally didn't have any issue with this,
Here is a exhibit from osdev about the oneshot mode:
Could you please demo the issue here? What does the failure look like? Is it an assert failure?
mazunki commentedon Nov 8, 2025
@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 commentedon Nov 9, 2025
I was unable to reproduce and I used the script you provided to run test multiple times.