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
