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
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:
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:
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