Re: Console Hang on SMP Secondary CPU Bringup

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-09-28 16:54:31 [-0400], Derek Barbosa wrote:
> Hi Sebastian,
Hi Derek,

> On Mon, Sep 28, 2026 at 04:08:37PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2026-09-23 12:02:31 [-0400], Derek Barbosa wrote:
> > > In the v6.6-rt-rebase branch in the linux-stable-rt kernel trees, building (with
> > > defconfig and additional HV drivers enabled), installing, then booting a kernel
> > > in a paravirtualized Virtual Machine environment (HyperV in this case) via UEFI
> > > boot may result in a unrecoverable "hang"
> > 
> > Does this also occur in v6.6-rt15? If so, can you check v7.3-rc5 and if
> > it does not occur, try other RT kernels where this started happening?
> 
> You mean the non-rebase branch, correct? I can throw that on the TODO as well.

I don't care so much about rebase vs non-rebase but the old v6.6-rt15 vs
current. Just to ensure that nothing slipped in while moving forward. I
would assume that the rebase and non-rebase branch are equal for a fiven
version.

> Just recently I tested a 7.2 kernel with PREEMPT_RT (and some other Fedora
> configs) and was able to reproduce the issue. I need to confirm this though,
> running some more trials and collecting data. I've been a little
> scatter-brained.

Oh. That is good because it is not something that exists just in this
old version of printk but also in the recent one.

> > This HyperV is something I can't try here, can I?
> 
> Hmm. IIRC you either need a Windows host with the functionality enabled, or
> access to some sort of Azure cloud platform [0]. It is similar to other compute
> providers in terms of signup, etc.

I have neither.

> > Does this run in qemu where you could attach gdb and check what the CPUs
> > are doing?
> > 
> 
> I John's email with something similar. TLDR: I don't know what other functionalities
> of Hyper-V the "Azure Cloud VMs" expose, I will play around with the knobs and
> fiddle with some buttons here and there...

Ah, I forget that gdb and so on does not work in the other world.

> > So we are not doing PREEMPT_RT?
> 
> The issue was reproducible in both :)
> 
> But seeing as how the code still exists in this tree, I figured this may be the
> best place to report it.

The logic should be widely the same but changed in a few details to what
we have now in v7.3-rc1. Also the print logic is different in RT vs
non-RT (due to threaded printing and not).

> It hangs right at the "cpuhp up cpu1 state cpu:kick_ap" message I had inserted.
> 
> I will play around with some of John's suggestions, and a few more ideas I had
> in mind.

The question is, does it hang on its own or is related to printk message
it issues.

> > The printk version is a bit old but still functional :) If the problem
> > does not occur in a later kernel then could think about backporting that
> > printk version back to v6.6 (unless there is a single obvious cause).
> 
> It very much is! I am pretty positive that we're only seeing the bug in
> this weird corner case of HyperV (Linux guest), nbcon + high loglevel.
> 
> Thank you for the heads up. I will report back with more results + findings
> soon. The bug is just pretty tedious to reproduce.

okay, thanks.

Sebastian