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

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

Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
---
 drivers/tty/serial/8250/8250_core.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index d2e2c5dfef99..3465a4d93b50 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -694,6 +694,7 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
 {
 	struct uart_8250_port *uart;
 	int ret;
+	bool was_removed = false;
 
 	if (up->port.uartclk == 0)
 		return -EINVAL;
@@ -716,8 +717,10 @@ 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) {
 		uart_remove_one_port(&serial8250_reg, &uart->port);
+		was_removed = true;
+	}
 
 	uart->port.ctrl_id	= up->port.ctrl_id;
 	uart->port.port_id	= up->port.port_id;
@@ -819,6 +822,10 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
 					&uart->capabilities);
 
 		serial8250_apply_quirks(uart);
+
+		if (was_removed && uart_console(&uart->port))
+			uart->port.cons->flags &= ~CON_PRINTBUFFER;
+
 		ret = uart_add_one_port(&serial8250_reg,
 					&uart->port);
 		if (ret)
-- 
2.36.1

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

[Andy Shevchenko]

On Thu, Apr 16, 2026 at 12:29 PM Fushuai Wang <fushuai.wang@linux.dev> 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.

Is it a real device out of there? Can you share what that is?

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

Seems like the Fixes tag is missing.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] 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.
>
> Is it a real device out of there? Can you share what that is?

Yes, it's a real device.
In my Intel(R) Xeon(R) 6971P-C machine, the boot log shows:
	[   17.242984] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
	[   17.251352] printk: console [ttyS0] disabled
	[   17.257934] serial 00:04: Runtime PM usage count underflow!
	[   17.258360] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
	[   17.258516] printk: console [ttyS0] enabled
	[   29.643013] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A

The issue occurs when BIOS "Serial Device" option is set to BMC:
	  Setup Question  = Serial Device
  	  Help String     = Sets the Serial Device used to output bios serial log
  	  Token   = 9003   // Do NOT change this line
  	  Offset  = 2F8
  	  Width   = 01
  	  BIOS Default =[01]BMC
  	  Options = *[01]BMC       // Move "*" to desired Option
            	    [02]S3M

So 00:05 may be the BMC serial port device. From ACPI paths:
	/sys/bus/pnp/devices/00:04/firmware_node/path: \_SB_.LPC0.UAR1
	/sys/bus/pnp/devices/00:05/firmware_node/path: \_SB_.UAR1

>> 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.
>
>Seems like the Fixes tag is missing.

Yes, I will add Fixes tag lately.

-- 
Regards,
WANG

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

[Andy Shevchenko]

On Thu, Apr 16, 2026 at 1:03 PM Fushuai Wang <fushuai.wang@linux.dev> wrote:

> >> When two PnP devices map to the same physical port, the serial8250 driver
> >> removes and re-registers the console structure for the same port.
> >
> > Is it a real device out of there? Can you share what that is?
>
> Yes, it's a real device.
> In my Intel(R) Xeon(R) 6971P-C machine, the boot log shows:
>         [   17.242984] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
>         [   17.251352] printk: console [ttyS0] disabled

>         [   17.257934] serial 00:04: Runtime PM usage count underflow!

This is strange, what kernel version is this?

>         [   17.258360] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
>         [   17.258516] printk: console [ttyS0] enabled
>         [   29.643013] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
>
> The issue occurs when BIOS "Serial Device" option is set to BMC:
>           Setup Question  = Serial Device
>           Help String     = Sets the Serial Device used to output bios serial log
>           Token   = 9003   // Do NOT change this line

>           Offset  = 2F8

Is it an IO port?

>           Width   = 01
>           BIOS Default =[01]BMC
>           Options = *[01]BMC       // Move "*" to desired Option
>                     [02]S3M
>
> So 00:05 may be the BMC serial port device. From ACPI paths:
>         /sys/bus/pnp/devices/00:04/firmware_node/path: \_SB_.LPC0.UAR1
>         /sys/bus/pnp/devices/00:05/firmware_node/path: \_SB_.UAR1

Do I understand correctly that both devices refer to the same physical
device?! How on earth is it supposed to work?

> >> 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.
> >
> >Seems like the Fixes tag is missing.
>
> Yes, I will add Fixes tag lately.

-- 
With Best Regards,
Andy Shevchenko

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

[Fushuai Wang]

>> >> When two PnP devices map to the same physical port, the serial8250 driver
>> >> removes and re-registers the console structure for the same port.
>> >
>> > Is it a real device out of there? Can you share what that is?
>>
>> Yes, it's a real device.
>> In my Intel(R) Xeon(R) 6971P-C machine, the boot log shows:
>>         [   17.242984] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
>>         [   17.251352] printk: console [ttyS0] disabled
>
>>         [   17.257934] serial 00:04: Runtime PM usage count underflow!
>
> This is strange, what kernel version is this?

Please ingore this. I just test the patch in kernel 6.6. And this log
has nothing to do with this problem. It was fixed in patch ed2761958ad7
("tty: serial: 8250: Fix another runtime PM usage counter underflow").

>
>>         [   17.258360] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
>>         [   17.258516] printk: console [ttyS0] enabled
>>         [   29.643013] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
>>
>> The issue occurs when BIOS "Serial Device" option is set to BMC:
>>           Setup Question  = Serial Device
>>           Help String     = Sets the Serial Device used to output bios serial log
>>           Token   = 9003   // Do NOT change this line
>>           Offset  = 2F8
>
> Is it an IO port?

No, Offset = 2F8 is the offset in BIOS configuration space, not the I/O port.

