sched: Add max delay tick limitation for wdog/wqueue.

[Fix-Point]

Summary

This PR fixes bugs in the wqueue and wdog modules. When delay is the maximum ticks (CLOCK_MAX >> 1) or SCLOCK_MAX, If there are expired wdog timer in the wdog queue, clock_compare might be incorrect.

E.g. Current tick is 123, and there is an expired wdog timer with the expired ticks 100. If we insert a wdog timer with delay CLOCK_MAX >> 1, where the absolute ticks is 123 + CLOCK_MAX >> 1, then clock_compare(100, 123 + CLOCK_MAX >> 1) will return false, leading to the new wdog timer queued before the expired wdog timer.

So we limited the delay ticks to CLOCK_MAX >> 2, which is $2^{30}-1$ or $2^{62}-1$. Assume all expired wdog timer can be processed within WDOG_MAX_DELAY ticks after the expiration, this ensure the correct enqueue of the wdog timer.

Besides, this PR changed the semantic of the wd_start. So we should also change the wdog_test. See apache/nuttx-apps#3076.

Impact

This PR affects the wqueue and wdog modules, especially the semantic of the wd_start.

Testing

Tested on QEMU/x86_64, sim and QEMU/riscv32.

[jlaitine]

Hm. I am experiencing an assertion in the test on rv-virt:smp, with updated nuttx-apps and this PR still:

[CPU1] Assertion failed : at file: wdog.c:312 task(CPU1): ostest process: ostest 0x80011b46

Perhaps check what happens in the test when interval -1 is passed as an argument to wd_start... ?

[Fix-Point]

Hm. I am experiencing an assertion in the test on rv-virt:smp, with updated nuttx-apps and this PR still:

[CPU1] Assertion failed : at file: wdog.c:312 task(CPU1): ostest process: ostest 0x80011b46

Perhaps check what happens in the test when interval -1 is passed as an argument to wd_start... ?

Rebased the PR and tested with the latest nuttx-apps(a5709532577ff0b3276a78bc8d278e8bf8a1b037). It works fine for me.

[jlaitine]

Yes, I can confirm that it now works, I had a messed-up environment myself.

[xiaoxiang781216]

@Fix-Point why ci still fail?