Created attachment 283135 [details] failed boot, screenshot 5.2-rc3 The system boots fine with kernel 5.1.7. Starting with 5.2-rc1 the G4 got problems to correctly finish booting. With 5.2-rc3 basic boot process seems to complete, but crashes when handing control over to systemd: systemd[1]: Failed to bump fs.file-max, ignoring: invalid argument systemd[1]: segfault (11) at 0 nip 0 ir 0 code 1 systemd[1]: Bad NIP, not dumping instructions [...] For more details see the screenshot. Kernel 5.2-rc1 errors out even earlier (see screenshot) with a different error. Also this problem maybe is 32bit specific. Tried 5.2-rc3 on a PowerMac G5 which boots successfully without problems. root is ext4, boot is ext2, systemd is v241.
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")