>>           Width   = 01
>>           BIOS Default =[01]BMC
>>           Options = *[01]BMC       // Move "*" to desired Option
>>                     [02]S3M
>>
>> So 00:05 may be the BMC serial port device. From ACPI paths:
>>         /sys/bus/pnp/devices/00:04/firmware_node/path: \_SB_.LPC0.UAR1
>>         /sys/bus/pnp/devices/00:05/firmware_node/path: \_SB_.UAR1
>
> Do I understand correctly that both devices refer to the same physical
> device?! How on earth is it supposed to work?

Not exactly the same physical device, but they map to the same I/O port (0x3f8).
They are different PnP devices with different ACPI paths:

  00:04: \_SB_.LPC0.UAR1  (LPC COM1)
  00:05: \_SB_.UAR1       (BMC serial port)

When BIOS "Serial Device" option is set to BMC, both 00:04 and 00:05 are mapped to
the same physical I/O port 0x3f8. And then:

  1.00:04 is probed first and registers the console for port 0x3f8
  2.00:05 is detected and also needs to use port 0x3f8
  3.Since port 0x3f8 is already in use, the driver must remove 00:04 first before
    adding 00:05
  4.This process involves console re-registration, which causes the entire 
    log buffer to be reprinted

Sorry if my explanation is not clear - I don't work with serial subsystem often. :-)

-- 
Regards,
WANG

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

[Andy Shevchenko]

On Thu, Apr 16, 2026 at 2:32 PM Fushuai Wang <fushuai.wang@linux.dev> wrote:

> >> >> When two PnP devices map to the same physical port, the serial8250 driver
> >> >> removes and re-registers the console structure for the same port.
> >> >
> >> > Is it a real device out of there? Can you share what that is?
> >>
> >> Yes, it's a real device.
> >> In my Intel(R) Xeon(R) 6971P-C machine, the boot log shows:
> >>         [   17.242984] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
> >>         [   17.251352] printk: console [ttyS0] disabled
> >
> >>         [   17.257934] serial 00:04: Runtime PM usage count underflow!
> >
> > This is strange, what kernel version is this?
>
> Please ingore this. I just test the patch in kernel 6.6. And this log
> has nothing to do with this problem. It was fixed in patch ed2761958ad7
> ("tty: serial: 8250: Fix another runtime PM usage counter underflow").

Thanks for clarification.

> >>         [   17.258360] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
> >>         [   17.258516] printk: console [ttyS0] enabled
> >>         [   29.643013] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
> >>
> >> The issue occurs when BIOS "Serial Device" option is set to BMC:
> >>           Setup Question  = Serial Device
> >>           Help String     = Sets the Serial Device used to output bios serial log
> >>           Token   = 9003   // Do NOT change this line
> >>           Offset  = 2F8
> >
> > Is it an IO port?
>
> No, Offset = 2F8 is the offset in BIOS configuration space, not the I/O port.
>
> >>           Width   = 01
> >>           BIOS Default =[01]BMC
> >>           Options = *[01]BMC       // Move "*" to desired Option
> >>                     [02]S3M
> >>
> >> So 00:05 may be the BMC serial port device. From ACPI paths:
> >>         /sys/bus/pnp/devices/00:04/firmware_node/path: \_SB_.LPC0.UAR1
> >>         /sys/bus/pnp/devices/00:05/firmware_node/path: \_SB_.UAR1
> >
> > Do I understand correctly that both devices refer to the same physical
> > device?! How on earth is it supposed to work?
>
> Not exactly the same physical device, but they map to the same I/O port (0x3f8).
> They are different PnP devices with different ACPI paths:
>
>   00:04: \_SB_.LPC0.UAR1  (LPC COM1)
>   00:05: \_SB_.UAR1       (BMC serial port)
>
> When BIOS "Serial Device" option is set to BMC, both 00:04 and 00:05 are mapped to
> the same physical I/O port 0x3f8. And then:
>
>   1.00:04 is probed first and registers the console for port 0x3f8
>   2.00:05 is detected and also needs to use port 0x3f8

This is simply wrong. Do we ever support such a FW configuration?
Why on earth are there two devices for the same resource exposed to
the OS? It smells like a bug in BIOS.

>   3.Since port 0x3f8 is already in use, the driver must remove 00:04 first before
>     adding 00:05
>   4.This process involves console re-registration, which causes the entire
>     log buffer to be reprinted
>
> Sorry if my explanation is not clear - I don't work with serial subsystem often. :-)

Now it's elaborated well enough.

-- 
With Best Regards,
Andy Shevchenko

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

[Fushuai Wang]

>> ...
>> When BIOS "Serial Device" option is set to BMC, both 00:04 and 00:05 are mapped to
>> the same physical I/O port 0x3f8. And then:
>>
>>   1.00:04 is probed first and registers the console for port 0x3f8
>>   2.00:05 is detected and also needs to use port 0x3f8
>
> This is simply wrong. Do we ever support such a FW configuration?
> Why on earth are there two devices for the same resource exposed to
> the OS? It smells like a bug in BIOS.

My BIOS has this configuration option, and I also found other vendors'
BIOS with the same option, e.g.:

	https://download.msi.com/archive/mnu_exe/server/S3066-S377-v1.1-BIOS-UG.pdf

	Serial Device [BMC]/[S3M] Sets the Serial Device used to output bios serial log

Also, the kernel's serial8250_register_8250_port() already 
handles the case where multiple devices map to the same physical 
port. When serial8250_find_match_or_unused() detects that 
a device with the same port already exists, the caller 
(serial8250_register_8250_port()) removes the existing 
port before registering the new one.

Since the kernel already supports this remove-re-add process, I
think it makes sense to fix the CON_PRINTBUFFER issue to handle
this scenario, rather than relying on BIOS to avoid such configurations.

-- 
Regards,
WANG