drivers/tty/serial/8250/8250_core.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
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.1On 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
>>
>> 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
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
>> >> 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
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
>> ... >> 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
© 2016 - 2026 Red Hat, Inc.