On Tue, May 31, 2022 at 5:23 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Tue, May 31, 2022 at 4:16 PM Yegor Yefremov
> <yegorslists@xxxxxxxxxxxxxx> wrote:
> > On Tue, May 31, 2022 at 10:36 AM Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> 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")?
1. the top of this branch with CONFIG_IRQSTACKS disabled stalls
2. f0191ea5c2e5 with the same config - not
Yegor
