Re: [PATCH v4 7/7] ARM: implement support for vmap'ed stacks

[Jon Hunter <jonathanh@nvidia.com>]

Hi Ard,

On 28/12/2021 14:39, Geert Uytterhoeven wrote:

...

>> As i don't have access to this hardware, I am going to have to rely on
>> someone who does to debug this further. The only alternative is
>> marking CONFIG_VMAP_STACK broken on MACH_EXYNOS but that would be
>> unfortunate.
> 
> Wish I had seen this thread before...
> 
> I've just bisected a resume after s2ram failure on R-Car Gen2 to the same
> commit a1c510d0adc604bb ("ARM: implement support for vmap'ed stacks")
> in arm/for-next.
> 
> Expected output:
> 
>      PM: suspend entry (deep)
>      Filesystems sync: 0.000 seconds
>      Freezing user space processes ... (elapsed 0.010 seconds) done.
>      OOM killer disabled.
>      Freezing remaining freezable tasks ... (elapsed 0.009 seconds) done.
>      Disabling non-boot CPUs ...
> 
> [system suspended, this is also where it hangs on failure]
> 
>      Enabling non-boot CPUs ...
>      CPU1 is up
>      sh-eth ee700000.ethernet eth0: Link is Down
>      Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
> driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=193)
>      OOM killer enabled.
>      Restarting tasks ... done.
>      PM: suspend exit
> 
> Both wake-on-LAN and wake-up by gpio-keys fail.
> Nothing interesting in the kernel log, cfr. above.
> 
> Disabling CONFIG_VMAP_STACK fixes the issue for me.
> 
> Just like arch/arm/mach-exynos/ (and others), arch/arm/mach-shmobile/
> has several *.S files related to secondary CPU bringup.


This is also breaking suspend on our 32-bit Tegra platforms. Reverting 
this change on top of -next fixes the problem.

Cheers
Jon

-- 
nvpublic