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
balrog_ has quit [Quit: Bye]
balrog has joined #armlinux
apritzel has quit [Ping timeout: 256 seconds]
Pali has quit [Ping timeout: 252 seconds]
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #armlinux
rfs613 has quit [Ping timeout: 240 seconds]
rfs613 has joined #armlinux
elastic_dog has quit [Ping timeout: 268 seconds]
elastic_dog has joined #armlinux
ravan_ has joined #armlinux
ravan has quit [Ping timeout: 268 seconds]
ravan has joined #armlinux
ravan has quit [Changing host]
ravan has joined #armlinux
ravan_ has quit [Ping timeout: 256 seconds]
SallyAhaj has joined #armlinux
neocow has quit [Quit: The Lounge - https://thelounge.chat]
neocow has joined #armlinux
iivanov has joined #armlinux
iivanov has quit [Quit: Leaving...]
iivanov has joined #armlinux
iivanov has quit [Quit: Leaving...]
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 268 seconds]
nsaenz has joined #armlinux
apritzel has joined #armlinux
XV8 has joined #armlinux
Pali has joined #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 ?
<geertu> ardb: Enabling LPAE unbroke shmobile_defconfig
Tokamak has joined #armlinux
Tokamak has quit [Client Quit]
<ardb> brb
<geertu> ardb: resume from s2ram works with lpae=n and nosmp
<ardb> geertu: ok
maz_ is now known as maz
gdd has joined #armlinux
gdd has quit [Ping timeout: 240 seconds]
nsaenz has joined #armlinux
headless has joined #armlinux
headless has quit [Quit: Konversation terminated!]
neocow has quit [Quit: The Lounge - https://thelounge.chat]
neocow has joined #armlinux
amitk_ has joined #armlinux
amitk has quit [Ping timeout: 240 seconds]
nsaenz has quit [Remote host closed the connection]
apritzel has joined #armlinux
ravan has quit [Ping timeout: 240 seconds]
Norkle has quit [Ping timeout: 260 seconds]
Norkle has joined #armlinux