Fishwaldo opened a new pull request, #19732:
URL: https://github.com/apache/nuttx/pull/19732
## Summary
* The RAM log is the natural home for boot messages, but writing to it
during early boot can crash the system it is meant to describe.
* `ramlog_addbuf()` took the critical section on every write, and
`enter_critical_section()` consults the current task. On a port whose
first syslog output happens before the task lists exist, that lookup
walks uninitialized state and faults. The reader notification path was
worse still, locking a scheduler that did not exist yet.
* Both are now guarded on the OS init level. Before the task lists exist,
plain interrupt masking protects the buffer just as well, since there is
only one thread of control; readers are notified only once there is a
scheduler to notify them through.
* The bytes land in the buffer either way, so nothing logged before the OS
is ready is lost.
* No related issue filed.
## Impact
* Is new feature added? Is existing feature changed? **NO.** Bug fix.
* Impact on user? **YES, positive.** `CONFIG_RAMLOG_SYSLOG` becomes usable
on ports that log before the scheduler exists. No API or configuration
change; a port that already worked sees no behavioural difference, since
the guarded paths are taken only before `OSINIT_TASK_READY()` and
`OSINIT_OS_READY()`.
* Impact on build? **NO.**
* Impact on hardware? **NO.** Driver code, architecture-independent, though
whether the bug is reachable depends on how early a given arch calls
`syslog`.
* Impact on documentation? **NO.**
* Impact on security? **NO.**
* Impact on compatibility? **NO.**
* Anything else? This makes RAMLOG match what the syslog layer already
assumes: that a channel can be written from the earliest moments of boot.
Other channels already tolerate it; RAMLOG did not.
## Testing
I confirm that changes are verified on local setup and works as intended:
* Build Host: macOS 26.5.1, arm64 (Apple Silicon), xPack riscv-none-elf-gcc
15.2.0
* Target: RISC-V, ESWIN EIC7700X EVB (downstream board port, not yet
upstream), kernel build, `CONFIG_RAMLOG_SYSLOG=y`
Reproduce by enabling `CONFIG_RAMLOG_SYSLOG` on any port that calls
`syslog`
before the task lists are initialised. This port logs from its start
routine, before the MMU is up, which is what makes the fault reachable.
Before the change, enabling `RAMLOG_SYSLOG` turned the boot into a silent
wedge two characters in. There is no "before" log to provide, because
producing no log is the failure: the fault happens inside the syslog write
itself, so the message that would have described it never reaches the
console and nothing further is emitted. An empty console is the whole
symptom.
After the change the same configuration boots to a shell, and `dmesg`
replays the full early history, including the messages written before the
scheduler existed. Ports that were already working are unaffected, since
both guarded paths are taken only before `OSINIT_TASK_READY()` and
`OSINIT_OS_READY()`.
## PR verification Self-Check
* [x] This PR introduces only one functional change.
* [x] I have updated all required description fields above.
* [x] My PR adheres to Contributing Guidelines and Documentation.
* [ ] My PR is still work in progress (not ready for review).
* [x] My PR is ready for review and can be safely merged into a codebase.
---
*Claude (claude-opus-5) assisted with diagnosing this bug and with authoring
the
code comments and this PR description. The commit carries an `Assisted-by:`
tag
per
[CONTRIBUTING.md](https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md)
ยง1.5.*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
