Repository navigation
Don't livelock on the busy flag with the GDB backend - #57
Merged
Merged
Conversation
monitor_wait_until_not_busy() polled every 10 ms and never resumed the target. With the GDB backend each ring read interrupts the target, so when an interrupt landed while the firmware held DMLOG_FLAG_BUSY (in the middle of a dmlog write), the target either stayed stopped for good (if the monitor had not resumed it yet, as right after connecting) or only got 10 ms windows, in which Renode lets it execute next to nothing. The flag never cleared and the log stopped for good - dmod-boot's Renode test hung that way at random points of the boot (flags=0x2 in every ring read, head/tail frozen). Resume the target in that loop too and share the 200 ms GDB poll interval monitor_wait_for_new_data() already uses. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JWVYTSBnZLbpDqp7X1sknv
JohnAmadis
pushed a commit
to choco-technologies/dmod-boot
that referenced
this pull request
Sep 30, 2026
choco-technologies/dmlog#57 is merged; abd4691 is its merge commit, with the same tree as the branch commit tested here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JWVYTSBnZLbpDqp7X1sknv
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
2 participants
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.
Problem
In dmod-boot's Renode test,
monitor-gdbwould randomly stop logging partway through the boot (afterdmini,dmfmcordmhaman). It then read the same ring header forever:With
--verboseit happened in 3 of 3 runs.With the GDB backend every ring read interrupts the target. When the interrupt lands while the firmware holds
DMLOG_FLAG_BUSY(in the middle of a dmlog write),monitor_wait_until_not_busy()takes over, and that loop:Either way the flag never clears.
Fix
monitor_wait_until_not_busy()now resumes the target (gdb_resume_briefly()) before polling again with the GDB backend.monitor_wait_for_new_data()already used (Fix the monitor for the current dmod API and for Renode's GDB server #56). OpenOCD keeps 10 ms.Verification
ctestpasses 5/5, andtests/test_automated_gdb.shpasses 7/7 (gdbserver backend).dmlog_monitor --gdbagainst dmod-boot in Renode (chocotechnologies/dmboot:1.0.0): went from 3/3 stalled to 3/3 reachingDMOD-Boot startedand the shell prompt.run_renode_tests.shwith this monitor passes consistently (see the dmod-boot PR adding the UART step).🤖 Generated with Claude Code
https://claude.ai/code/session_01JWVYTSBnZLbpDqp7X1sknv
Generated by Claude Code