[Skiboot] [PATCH 1/3] uart: Drop console write data if BMC becomes unresponsive

[Nicholas Piggin]

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