RTEMS | bsps/x86_64/amd64: The CPU counter counts calls and the frequency truncates (#5729)

[Sebastian Huber (@sebhub)]

Issue created by Sebastian Huber: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5729



The clock driver casts the frequency of the time stamp counter to 32 bits
before it gives the value to the timecounter. `tc_frequency` of
`struct timecounter` is 64 bits wide, so a processor above 4.295 GHz gets a
frequency which is far too low and every time reading of the system is wrong.

The x86_64 CPU port is the second defect. It links the software CPU counter of
`cpukit/score/cpu/no_cpu`. `_CPU_Counter_read()` of that counter increments a
static variable per call and `_CPU_Counter_frequency()` returns 1000000000, so
nothing in it measures time. `rtems_counter_delay_nanoseconds()` therefore
delays by a count of calls and `getentropy()` takes no entropy from the time.

The BSP already reads the time stamp counter for its timecounter and already
measures the frequency of that counter, but it does so beside the local APIC
timer in `lapic_timer_calc_ticks_per_sec()`. That runs with the interrupt
facility, which is later than the CPU counter step of the system
initialization, so the measurement has to move for the counter to exist when
`rtems_counter_initialize_converter()` asks for its frequency.

Found while running the full test suite on eleven simulators. This description
was created with Claude Code assistance.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5729
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/5-1ad1m0z65hi3rjc86mc006ef3-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260824/feade3e7/attachment-0001.htm>