[PATCH v3] serial: 8250: Clear CON_PRINTBUFFER on port re-registration

[PATCH v3] serial: 8250: Clear CON_PRINTBUFFER on port re-registration

[Fushuai Wang]

From: Fushuai Wang <wangfushuai@baidu.com>

When two PnP devices map to the same physical port, the serial8250 driver
removes and re-registers the console structure for the same port.

During re-registration, the console structure still has CON_PRINTBUFFER set
from the initial registration, which causes console_init_seq() to set
console->seq to syslog_seq. This results in re-printing the entire
system log buffer, which may lead to RCU stall on slow serial consoles.

Clear CON_PRINTBUFFER when re-registering a port to prevent duplicate
log printing.

Fixes: 835d844d1a28 ("8250_pnp: do pnp probe before legacy probe")
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
---
V2->V3: Clear CON_PRINTBUFFER when remove the port
V1->V2: Add Fixes tag

 drivers/tty/serial/8250/8250_core.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index a428e88938eb..5419f1d22d47 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -716,8 +716,12 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
 	if (uart->port.type == PORT_8250_CIR)
 		return -ENODEV;
 
-	if (uart->port.dev)
+	if (uart->port.dev) {
+		if (uart_console(&uart->port))
+			uart->port.cons->flags &= ~CON_PRINTBUFFER;
+
 		uart_remove_one_port(&serial8250_reg, &uart->port);
+	}
 
 	uart->port.ctrl_id	= up->port.ctrl_id;
 	uart->port.port_id	= up->port.port_id;
-- 
2.36.1

Re: [PATCH v3] serial: 8250: Clear CON_PRINTBUFFER on port re-registration

[Fushuai Wang]

> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index a428e88938eb..5419f1d22d47 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -716,8 +716,12 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
>  	if (uart->port.type == PORT_8250_CIR)
>  		return -ENODEV;
>  
> -	if (uart->port.dev)
> +	if (uart->port.dev) {
> +		if (uart_console(&uart->port))
> +			uart->port.cons->flags &= ~CON_PRINTBUFFER;
> +
>  		uart_remove_one_port(&serial8250_reg, &uart->port);
> +	}
>  
>  	uart->port.ctrl_id	= up->port.ctrl_id;
>  	uart->port.port_id	= up->port.port_id;

ping.

-- 
Regards,
WANG

Re: [PATCH v3] serial: 8250: Clear CON_PRINTBUFFER on port re-registration

[Anirudh Srinivasan]

Hi Fushuai,

On Fri, May 22, 2026 at 06:10:42PM +0800, Fushuai Wang wrote:
> From: Fushuai Wang <wangfushuai@baidu.com>
> 
> When two PnP devices map to the same physical port, the serial8250 driver
> removes and re-registers the console structure for the same port.
> 
> During re-registration, the console structure still has CON_PRINTBUFFER set
> from the initial registration, which causes console_init_seq() to set
> console->seq to syslog_seq. This results in re-printing the entire
> system log buffer, which may lead to RCU stall on slow serial consoles.
> 
> Clear CON_PRINTBUFFER when re-registering a port to prevent duplicate
> log printing.
> 
> Fixes: 835d844d1a28 ("8250_pnp: do pnp probe before legacy probe")
> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
> ---
> V2->V3: Clear CON_PRINTBUFFER when remove the port
> V1->V2: Add Fixes tag
> 
>  drivers/tty/serial/8250/8250_core.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Seems like this patch was added in next-20261717.

I'm noticing that this patch is causing no serial output to be visible
on riscv boards till the uart device is registered. Normally while
booting, we expect for all the prints made before this to be
buffered and appear post serial device initialization.

=> booti 0x11000000 0x21000000:${initrd_size} 0x31000000
Moving Image from 0x11000000 to 0x200000, end=1ca6000
[ 161.301] ## Flattened Device Tree blob at 31000000
[ 161.302]    Booting using the fdt blob at 0x31000000
[ 161.307]    Loading Ramdisk to 7653e000, end 7dd81853 ... OK
[ 161.366]    Loading Device Tree to 0000000076532000, end 000000007653d25d ... OK

Starting kernel ...

[    0.235159] printk: legacy console [ttyS0] enabled
[    0.238787] /soc/i2c@d401d800/pmic@41: Fixed dependency cycle(s) with /soc/i2c@d401d800/pmic@41/regulators/buck5

Most devs who are debugging might be booting with the earlycon boot
parameter. If earlycon is present, serial output is present, but
with earlycon missing (which is what most distros use), I don't get
any serial output till this point.

I observed this on a Milk-V Jupiter and a Hifive Premier P550. Same
behaviour in both cases.

Regards
Anirudh Srinivasan

