serial: 8250: Clear CON_PRINTBUFFER on port re-registration

PATCH Superseded Fushuai Wang 4 participants 7 messages May 22 – Jul 29

Subsystems (2)

RISC-V TTY layer and serial drivers

lore

Share & tools

lore

Fushuai Wang

author

2026-05-22 10:11 UTC #0 lore raw

PATCH v3 1/1 serial: 8250: Clear CON_PRINTBUFFER on port re-registration

From: Fushuai Wang <[email protected]>

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")

Signed-off-by Fushuai Wang <[email protected]>

---
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(-)

drivers/tty/serial/8250/8250_core.c +5 -1

index a428e88938eb..5419f1d22d47 100644
@@ -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;

Signature · 1 line

2.36.1

Fushuai Wang

author

2026-06-03 06:57 UTC #1 lore raw

Quoted 8 lines

drivers/tty/serial/8250/8250_core.c +0 -0

index a428e88938eb..5419f1d22d47 100644
@@ -716,8 +716,12 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
 	if (uart->port.type == PORT_8250_CIR)
 		return -ENODEV;

drivers/tty/serial/8250/8250_core.c int serial8250_register_8250_port(const struct uart_8250_port *up) · line 727

Quoted 10 lines

drivers/tty/serial/8250/8250_core.c +5 -1

-	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.

Signature · 2 lines

Regards,
WANG

Anirudh Srinivasan

2026-07-20 19:22 UTC #2 lore raw

In reply to Fushuai Wang

Hi Fushuai,

Quoted 16 lines · Fushuai Wang

From: Fushuai Wang <[email protected]>
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 <[email protected]>
Signed-off-by Fushuai Wang <[email protected]>

Quoted 6 lines

---
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

Quoted 22 lines

drivers/tty/serial/8250/8250_core.c +5 -1

index a428e88938eb..5419f1d22d47 100644
@@ -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;

Signature · 1 line

2.36.1

Andy Shevchenko

2026-07-20 20:23 UTC #3 lore raw

Quoted 3 lines · Anirudh Srinivasan

On Fri, May 22, 2026 at 06:10:42PM +0800, Fushuai Wang wrote:
Seems like this patch was added in next-20261717.

0717

Quoted 14 lines

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 ...

Quoted 7 lines

[    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.

Signature · 2 lines

With Best Regards,
Andy Shevchenko

Fushuai Wang

author

2026-07-21 03:14 UTC #4 lore raw

PATCH v3 1/1 serial: 8250: Clear CON_PRINTBUFFER on port re-registration

Quoted 28 lines

Quoted 3 lines · Fushuai Wang
Seems like this patch was added in next-20261717.
0717
Quoted 14 lines
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 ...
Quoted 7 lines
[    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.

Quoted 12 lines

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.
Signature · 2 lines
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.

Signature · 2 lines

Regards,
Fushuai

Mark Brown

2026-07-23 21:55 UTC #5 lore raw

In reply to Fushuai Wang

Quoted 5 lines · Fushuai Wang

From: Fushuai Wang <[email protected]>
When two PnP devices map to the same physical port, the serial8250 driver removes and re-registers the console structure for the same port.

Quoted 7 lines

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

Mark Brown

2026-07-29 10:22 UTC #6 lore raw

Quoted 9 lines · Mark Brown

Quoted 2 lines · Fushuai Wang
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/[email protected]