Re: am335x: 5.18.x: system stalling

[Yegor Yefremov <yegorslists@googlemail.com>]

On Fri, May 27, 2022 at 10:39 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, May 27, 2022 at 10:17 AM Yegor Yefremov
> <yegorslists@googlemail.com> wrote:
> > On Fri, May 27, 2022 at 8:57 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Fri, May 27, 2022 at 8:50 AM Tony Lindgren <tony@atomide.com> wrote:
> > > > * Arnd Bergmann <arnd@arndb.de> [220527 06:35]:
> > > > > On Fri, May 27, 2022 at 6:44 AM Yegor Yefremov <yegorslists@googlemail.com> wrote:
> > > > > > On Thu, May 26, 2022 at 4:16 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > > Based on what we just discussed on #armlinux, testing before and after
> > > > commit 9c46929e7989 ("ARM: implement THREAD_INFO_IN_TASK for uniprocessor
> > > > systems") might be a good idea as it enables some config options that
> > > > did not get enabled earlier.
> > > >
> > > > Another thing that might help is to bisect again and ensure vmap stack
> > > > config option stays disabled so issues related to vmap stack are kept
> > > > out of the way.
> > >
> > > Unfortunately the commits around 9c46929e7989 are the ones that failed
> > > to build according to the original report. But it's possible that the
> > > problem has something to do with
> > > CONFIG_CURRENT_POINTER_IN_TPIDRURO, which is disabled
> > > in the V6+SMP config, and which in turn is required for
> > > THREAD_INFO_IN_TASK, IRQSTACKS and STACKPROTECTOR_PER_TASK.
> > >
> > > If any of the four are the cause of the stall, then turning off ARCH_OMAP2 and
> > > CONFIG_CPU_V6 should show the same bug in older commits as well.
> >
> > Both config options disabled:
> >
> > # zcat /proc/config.gz | grep 'CONFIG_ARCH_MULTI_V6\|CONFIG_SMP'
> > # CONFIG_ARCH_MULTI_V6 is not set
> > CONFIG_ARCH_MULTI_V6_V7=y
> > # CONFIG_SMP is not set
> >
> > This helped - no stalls.
>
> Ok, that does point back to a recent regression then, rather than something
> that was already broken and just uncovered by the changed behavior.
>
> Can you try the other combinations as well? OMAP2=y with SMP=n
> and OMAP2=n with SMP=y? Hopefully that narrows it down enough that
> we can look at which code paths actually changed.

# zcat /proc/config.gz | grep 'CONFIG_ARCH_MULTI_V6\|CONFIG_SMP'
# CONFIG_ARCH_MULTI_V6 is not set
CONFIG_ARCH_MULTI_V6_V7=y
CONFIG_SMP=y
CONFIG_SMP_ON_UP=y

No stalls.

# zcat /proc/config.gz | grep 'CONFIG_ARCH_MULTI_V6\|CONFIG_SMP\|ARCH_OMAP2'
CONFIG_ARCH_MULTI_V6=y
CONFIG_ARCH_MULTI_V6_V7=y
CONFIG_ARCH_OMAP2=y
CONFIG_ARCH_OMAP2PLUS=y
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y

No stalls.

As soon as I enable both SMP and OMAP2 options the system stalls.

Yegor


# CONFIG_SMP is not set