subrata singh commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3889#note_149273 Hello mentors @joel and @gedare, While writing this test I found a bug in `timer_settime()`: when `flags == TIMER_ABSTIME`, it unconditionally calls `_TOD_Get()` (`CLOCK_REALTIME`) before fetching the timer object, regardless of the timer's `clock_type`. This means `TIMER_ABSTIME` with `CLOCK_MONOTONIC` always returns `EINVAL` because monotonic uptime (seconds since boot) is always less than wall clock time (Unix epoch). `_Timespec_Greater_than( &now, &normalize.it_value )` always evaluates to true. I verified this by running the test on the ERC32 simulator. I have commented out the remaining time check with a `TODO` and set the `.scn` file to expect this `EINVAL` failure for now so the test completes cleanly. To fix this in `timersettime.c`, the absolute to relative conversion block needs to be moved down inside the section (after `ptimer = _POSIX_Timer_Get(...)`) so we can check `ptimer->clock_type`. Then we can fetch the correct time (e.g., `_Timecounter_Nanouptime`). Current - clock_type unknown here, always uses `_TOD_Get()` ```c if ( flags == TIMER_ABSTIME ) { _TOD_Get( &now ); // wrong for CLOCK_MONOTONIC //subtract... } ptimer = _POSIX_Timer_Get( timerid, &lock_context ); // late ``` The fix: move the conversion block to after _POSIX_Timer_Get() so ptimer->clock_type is available. ```c ptimer = _POSIX_Timer_Get( timerid, &lock_context ); if ( ptimer != NULL ) { if ( flags == TIMER_ABSTIME ) { if ( ptimer->clock_type == CLOCK_MONOTONIC ) _Timecounter_Nanouptime( &now ); else _TOD_Get( &now ); //subtract } } ``` I can try to submit a patch for `timersettime.c` if this is confirmed as unintended behavior. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/3889#note_149273 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
