Luka-Filipovic opened a new issue, #19792:
URL: https://github.com/apache/nuttx/issues/19792
### Description / Steps to reproduce the issue
I'm using STM32F4 devices running PX4. The system does periodic SD card
reads/writes, and when flying it runs a logger that continuously writes to the
SD card.
Very rarely, when arming the drone or when booting up, it fails like this:
- dataman reads start failing (dataman is a PX4 task that reads records from
a binary file on the SD card filesystem). The reads fail fast with -116
(ETIMEDOUT)
- After a few seconds, every task at or below a certain priority stops being
executed, including tasks that never touch the SD card. This is the crucial
part: from this point I can't get any information out of the device, all
mavlink instances and the logger are gone. Tasks above that priority keep
running.
- The state never clears on its own. Only a power cycle recovers the device,
and afterwards the same card mounts and works normally.
- I couldn't find any problems in the higher level tasks that use the SD
card, so the main suspicion is the driver itself.
It is very hard to reproduce, otherwise this would've been much easier to
investigate. The "CPU starving" explanation is just a theory, but it's the only
one I found that fits the behaviour.
After longer investigation, this is the proposal from the claude:
> `stm32_waitresponse()` in `arch/arm/src/common/stm32/stm32_sdio_m3m4_v1.c`
polls `SDIO_STA` in a busy loop bounded only by an iteration count
(`SDIO_LONGTIMEOUT` = `0x7fffffff` for response-bearing commands).
> The hardware `CTIMEOUT` flag normally ends the wait within microseconds,
but it is only generated while the card clock is running and the command state
machine is in its Wait state.
> If the peripheral gets into a bad state, `SDIO_STA` never changes and the
loop spins for minutes at 100% CPU while holding the FAT semaphore — and with
`CONFIG_PRIORITY_INHERITANCE=y` the spinning thread inherits the priority of
the highest waiter blocked on the filesystem, which would produce exactly the
priority-banded starvation I observe.
> Artificially freezing `SDIO_STA` on a bench setup reproduces the same
signature, but I have not captured a real occurrence with a debugger attached.
I find the change very reasonable and safe, however I don't have enough
experience to gauge how big an impact it could have.
### On which OS does this issue occur?
[OS: Linux]
### What is the version of your OS?
Ubuntu
### NuttX Version
master
### Issue Architecture
[Arch: arm]
### Issue Area
[Area: Drivers]
### Host information
_No response_
### Verification
- [x] I have verified before submitting the report.
--
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]