> 
> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index a428e88938eb..5419f1d22d47 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -716,8 +716,12 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
>  	if (uart->port.type == PORT_8250_CIR)
>  		return -ENODEV;
>  
> -	if (uart->port.dev)
> +	if (uart->port.dev) {
> +		if (uart_console(&uart->port))
> +			uart->port.cons->flags &= ~CON_PRINTBUFFER;
> +
>  		uart_remove_one_port(&serial8250_reg, &uart->port);
> +	}
>  
>  	uart->port.ctrl_id	= up->port.ctrl_id;
>  	uart->port.port_id	= up->port.port_id;
> -- 
> 2.36.1
> 

Re: [PATCH v3] serial: 8250: Clear CON_PRINTBUFFER on port re-registration

[Andy Shevchenko]

On Mon, Jul 20, 2026 at 10:22 PM Anirudh Srinivasan
<asrinivasan@oss.tenstorrent.com> wrote:
> On Fri, May 22, 2026 at 06:10:42PM +0800, Fushuai Wang wrote:

> Seems like this patch was added in next-20261717.

0717

> I'm noticing that this patch is causing no serial output to be visible
> on riscv boards till the uart device is registered. Normally while
> booting, we expect for all the prints made before this to be
> buffered and appear post serial device initialization.
>
> => booti 0x11000000 0x21000000:${initrd_size} 0x31000000
> Moving Image from 0x11000000 to 0x200000, end=1ca6000
> [ 161.301] ## Flattened Device Tree blob at 31000000
> [ 161.302]    Booting using the fdt blob at 0x31000000
> [ 161.307]    Loading Ramdisk to 7653e000, end 7dd81853 ... OK
> [ 161.366]    Loading Device Tree to 0000000076532000, end 000000007653d25d ... OK
>
> Starting kernel ...
>
> [    0.235159] printk: legacy console [ttyS0] enabled
> [    0.238787] /soc/i2c@d401d800/pmic@41: Fixed dependency cycle(s) with /soc/i2c@d401d800/pmic@41/regulators/buck5
>
> Most devs who are debugging might be booting with the earlycon boot
> parameter. If earlycon is present, serial output is present, but
> with earlycon missing (which is what most distros use), I don't get
> any serial output till this point.

Perhaps it's inconvenient. Logically I support using earlycon (I have
noticed a few times in the past double printing of the kernel buffer
to the serial console). So I tend more towards that this patch
actually gives a better experience. However, I haven't given any tag
to it, nor do I object to any improvements or reverting to the old
behaviour — your inconvenience will become mine :-)

Just my 2c.

-- 
With Best Regards,
Andy Shevchenko

[PATCH v3] serial: 8250: Clear CON_PRINTBUFFER on port re-registration

[Fushuai Wang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 2041 bytes --]

> > On Fri, May 22, 2026 at 06:10:42PM +0800, Fushuai Wang wrote:
>
> > Seems like this patch was added in next-20261717.
>
> 0717
>
> > I'm noticing that this patch is causing no serial output to be visible
> > on riscv boards till the uart device is registered. Normally while
> > booting, we expect for all the prints made before this to be
> > buffered and appear post serial device initialization.
> >
> > => booti 0x11000000 0x21000000:${initrd_size} 0x31000000
> > Moving Image from 0x11000000 to 0x200000, end=1ca6000
> > [ 161.301] ## Flattened Device Tree blob at 31000000
> > [ 161.302]    Booting using the fdt blob at 0x31000000
> > [ 161.307]    Loading Ramdisk to 7653e000, end 7dd81853 ... OK
> > [ 161.366]    Loading Device Tree to 0000000076532000, end 000000007653d25d ... OK
> >
> > Starting kernel ...
> >
> > [    0.235159] printk: legacy console [ttyS0] enabled
> > [    0.238787] /soc/i2c@d401d800/pmic@41: Fixed dependency cycle(s) with /soc/i2c@d401d800/pmic@41/regulators/buck5
> >
> > Most devs who are debugging might be booting with the earlycon boot
> > parameter. If earlycon is present, serial output is present, but
> > with earlycon missing (which is what most distros use), I don't get
> > any serial output till this point.
>
> Perhaps it's inconvenient. Logically I support using earlycon (I have
> noticed a few times in the past double printing of the kernel buffer
> to the serial console). So I tend more towards that this patch
> actually gives a better experience. However, I haven't given any tag
> to it, nor do I object to any improvements or reverting to the old
> behaviour — your inconvenience will become mine :-)
>
> Just my 2c.
>
> -- 
> With Best Regards,
> Andy Shevchenko

Hi, Andy and Anirudh

Thanks for the report. I only tested this on x86 and don't have a
RISC-V environment.

I think this patch should be reverted in -next. Since I haven't done
this before, could you let me know the proper way to handle this?
I'll also explore a better approach later.

-- 
Regards,
Fushuai