ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
nsaenz has quit [Remote host closed the connection]
luispm has quit [Ping timeout: 240 seconds]
luispm has joined #armlinux
<ardb>
geertu: nog een vrolijk kerstfeest :-)
<ardb>
thanks for the report
<ardb>
is there any way to debug that resume path in your case?
<geertu>
ardb: Vrolijk Kerstfeest terug ;-)
<geertu>
ardb: Gonna be hard, I guess
<ardb>
geertu: yeah :-)
<ardb>
geertu: could you help me pinpoint which exact call sequence occurs on resume in your failure case?
<ardb>
one of those asm routines gets called from the platform/bootloader code?
<geertu>
arch/arm/mach-shmobile/headsmp.S is the common one
<geertu>
headsmp-apmu.S is for R-Car Gen2 (known broken)
<geertu>
platsmp-scu.S is for the older Cortex-A9 SMP machines (about to test)
<geertu>
Ok, the CA9 variant does something:
<geertu>
Enabling non-boot CPUs ...
<geertu>
g function called from invalid c.h:230
<geertu>
Note that this is on a dual CA9 platform that had SMP issues since forever (sometimes the second CPU doesn't come up at all after s2ram)
<ardb>
right
<geertu>
(but usually the system does keep working)
<geertu>
As expected, the single-core CA9 machines do s2ram fine.
<ardb>
on -next with vmap'ed stacks enabled?
<ardb>
or in general?
<geertu>
Not on next, my current tree with lots of for-next branches merged in (which will become today's renesas-drivers release later)
ardb has left #armlinux [#armlinux]
ardb has joined #armlinux
<ardb>
geertu: but does it include a1c510d0adc604bb?
<geertu>
Amazingly, my R-Car Gen2 board that fails to resume with shmobile_defconfig, does resume fine with a more board-specific config, which does hav CONFIG_HAVE_ARCH_VMAP_STACK=y
<geertu>
ardb: Sure, that one is included
<geertu>
else I wouldn't have reported an issue ;-)
<ardb>
true
<ardb>
just double checking
<ardb>
so this may be related to restarting secondaries after resume rather than suspend/resume itself
<ardb>
although the output you shared suggests otherwise :-(
<geertu>
ardb: did it? The output shows it crashes before enabling the non-boot CPUs. Yes, that's strange. I'd expect the "Enabling non-boot CPUs ..." still to be printed. Probably it was buffered.
<geertu>
So yes, restarting secondaries. Most of the CA15 SoCs have their own code to do that.
<ardb>
geertu: so the main difference is that the stack pointer now points into the vmalloc space,which means virt_to_phys() produces a bogus address
<ardb>
not sure how that affects secondary_start() only after suspend though
<geertu>
ardb: Do you have an idea why it would work with one config and not with another, with both configs having CONFIG_HAVE_ARCH_VMAP_STACK=y?
<ardb>
geertu: is shmobile_defconfig v6+v7 ?
<geertu>
ardb: Nope, v7 only (CA9, CA7, CA15)
<ardb>
geertu: ok i will need to stare at this a little bit longer
<geertu>
ardb: I'm afraid there are more platform to fix than exynos and shmobile
<geertu>
It's a bad moment of the year for such breakage...
<ardb>
geertu: do both configs have HOTPLUG_CPU enabled?
<geertu>
ardb: yes they do, I usually do all my testing with them.
<ardb>
can you send me both configs please so i can compare?
apritzel has quit [Ping timeout: 250 seconds]
<ardb>
geertu: how about LPAE ?
<geertu>
ardb: Nice catch! The working one has LPAE enabled, the non-working one hasn't.
<geertu>
lemme try...
<geertu>
ardb: Disabling LPAE breaks s2ram in the custom config
<ardb>
ok that should help narrow it down, thanks
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ardb>
geertu: and does it still work when booting with nosmp ?