[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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 4714 bytes --]

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.

For the past week or more (I think since it was committed) I have been
seeing boot regressions in -next on a wide range of platforms which
bisect to it.  One sample is the VisionFive2 which gets to userspace but
grinds to a halt:

[   16.954602] pci 0001:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[   16.962739] pci_bus 0001:01: busn_res: [bus 01-ff] end is updated to 01
[   16.969371] pci 0001:00:00.0: PCI bridge to [bus 01]
[   16.974348] pci_bus 0001:00: resource 4 [mem 0x38000000-0x3fffffff]
[   16.980620] pci_bus 0001:00: resource 5 [mem 0x980000000-0x9bfffffff pref]
[   16.987749] pcieport 0001:00:00.0: PME: Signaling with IRQ 66
/bin/sh: can't access tty; job control turned off

Full log:

   https://lava.sirena.org.uk/scheduler/job/3013935#L604

I'm also seeing this on for example pine64plus.  Some platforms have
some WARN_ON()s from DRM which slowed reporting but those don't seem
related.

bisect log, other platforms look similar and converge on the same commit:

git bisect start
# status: waiting for both good and bad commits
# bad: [9eebf259d5352b87080d67758f483583d9e763d7] Add linux-next specific files for 20260723
git bisect bad 9eebf259d5352b87080d67758f483583d9e763d7
# status: waiting for good commit(s), bad commit known
# good: [922cc3121ee3e099ec8d36c468f38cd3dff3308a] Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git
git bisect good 922cc3121ee3e099ec8d36c468f38cd3dff3308a
# good: [a442ff27677c2fdc0c046778a6c12b78cc9561ec] Merge branch 'libcrypto-next' of https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git
git bisect good a442ff27677c2fdc0c046778a6c12b78cc9561ec
# good: [62dd23e06176ab94221cbe269c46483534cf6545] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
git bisect good 62dd23e06176ab94221cbe269c46483534cf6545
# good: [cbbe21042d5ae5b70f7bfd02fa345ccdea53b069] Merge branch 'usb-next' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git
git bisect good cbbe21042d5ae5b70f7bfd02fa345ccdea53b069
# bad: [ed9b79b61e9248ec87c34c0d2f7f2109e7f3a651] Merge branch 'staging-next' of https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
git bisect bad ed9b79b61e9248ec87c34c0d2f7f2109e7f3a651
# bad: [5e110656994217e9816366ae54b83511b55f4f77] Merge branch 'togreg' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
git bisect bad 5e110656994217e9816366ae54b83511b55f4f77
# bad: [d6082d34d41e4bd21dbe39203e2e050016d092e3] Merge branch 'char-misc-next' of https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
git bisect bad d6082d34d41e4bd21dbe39203e2e050016d092e3
# good: [6994c8b4ef95114073a51d6143185bca39d6e5d5] drivers/misc/enclosure: Replace strcpy() + strcat() with snprintf()
git bisect good 6994c8b4ef95114073a51d6143185bca39d6e5d5
# bad: [6e5bd7cc3a2f304a66d294011647d82074421979] serial: qcom-geni: Add tracepoints for Qualcomm GENI serial driver
git bisect bad 6e5bd7cc3a2f304a66d294011647d82074421979
# bad: [7a68b818d56e5c48b90232d59148ef8e716082ae] serdev: acpi: Free resource list at appropriate time
git bisect bad 7a68b818d56e5c48b90232d59148ef8e716082ae
# good: [25b51d1fd3268a219e43608b165098fff7cd9dcd] serial: max310x: register GPIO controller before adding UART ports
git bisect good 25b51d1fd3268a219e43608b165098fff7cd9dcd
# bad: [d338ab1d90603f875c4f7ed223406535378173a5] serial: 8250: Clear CON_PRINTBUFFER on port re-registration
git bisect bad d338ab1d90603f875c4f7ed223406535378173a5
# good: [7a52545d37eb805eb1f3c7e03ff336b12c12f5af] tty: tty_jobctrl: use guard()s in tiocspgrp()
git bisect good 7a52545d37eb805eb1f3c7e03ff336b12c12f5af
# good: [4d105880666ab7f7914a75716d3e95b0d8b879dc] tty: serial: mpc52xx_uart: add bounds check for psc_num array index
git bisect good 4d105880666ab7f7914a75716d3e95b0d8b879dc
# first bad commit: [d338ab1d90603f875c4f7ed223406535378173a5] serial: 8250: Clear CON_PRINTBUFFER on port re-registration

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

On Thu, Jul 23, 2026 at 10:55:44PM +0100, Mark Brown wrote:
> On Fri, May 22, 2026 at 06:10:42PM +0800, Fushuai Wang wrote:

> > Clear CON_PRINTBUFFER when re-registering a port to prevent duplicate
> > log printing.
> 
> For the past week or more (I think since it was committed) I have been
> seeing boot regressions in -next on a wide range of platforms which
> bisect to it.  One sample is the VisionFive2 which gets to userspace but
> grinds to a halt:

A fix for these boot regressions was pused by Fushuai:

  https://lore.kernel.org/r/20260724093151.53216-1-fushuai.wang@linux.dev

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]