From: John Ogness <john.ogness@linutronix.de>
To: debarbos@redhat.com, williams@redhat.com
Cc: williams@redhat.com, vkuznets@redhat.com,
linux-rt-users@vger.kernel.org, Petr Mladek <pmladek@suse.com>
Subject: Re: Console Hang on SMP Secondary CPU Bringup
Date: Mon, 28 Sep 2026 16:06:22 +0206 [thread overview]
Message-ID: <87fqytbhmx.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <arPmYPbFLf2EldIl@debarbos-thinkpadt14gen5.rmtusma.csb>
Hi Derek,
On 2026-09-23, Derek Barbosa <debarbos@redhat.com> wrote:
> It appears as though the behavior in question has been bisected to af3a8162581e
> ("serial: 8250: Switch to nbcon console")
Since you are hacking up the code anyway, here a few things you could
try.
First off, it might be helpful to enable CONFIG_PRINTK_CALLER. This will
print the CPU-ID that the printk message originated from.
To be sure it is timing related due to the nbcon atomic printing, you
could try short-circuiting:
drivers/tty/serial/8250/8250_port.c:serial8250_console_write_atomic()
so that it immediately does
return true;
Obviously you will not see any kernel messages on boot, but the machine
should boot and with dmesg you should still see all the messages.
Assuming that boots, you could change the short-circuit in
serial8250_console_write_atomic() to simulate the timing with:
mdelay(7);
return true;
If it fails to boot, then we at least know it has nothing to do with the
8250 and is instead either delays in time-sensitive sections or some
sort of contention bug in the core nbcon code.
> <snip>
> while (!nbcon_enter_unsafe(wctxt))
> nbcon_reacquire(wctxt);
>
> /* Finally, wait for transmitter to become empty and restore IER. */
> wait_for_xmitr(up, UART_LSR_BOTH_EMPTY);
> if (em485) {
> mdelay(port->rs485.delay_rts_after_send);
> if (em485->tx_stopped)
> up->rs485_stop_tx(up);
> }
> serial_port_out(port, UART_IER, ier);
> </snip>
>
> Is it possible that we just spin here?
That loop means that the console has lost ownership. A console can only
lose ownership if a WARN or panic were to occur at that moment. I assume
you have neither.
With QEMU it is easy to attach gdb and dump the kernel logs using the
gdb scripts. I don't know if Hyper-V has anything like this. But it
could help if there is one more printk message you are not seeing. When
printk() is called, it locklessly inserts the message and then tries to
print it to the console.
John Ogness
next prev parent reply other threads:[~2026-09-28 14:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 16:02 Console Hang on SMP Secondary CPU Bringup Derek Barbosa
2026-09-28 14:00 ` John Ogness [this message]
2026-09-28 20:17 ` Derek Barbosa
2026-10-02 21:07 ` Derek Barbosa
2026-10-03 19:19 ` John Ogness
2026-09-28 14:08 ` Sebastian Andrzej Siewior
2026-09-28 20:54 ` Derek Barbosa
2026-09-29 9:14 ` Sebastian Andrzej Siewior
2026-10-02 20:53 ` Derek Barbosa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fqytbhmx.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=debarbos@redhat.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=vkuznets@redhat.com \
--cc=williams@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.