Bug 203839

Created attachment 283137 [details]
failed boot, screenshot 5.2-rc1

Created attachment 283139 [details]
kernel .config (5.2-rc3, G4 MDD)

Could you try and revert the following commits ?

38b4564cf042 powerpc/32: don't do syscall stuff in transfer_to_handler
1a4b739bbb4f powerpc/32: implement fast entry for syscalls on BOOKE
b86fb88855ea powerpc/32: implement fast entry for syscalls on non BOOKE

Thanks
Christophe

On 06/07/2019 12:03 AM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=203839
> 
> --- Comment #2 from Erhard F. (erhard_f@mailbox.org) ---
> Created attachment 283139 [details]
>    --> https://bugzilla.kernel.org/attachment.cgi?id=283139&action=edit
> kernel .config (5.2-rc3, G4 MDD)
>

Created attachment 283163 [details]
failed boot, screenshot 5.2-rc3+

After reverting the 3 commits on top of v5.2-rc3 the kernel panics at an earlier stage with:

Kernel panic - not syncing: Requested init /lib/systemd/systemd failed (error -8)


# LC_MESSAGES=C git status
HEAD detached at v5.2-rc3
You are currently reverting commit b86fb88855ea.
  (all conflicts fixed: run "git revert --continue")
  (use "git revert --abort" to cancel the revert operation)

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   arch/powerpc/kernel/entry_32.S
	modified:   arch/powerpc/kernel/head_32.S
	modified:   arch/powerpc/kernel/head_32.h
	modified:   arch/powerpc/kernel/head_40x.S
	modified:   arch/powerpc/kernel/head_44x.S
	modified:   arch/powerpc/kernel/head_8xx.S
	modified:   arch/powerpc/kernel/head_booke.h
	modified:   arch/powerpc/kernel/head_fsl_booke.S

Then the problem is not due to the rework of syscalls.

Are you able to bisect ?

Created attachment 283183 [details]
bisect.log

bisect took me a while due to quite some skips. Cherry-picking 397d2300b08cdee052053e362018cdb6dd65eea2 and 305d60012304684bd59ea1f67703e51662e4906a helped me complete it.

# git bisect good | tee -a /root/bisect02.log
215b823707ce4e8e52b106915f70357fa474c669 is the first bad commit
commit 215b823707ce4e8e52b106915f70357fa474c669
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date:   Fri Apr 26 16:23:36 2019 +0000

    powerpc/32s: set up an early static hash table for KASAN.
    
    KASAN requires early activation of hash table, before memblock()
    functions are available.
    
    This patch implements an early hash_table statically defined in
    __initdata.
    
    During early boot, a single page table is used.
    
    For hash32, when doing the final init, one page table is allocated
    for each PGD entry because of the _PAGE_HASHPTE flag which can't be
    common to several virt pages. This is done after memblock get
    available but before switching to the final hash table, otherwise
    there are issues with TLB flushing due to the shared entries.
    
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

:040000 040000 abc24eb3c4ad3e4f2b1eb7b52c295c8b95d79a78 c3b6114c26eb8e181abb3f1abc9b6ecc12292f4d M	arch

Created attachment 283185 [details]
kernel .config (5.1.0-rc3+, G4 MDD)

Argh !

CONFIG_SMP must (again) be the reason we missed it.

Can you please try the change below ?

diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 1d5f1bd0dacd..f255e22184b4 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -752,6 +752,7 @@ __secondary_start:
  	stw	r0,0(r3)

  	/* load up the MMU */
+	bl	load_segment_registers
  	bl	load_up_mmu

  	/* ptr to phys current thread */

Thanks
Christophe

On 06/11/2019 12:32 AM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=203839
> 
> --- Comment #6 from Erhard F. (erhard_f@mailbox.org) ---
> Created attachment 283183 [details]
>    --> https://bugzilla.kernel.org/attachment.cgi?id=283183&action=edit
> bisect.log
> 
> bisect took me a while due to quite some skips. Cherry-picking
> 397d2300b08cdee052053e362018cdb6dd65eea2 and
> 305d60012304684bd59ea1f67703e51662e4906a helped me complete it.
> 
> # git bisect good | tee -a /root/bisect02.log
> 215b823707ce4e8e52b106915f70357fa474c669 is the first bad commit
> commit 215b823707ce4e8e52b106915f70357fa474c669
> Author: Christophe Leroy <christophe.leroy@c-s.fr>
> Date:   Fri Apr 26 16:23:36 2019 +0000
> 
>      powerpc/32s: set up an early static hash table for KASAN.
> 
>      KASAN requires early activation of hash table, before memblock()
>      functions are available.
> 
>      This patch implements an early hash_table statically defined in
>      __initdata.
> 
>      During early boot, a single page table is used.
> 
>      For hash32, when doing the final init, one page table is allocated
>      for each PGD entry because of the _PAGE_HASHPTE flag which can't be
>      common to several virt pages. This is done after memblock get
>      available but before switching to the final hash table, otherwise
>      there are issues with TLB flushing due to the shared entries.
> 
>      Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>      Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> 
> :040000 040000 abc24eb3c4ad3e4f2b1eb7b52c295c8b95d79a78
> c3b6114c26eb8e181abb3f1abc9b6ecc12292f4d M      arch
>

(In reply to Christophe Leroy from comment #8)
> Argh !
> 
> CONFIG_SMP must (again) be the reason we missed it.
> 
> Can you please try the change below ?
Applied your change on top of 5.2-rc4. The G4 boots fine again, thanks!

The fix meanwhile found it's way in kernel 5.2-rc7 which boots just fine. Thanks!

Fixed in b7f8b440f300 ("powerpc/32s: fix initial setup of segment registers on secondary CPU")