-
Couldn't load subscription status.
- Fork 8.1k
Description
Describe the bug
There seems to be a race in the shell if CONFIG_SHELL_BACKEND_SERIAL_API_INTERRUPT_DRIVEN is enabled ,
where the UART Rx interrupt is enabled
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/shell/backends/shell_uart.c#L221
before shell_thread is spawned.
With the UART Rx interrupt triggering (before that thread is processing), an SHELL_SIGNAL_RXRDY event
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/shell/backends/shell_uart.c#L130
will be queued, but it will never be dequeued.
Note that as part of shell_start(), z_shell_backend_rx_buffer_flush() is called.
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/shell/shell.c#L1444
Removing the already received data. But the SHELL_SIGNAL_RXRDY event is left pending, so this is inconsistent.
In any case, this k_event_wait() https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/shell/shell.c#L1338
would seem to wait for new events (not return if one was already pended), so it will block there.
Regression
- This is a regression.
Steps to reproduce
The easiest way to repro it may be by taking this #93957,
and run
echo -e "help\n" | zephyr/zephyr.exe -uart_stdinout | head -n 80
You can see that the shell does not process the help message and does not print anything.
While with CONFIG_SHELL_BACKEND_SERIAL_API_INTERRUPT_DRIVEN=n it does.
Relevant log output
N/A
Expected behavior
The shell enables the UART reception when it can start processing the data.
Impact
Functional Limitation – Some features not working as expected, but system usable.
Environment
- OS Linux
- host gcc 14.2
- Main as of now (8843fd9 , but with patch to trigger issue)
Additional Context
Issue was discovered while trying #93957