Browse Source
There was an edge case in the timeout handling (exposed by, but not strictly related to, the recent timeslice fix): the next_timeout() computation would include time slice expiration as a clamp on the result, but this would be invoked also on the z_set_timeout_expiry() path which gets hooked on entry to a new thread which is needed to set the timeout in the first place. So if no other timer interrupt was scheduled, it was possible to miss the first timeslice interrupt after thread scheduling. The explanation is much longer than the fix (use <= as the comparator instead of <). In practice this was only being hit in the existing test suite on riscv miv running under renode using non-default clock rates. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>pull/31792/head
1 changed files with 1 additions and 1 deletions
Loading…
Reference in new issue