maxikrie opened a new pull request, #20934:
URL: https://github.com/apache/nuttx/pull/20934
## Summary
* Why: in non-alarm tickless mode (`CONFIG_SCHED_TICKLESS=y`,
`CONFIG_SCHED_TICKLESS_ALARM=n`), a watchdog deadline that has already
passed is handed to the timer as a negative delay, which the generic
timer path turns into a very long timeout.
* What: `wd_timer_start()` in `sched/wdog/wdog.h`.
* How: `wd_timer_start()` called `up_timer_tick_start(next_tick - now)`.
The next deadline can already be past when the timer is re-armed: an
absolute tick in the past given to `wd_start_abstick()`, or watchdog
callbacks that ran past the next expiry. The generic
`up_timer_tick_start()` in `drivers/timers/arch_timer.c` passes the
delay to `update_timeout()`, which takes a `uint32_t`, so -1 tick becomes
`0xffffffff` ticks. The timer is set as far ahead as the lower half
allows, and the expired watchdog and every one queued after it wait for
an unrelated interrupt. This PR passes 0 for a deadline that has already
passed. A delay of 0 is already what the timer gets today when the
deadline equals the current tick, so no lower half sees a new value.
## Impact
* Is new feature added? Is existing feature changed? NO.
* Impact on user (will user need to adapt to change)? NO.
* Impact on build (will build process change)? NO.
* Impact on hardware (will arch(s) / board(s) / driver(s) change)? YES,
non-alarm tickless builds: a watchdog whose deadline has passed now
fires on the next timer event instead of after a wrapped timeout.
Boards using `CONFIG_SCHED_TICKLESS_ALARM` are unchanged. Some arch
drivers (e.g. ESP32-S3) already wrapped the negative delay back to
"now"; for them the behavior is the same.
* Impact on documentation (is update required / provided)? NO.
* Impact on security (any sort of implications)? NO.
* Impact on compatibility (backward/forward/interoperability)? NO.
## Testing
I confirm that changes are verified on local setup and works as intended:
* Build Host(s): Debian Linux (kernel 6.1), x86_64,
`xtensa-esp-elf-gcc (crosstool-NG esp-14.2.0_20241119) 14.2.0`.
* Target(s): xtensa, `esp32s3-devkit:tickless` (build); custom ESP32-S3
board, non-alarm tickless with `CONFIG_USEC_PER_TICK=1`, NuttX 12.13
with the same change (runtime).
* The overflow itself needs a board using the generic `arch_timer.c`
path, which I don't have; the ESP32-S3 driver wraps a negative delay
back to "now". The runtime test shows the changed path running with no
regression.
Build:
```
$ ./tools/configure.sh esp32s3-devkit:tickless
$ make -j EXTRAFLAGS=-Werror
CC: wdog/wd_start.c
LD: nuttx
$ ./tools/checkpatch.sh -g HEAD~1..HEAD
✔️ All checks pass.
```
Testing logs after change:
```
TODO: ostest output
```
## PR verification Self-Check
* [x] This PR introduces only one functional change.
* [x] I have updated all required description fields above.
* [x] My PR adheres to Contributing
[Guidelines](https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md) and
[Documentation](https://nuttx.apache.org/docs/latest/contributing/index.html)
(git commit title and message, coding standard, etc).
* [x] My PR is ready for review and can be safely merged into a codebase.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
