Repository navigation
tests: pass on a realtime host - #4749
Merged
Merged
Conversation
The rtpreempt buildbot runs rtapi_app setuid, so its threads run SCHED_FIFO. Two things then differ from the non-realtime CI runners: - hal.query reports the thread priority (98) instead of 0, which halmodule/halquery has failed on in every build. Mask it like the component IDs. - A late servo period sends "Unexpected realtime delay" to the error channel. workplane-retain printed it into its result and stale-motion-status/slow-controller, whose kinematics busy wait most of a period, counted it as a failure. Both now leave it out.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bookworm rtpreempt buildbot runs rtapi_app with SCHED_FIFO, and three tests fail there that never fail on GitHub CI, where rtapi_app runs SCHED_OTHER (for example build 4412):
halmodule/halqueryfails in every build:hal.queryreports the thread priority, which is 98 under realtime and 0 without, andexpectedhas 0. The test now masks the priority the same way it already masks the component IDs.workplane-retainandstale-motion-status/slow-controllerfail intermittently: a late servo period sends "Unexpected realtime delay" to the NML error channel, which only happens under SCHED_FIFO.workplane-retainprinted every error channel message into its result, andslow-controller, whose kinematics deliberately busy wait most of a servo period, counted any message as a failure. Both now leave that message out.I reproduced all of these locally with SCHED_FIFO (RLIMIT_RTPRIO raised and
LINUXCNC_FORCE_REALTIME=1), and with this change the three tests pass both with and without realtime.threads.0also fails intermittently on that buildbot, but that one was a real problem rather than a test issue; it is fixed by #4735 (see #4734).