AW: [REGRESSION] x86/microcode: boot hangs bringing up first secondary CPU on i7-6700HQ, avoided by dis_ucode_ldr

AW: [REGRESSION] x86/microcode: boot hangs bringing up first secondary CPU on i7-6700HQ, avoided by dis_ucode_ldr

[Dario Ackermann]

I found two similar reports on ASUS N552V-series laptops with an Intel i7-6700HQ:

Ubuntu N552VW: the reporter tested upstream 6.4.0 as working and 6.5.0 as failing. Boot stopped at "smpboot: x86: Booting SMP configuration:", and dis_ucode_ldr allowed booting.
https://askubuntu.com/questions/1512327/ubuntu-freezes-during-boot-when-using-linux-kernel-6-5-0

openSUSE N552V: the reporter says 6.1 works, newer kernels hang when Intel microcode is present, and dis_ucode_ldr allows booting.
https://forums.opensuse.org/t/opensuse-tw-wont-boot-without-the-dis_ucode_ldr-parameter/175229

Commit 0c7ffa32dbd6 ("x86/smpboot/64: Implement arch_cpuhp_init_parallel_bringup() and enable it"), merged for 6.5, moved AP microcode loading from after the AP startup handshake to before it. This is a candidate cause, not yet confirmed by a bisect or patched-kernel boot test on my N552VX.
https://git.kernel.org/linus/0c7ffa32dbd6b09a87fea4ad1de8b27145dfd9a6

I am preparing two upstream 6.18.55 boot images, one unmodified and one with the AP microcode call moved after the handshake, for a direct comparison and to work on a potential fix

Re: AW: [REGRESSION] x86/microcode: boot hangs bringing up first secondary CPU on i7-6700HQ, avoided by dis_ucode_ldr

[Thorsten Leemhuis]

On 11/9/26 22:09, Dario Ackermann wrote:
> I found two similar reports on ASUS N552V-series laptops with an Intel i7-6700HQ:

FWIW, the earlier report from Dario was here:
https://lore.kernel.org/all/581128204058725416570264.8152.2026119193410@darioackermann.ch/


> Ubuntu N552VW: the reporter tested upstream 6.4.0 as working and 6.5.0 as failing. Boot stopped at "smpboot: x86: Booting SMP configuration:", and dis_ucode_ldr allowed booting.
> https://askubuntu.com/questions/1512327/ubuntu-freezes-during-boot-when-using-linux-kernel-6-5-0
> 
> openSUSE N552V: the reporter says 6.1 works, newer kernels hang when Intel microcode is present, and dis_ucode_ldr allows booting.
> https://forums.opensuse.org/t/opensuse-tw-wont-boot-without-the-dis_ucode_ldr-parameter/175229
> 
> Commit 0c7ffa32dbd6 ("x86/smpboot/64: Implement arch_cpuhp_init_parallel_bringup() and enable it"), merged for 6.5, moved AP microcode loading from after the AP startup handshake to before it. This is a candidate cause, not yet confirmed by a bisect or patched-kernel boot test on my N552VX.
> https://git.kernel.org/linus/0c7ffa32dbd6b09a87fea4ad1de8b27145dfd9a6
> 
> I am preparing two upstream 6.18.55 boot images, one unmodified and one with the AP microcode call moved after the handshake, for a direct comparison and to work on a potential fix

FWIW, you really want to test with at least 7.3 or, which would way
better, latest mainline (7.4-rc2 or newer), as the bug might be fixed
there already. If not, some developer might come around with an idea to
debug it; if that doesn't work out, you most likely will need to bisect
the problem.

Ciao, Thorsten

AW: [REGRESSION] x86/microcode: boot hangs bringing up first secondary CPU on i7-6700HQ, avoided by dis_ucode_ldr

[Dario Ackermann]

Sorry for the thread-mixup.

I tested v7.4-rc2 (7475ea8b5861). It still hangs while bringing up CPU1,
with both default AP bringup and cpuhp.parallel=0.

On upstream 6.18.55, I compared four images with the same config and boot
arguments (cpuhp.parallel=0, only intel-ucode.img as initrd):

  unmodified kernel                              hangs at CPU1
  skip Intel AP microcode loading               passes SMP
  skip the AP's MSR 0x79 write                  passes SMP
  do the write, skip the following revision read hangs at CPU1

