[PATCH v4 7/7] ARM: implement support for vmap'ed stacks
Jon Hunter
jonathanh at nvidia.com
Wed Jan 5 03:08:38 PST 2022
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
More information about the linux-arm-kernel
mailing list