[Skiboot] [PATCH 1/3] uart: Drop console write data if BMC becomes unresponsive
Nicholas Piggin
npiggin at gmail.com
Wed May 20 23:02:12 AEST 2020
Excerpts from Vasant Hegde's message of May 20, 2020 9:51 pm:
> If BMC becomes unresponsive (ex: during BMC reboot) during console write
> then we may get stuck in uart_wait_tx_room(). This will result in kernel
> lockups and in some cases host becomes unresponsive.
>
> This patch retries for `tx_room` for predefined number of time. If we don't
> get space within that time it will return zero. This will result in
> dropping console message.
Is the number of times important, or should it be time based?
>
> Signed-off-by: Vasant Hegde <hegdevasant at linux.vnet.ibm.com>
> ---
> hw/lpc-uart.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/hw/lpc-uart.c b/hw/lpc-uart.c
> index 979a617c3..ed56a4bdc 100644
> --- a/hw/lpc-uart.c
> +++ b/hw/lpc-uart.c
> @@ -63,6 +63,8 @@ static void *mmio_uart_base;
> static int uart_console_policy = UART_CONSOLE_OPAL;
> static int lpc_irq = -1;
>
> +#define UART_WRITE_MAX_RETRIES 0x100
> +
> void uart_set_console_policy(int policy)
> {
> uart_console_policy = policy;
> @@ -106,6 +108,8 @@ static void uart_check_tx_room(void)
>
> static void uart_wait_tx_room(void)
> {
> + int retry_cnt = 0;
> +
> while (!tx_room) {
> uart_check_tx_room();
> if (!tx_room) {
> @@ -113,6 +117,10 @@ static void uart_wait_tx_room(void)
> do {
> barrier();
> uart_check_tx_room();
> +
> + retry_cnt++;
> + if (retry_cnt > UART_WRITE_MAX_RETRIES)
> + return;
> } while (!tx_room);
> smt_medium();
Must restore SMT priority to medium.
Thanks,
Nick
More information about the Skiboot
mailing list