When M-mode and U-mode tasks execute concurrently, the log output exhibits a temporally regressive pattern. Iteration counts from M-mode tasks jump forward, then retroactively fill in earlier values. Meanwhile, U-mode iteration counts remain strictly monotonic.
The following snippet from privilege_switch, which is introduced in PR #32, test output illustrates this behavior:
[M-mode] iteration 16253
...
[M-mode] iteration 16260
[U-mode] iteration 497
[M-mode] iteration 16292 ← jumps forward
...
[M-mode] iteration 16253 ← fills in earlier values
Notably, the total message count remains correct—only the display order is affected. This suggests the underlying execution is sound, but the I/O path introduces ordering anomalies when mixing privilege modes.
This behavior makes it difficult to trace concurrent M-mode and U-mode interactions through logs, as the temporal sequence does not reflect actual execution order.
Related Issues:
When M-mode and U-mode tasks execute concurrently, the log output exhibits a temporally regressive pattern. Iteration counts from M-mode tasks jump forward, then retroactively fill in earlier values. Meanwhile, U-mode iteration counts remain strictly monotonic.
The following snippet from privilege_switch, which is introduced in PR #32, test output illustrates this behavior:
Notably, the total message count remains correct—only the display order is affected. This suggests the underlying execution is sound, but the I/O path introduces ordering anomalies when mixing privilege modes.
This behavior makes it difficult to trace concurrent M-mode and U-mode interactions through logs, as the temporal sequence does not reflect actual execution order.
Related Issues:
sys_tputsthrough unboundedNOSCHEDblocking #65