The passing images reach the expected root-mount failure because the initrd
has no NVMe driver. This implicates the AP microcode write or its immediate
effect, rather than the following revision read (?) Moving load_ucode_ap() after
cpuhp_ap_sync_alive() or cpu_init() still hung.

With the unmodified image, microcode revisions 0xdc (one boot) and 0xd6 (two
boots) hung too. A first-parent bisect of v6.4..v6.5 tentatively points to
the smp-core-2023-06-26 merge (9244724f): its parent passed SMP in 4/5 boots
and the merge in 0/5. Earlier kernels occasionally hang too, and tests within
the merged branch were inconclusive.

Any suggestions for what to instrument next? I am new to kernel debugging,
but happy to take pointers.

Dario

Re: AW: [REGRESSION] x86/microcode: boot hangs bringing up first secondary CPU on i7-6700HQ, avoided by dis_ucode_ldr

[Borislav Petkov]

On Tue, Nov 10, 2026 at 04:08:17PM +0000, Dario Ackermann wrote:
> Sorry for the thread-mixup.
> 
> I tested v7.4-rc2 (7475ea8b5861). It still hangs while bringing up CPU1,
> with both default AP bringup and cpuhp.parallel=0.

Ok, so I don't understand: which kernel did work fine, without any cmdline
switches?

Pls send full dmesg from that one. IOW, did any kernel at all load microcode
successfully on your machine?

Also, send one from 7.4 with dis_ucode_ldr on the cmdline.

Also, check whether you're running the latest microcode packages by updating
your distro blobs.

And put your reply under the text you're replying to, like I just did.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

AW: [REGRESSION] x86/microcode: boot hangs bringing up first secondary CPU on i7-6700HQ, avoided by dis_ucode_ldr

[Dario Ackermann]

> Ok, so I don't understand: which kernel did work fine, without any cmdline
> switches?
>
> Pls send full dmesg from that one. IOW, did any kernel at all load microcode
> successfully on your machine?

6.1, and yes. I had only tested the Manjaro build before. Vanilla 6.1.189
also updates early to 0xf0 and brings up all eight CPUs

https://drop.ackd.xyz/n552vx/dmesg-6.1.189.txt

Not perfect either: ~1 boot in 10 black-screens, as in my first mail.

Second case, from that same mail: 6.18.55 with maxcpus=1, then onlining
CPUs 1-7 from sysfs, leaves all eight on 0xf0. Log for that:

https://drop.ackd.xyz/n552vx/dmesg-6.18.55-maxcpus1.txt

> Also, send one from 7.4 with dis_ucode_ldr on the cmdline.

https://drop.ackd.xyz/n552vx/dmesg-7.4.0-rc2-dis_ucode_ldr.txt

Boots all eight CPUs on the firmware revision:

  [    0.000000] x86/CPU: Running old microcode

> Also, check whether you're running the latest microcode packages by updating
> your distro blobs.

intel-ucode 20260925-1, newest available for manjaro at that point. 0xf0
(2021-11-12) is the latest for signature 0x506e3, pf 0x20.

> And put your reply under the text you're replying to, like I just did.

Done.

Both kernels are vanilla (v7.4-rc2 at 7475ea8b5861, 6.1.189 from
kernel.org), rebuilt with NVMe, ext4 and console built in so they reach
userspace.

My best suspicion at the current time is that it is related to SMP startup and
that disabling the microcode loader prevents a (firmware?) race there. 

Dario

Re: AW: [REGRESSION] x86/microcode: boot hangs bringing up first secondary CPU on i7-6700HQ, avoided by dis_ucode_ldr

[Borislav Petkov]

On Wed, Nov 11, 2026 at 09:45:52AM +0000, Dario Ackermann wrote:
> 6.1, and yes. I had only tested the Manjaro build before. Vanilla 6.1.189
> also updates early to 0xf0 and brings up all eight CPUs
> 
> https://drop.ackd.xyz/n552vx/dmesg-6.1.189.txt

This one looks incomplete. Does it stop booting here?

BUT, before we continue here, I would like you to remove the proprietary
nvidia module completely and then try catching all dmesg again.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette