Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

tests: benchmarks: thread_metric: up_squared: error sending/receiving messages #83864

Closed
golowanow opened this issue Jan 12, 2025 · 2 comments · Fixed by #85003
Closed

tests: benchmarks: thread_metric: up_squared: error sending/receiving messages #83864

golowanow opened this issue Jan 12, 2025 · 2 comments · Fixed by #85003
Assignees
@peter-mitsis
Labels
area: Benchmarks bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@golowanow
Copy link
Member

Describe the bug
benchmark.thread_metric.message on up_squared always returns zero metric value and ERROR: Invalid counter value(s). Error sending/receiving messages!
The problem observed at least on two up_squared boards.
Other thread_metric benchmarks usually have no problems on the same devices.

To Reproduce
Run the thread_metric benchmark test suite on a host with up_squared connected, e.g.
twister -p up_squared/apollo_lake -T tests/benchmarks/thread_metric

Expected behavior
The benchmark returns its time period values without errors.

Logs and console output

**** Thread-Metric Message Processing Test **** Relative Time: 30
ERROR: Invalid counter value(s). Error sending/receiving messages!
Time Period Total:  0

**** Thread-Metric Message Processing Test **** Relative Time: 60
ERROR: Invalid counter value(s). Error sending/receiving messages!
Time Period Total:  0

**** Thread-Metric Message Processing Test **** Relative Time: 90
ERROR: Invalid counter value(s). Error sending/receiving messages!
Time Period Total:  0

Environment (please complete the following information):

  • OS: Linux
  • Toolchain zephyr SDK 0.17.0
  • Commit SHA f9e4bc3
@golowanow golowanow added bug The issue is a bug, or the PR is fixing a bug area: Benchmarks labels Jan 12, 2025
@golowanow golowanow changed the title tests: benchmarks: thread_metric: error sending/receiving messages tests: benchmarks: thread_metric: up_squared: error sending/receiving messages Jan 12, 2025
@kartben kartben added the priority: low Low impact/importance bug label Jan 14, 2025
@peter-mitsis
Copy link
Collaborator

Apparently this is replicable on qemu_x86_64 as well.

@peter-mitsis
Copy link
Collaborator

I think I have it figured out. The problem occurs on systems where 'unsigned long' is 8 bytes, not 4 bytes. This violates an assumption made by the benchmark.

peter-mitsis added a commit to peter-mitsis/zephyr that referenced this issue Jan 31, 2025
@peter-mitsis
tests: Fix thread_metric message processing
6aee9bc 
Changes the type of both the tm_message_sent and tm_message_received
arrays from 'unsigned long' to 'unsigned int'. The test expects those
arrays to be 16 bytes long. This was a problem on 64-bit platforms
as 'unsigned long' is 8 bytes, which made the arrays 32 bytes long.
On both our supported 32-bit and 64-bit platforms, 'unsigned int'
works out to be 4 bytes long, thereby giving us the requisite 16
byte buffer.

Although a case could be made for using 'uint32_t', this was not
chosen simply to keep the structure as close as practical to the
original thread_metric implementation.

Fixes zephyrproject-rtos#83864

Signed-off-by: Peter Mitsis <[email protected]>
@peter-mitsis peter-mitsis mentioned this issue Jan 31, 2025
Merged
@kartben kartben closed this as completed in 11f69fb Feb 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@peter-mitsis peter-mitsis

Labels
area: Benchmarks bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

tests: Fix thread_metric message processing peter-mitsis/zephyr
3 participants
@kartben @golowanow @peter-mitsis