On Tue, May 31, 2022 at 4:16 PM Yegor Yefremov
[off-list ref] wrote:

quoted

On Tue, May 31, 2022 at 10:36 AM Yegor Yefremov [off-list ref] wrote:
# bad: [b6b3b4814e77d2f5a7517297e9ac1d1aa1cda103] [PART 1] ARM:
implement THREAD_INFO_IN_TASK for uniprocessor systems
git bisect bad b6b3b4814e77d2f5a7517297e9ac1d1aa1cda103
# good: [dccfc18999cf4b4e518f01d5c7c578426166e5f2] ARM: v7m: enable
support for IRQ stacks
git bisect good dccfc18999cf4b4e518f01d5c7c578426166e5f2
# first bad commit: [b6b3b4814e77d2f5a7517297e9ac1d1aa1cda103] [PART
1] ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems

Though commit b6b3b4814e77d2f5a7517297e9ac1d1aa1cda103 led to a broken
kernel that didn't even show any output after the bootloader had
started it.

Commit 2d3456213319c0277ee6082946c43c3afacca9b4 showed the expected stalling.

Ok, good, so we know that the "ARM: implement THREAD_INFO_IN_TASK for
uniprocessor system" commit caused the problem then. This is what we had
already assumed, but now it's confirmed.

Too bad I screwed up that "this_cpu_offset" macro, I think it should
have been

@@ -286,7 +286,7 @@ THUMB(      fpreg   .req    r7      )
         *                   register 'rd'
         */
        .macro          this_cpu_offset, rd:req
-       mov             \rd, #0
+       ldr_va          \rd, __per_cpu_offset
        .endm

        /*

I've pushed a modified branch now, with that fix on the broken commit,
and another change to make CONFIG_IRQSTACKS user-selectable rather
than always enabled. That should tell us if the problem is in the SMP
patching or in the irqstacks.

Can you test the top of this branch with CONFIG_IRQSTACKS disabled,
and (if that still stalls) retest the fixed commit f0191ea5c2e5 ("[PART 1]
ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems")?