Re: am335x: 5.18.x: system stalling

[Arnd Bergmann <arnd@arndb.de>]

On Wed, Jun 1, 2022 at 9:36 AM Yegor Yefremov
<yegorslists@googlemail.com> wrote:
> On Tue, May 31, 2022 at 5:23 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > 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

Ok, perfect, that does narrow down the problem quite a bit: The final
patch has seven changes, all of which can be done individually because
in each case the simplified version in f0191ea5c2e5 is meant to run
the exact same instructions as the version after the change, when running
on a uniprocessor machine such as your am335x.

You have already shown earlier that the get_current() and
__my_cpu_offset() functions are not to blame here, as reverting
only those does not change the behavior.

This leaves the is_smp() check in set_current(), and the
four macros in <asm/assembler.h>. I don't see anything obviously
wrong with any of those five, but I would bet on the macros
here. Can you try bisecting into this commit, maybe reverting
the changes to set_current and get_current first, and then
narrowing it down to (hopefully) a single macro that causes the
problem?

        Arnd