From: Christian Kujau <hidden> Date: 2016-08-09 05:26:58
Hi,
while trying to upgrade this PowerBook G4 from 4.7-rc7 to 4.8-rc1, it's
unable to boot the Yaboot (v1.3.16 from Debian/stable) boot loader:
================================================================
copying OF device tree...
Building dt strings...
Building dt stucture...
Device tree strings 0x01e72000 -> 0x01e73615
Device tree struct 0x01e74000 -> 0x01e7e000
Quiescing Open Firmware...
Bootng Linux via __start()...
Invalid memory access at $SRR0: 0140f86c $SRR1: 00003030
Apple PowerBook6,8 4.9.0f0 BootROM built on 01/10/05 at 10:39:14
[...]
ok
0:> _
================================================================
Going back to 4.7-rc7 (w/o installing Yaboot again) works just fine. The
config is mostly the same (used "make oldconfig" from 4.7), but I've said
YES to CONFIG_SLAB_FREELIST_RANDOM - could this be causing the boot
failure? Full .config and screen shot: http://nerdbynature.de/bits/4.8.0-rc1/
Thanks,
Christian.
--
BOFH excuse #319:
Your computer hasn't been returning all the bits it gets from the Internet.
From: Christian Kujau <hidden> Date: 2016-08-09 09:06:51
On Mon, 8 Aug 2016, Christian Kujau wrote:
while trying to upgrade this PowerBook G4 from 4.7-rc7 to 4.8-rc1, it's
unable to boot the Yaboot (v1.3.16 from Debian/stable) boot loader:
================================================================
copying OF device tree...
Building dt strings...
Building dt stucture...
Device tree strings 0x01e72000 -> 0x01e73615
Device tree struct 0x01e74000 -> 0x01e7e000
Quiescing Open Firmware...
Bootng Linux via __start()...
Invalid memory access at $SRR0: 0140f86c $SRR1: 00003030
Apple PowerBook6,8 4.9.0f0 BootROM built on 01/10/05 at 10:39:14
[...]
ok
0:> _
================================================================
Going back to 4.7-rc7 (w/o installing Yaboot again) works just fine. The
config is mostly the same (used "make oldconfig" from 4.7), but I've said
YES to CONFIG_SLAB_FREELIST_RANDOM - could this be causing the boot
failure? Full .config and screen shot: http://nerdbynature.de/bits/4.8.0-rc1/
A git-bisect led me to:
=========================================
commit 9402c684613163888714df0955fa1f17142b08bf
Author: Benjamin Herrenschmidt [off-list ref]
Date: Tue Jul 5 15:03:41 2016 +1000
powerpc: Factor do_feature_fixup calls
32 and 64-bit do a similar set of calls early on, we move it all to
a single common function to make the boot code more readable.
Signed-off-by: Benjamin Herrenschmidt [off-list ref]
Signed-off-by: Michael Ellerman [off-list ref]
=========================================
But I'm unable to revert just this patch:
$ git revert 9402c684613163888714df0955fa1f17142b08bf
error: could not revert 9402c68... powerpc: Factor do_feature_fixup calls
hint: after resolving the conflicts, mark the corrected paths
The bisect-log:
=========================================
$ git bisect log
git bisect start '--' 'arch/powerpc'
# good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect good 523d939ef98fd712632d93a5a2b588e477a7565e
# bad: [29b4817d4018df78086157ea3a55c1d9424a7cfc] Linux 4.8-rc1
git bisect bad 29b4817d4018df78086157ea3a55c1d9424a7cfc
# bad: [3808a88985b4f5f5e947c364debce4441a380fb8] powerpc: Move FW feature probing out of pseries probe()
git bisect bad 3808a88985b4f5f5e947c364debce4441a380fb8
# good: [a203658b5ed37c11e5016d3fbbbab9ce018c1b78] powerpc/opal: Wake up kopald polling thread before waiting for events
git bisect good a203658b5ed37c11e5016d3fbbbab9ce018c1b78
# good: [0dfffb48cecd8f84c6e649baee9bacd9be925734] powerpc/powernv: abstraction for saving SPRs before entering deep idle states
git bisect good 0dfffb48cecd8f84c6e649baee9bacd9be925734
# good: [66c570f545e056babdd9510595ce762dcedadd71] powerpc/mm: use _raw variant of page table accessors
git bisect good 66c570f545e056babdd9510595ce762dcedadd71
# good: [c2ca9f6b4cc4c45eb598b24b8b06beee668052d5] powerpc/powernv: Fix pci-cxl.c build when CONFIG_MODULES=n
git bisect good c2ca9f6b4cc4c45eb598b24b8b06beee668052d5
# good: [4c91bd6eeabb004f283db8a6854b134e2a2de1bc] powerpc: Merge the RELOCATABLE config entries for ppc32 and ppc64
git bisect good 4c91bd6eeabb004f283db8a6854b134e2a2de1bc
# bad: [c4bd6cb87c9e28a7d9f4a97db5a06cc538eb5e48] powerpc: Move 64-bit feature fixup earlier
git bisect bad c4bd6cb87c9e28a7d9f4a97db5a06cc538eb5e48
# bad: [9402c684613163888714df0955fa1f17142b08bf] powerpc: Factor do_feature_fixup calls
git bisect bad 9402c684613163888714df0955fa1f17142b08bf
# good: [27d1149667352772240655b65372a4294f992ea7] powerpc/32: Remove RELOCATABLE_PPC32
git bisect good 27d1149667352772240655b65372a4294f992ea7
# first bad commit: [9402c684613163888714df0955fa1f17142b08bf] powerpc: Factor do_feature_fixup calls
=========================================
HTH,
Christian.
--
BOFH excuse #409:
The vulcan-death-grip ping has been applied.
================================================================
copying OF device tree...
Building dt strings...
Building dt stucture...
Device tree strings 0x01e72000 -> 0x01e73615
Device tree struct 0x01e74000 -> 0x01e7e000
Quiescing Open Firmware...
Bootng Linux via __start()...
Invalid memory access at $SRR0: 0140f86c $SRR1: 00003030
Apple PowerBook6,8 4.9.0f0 BootROM built on 01/10/05 at 10:39:14
[...]
ok
0:> _
================================================================
Going back to 4.7-rc7 (w/o installing Yaboot again) works just
fine. The
config is mostly the same (used "make oldconfig" from 4.7), but
I've said
YES to CONFIG_SLAB_FREELIST_RANDOM - could this be causing the
boot
failure? Full .config and screen shot: http://nerdbynature.de/bits/
4.8.0-rc1/
A git-bisect led me to:
=========================================
commit 9402c684613163888714df0955fa1f17142b08bf
Author: Benjamin Herrenschmidt [off-list ref]
Date: Tue Jul 5 15:03:41 2016 +1000
powerpc: Factor do_feature_fixup calls
32 and 64-bit do a similar set of calls early on, we move it all
to
a single common function to make the boot code more readable.
Signed-off-by: Benjamin Herrenschmidt [off-list ref]
Signed-off-by: Michael Ellerman [off-list ref]
=========================================
But I'm unable to revert just this patch:
$ git revert 9402c684613163888714df0955fa1f17142b08bf
error: could not revert 9402c68... powerpc: Factor do_feature_fixup
calls
hint: after resolving the conflicts, mark the corrected paths
The bisect-log:
=========================================
$ git bisect log
git bisect start '--' 'arch/powerpc'
# good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect good 523d939ef98fd712632d93a5a2b588e477a7565e
# bad: [29b4817d4018df78086157ea3a55c1d9424a7cfc] Linux 4.8-rc1
git bisect bad 29b4817d4018df78086157ea3a55c1d9424a7cfc
# bad: [3808a88985b4f5f5e947c364debce4441a380fb8] powerpc: Move FW
feature probing out of pseries probe()
git bisect bad 3808a88985b4f5f5e947c364debce4441a380fb8
# good: [a203658b5ed37c11e5016d3fbbbab9ce018c1b78] powerpc/opal: Wake
up kopald polling thread before waiting for events
git bisect good a203658b5ed37c11e5016d3fbbbab9ce018c1b78
# good: [0dfffb48cecd8f84c6e649baee9bacd9be925734] powerpc/powernv:
abstraction for saving SPRs before entering deep idle states
git bisect good 0dfffb48cecd8f84c6e649baee9bacd9be925734
# good: [66c570f545e056babdd9510595ce762dcedadd71] powerpc/mm: use
_raw variant of page table accessors
git bisect good 66c570f545e056babdd9510595ce762dcedadd71
# good: [c2ca9f6b4cc4c45eb598b24b8b06beee668052d5] powerpc/powernv:
Fix pci-cxl.c build when CONFIG_MODULES=n
git bisect good c2ca9f6b4cc4c45eb598b24b8b06beee668052d5
# good: [4c91bd6eeabb004f283db8a6854b134e2a2de1bc] powerpc: Merge the
RELOCATABLE config entries for ppc32 and ppc64
git bisect good 4c91bd6eeabb004f283db8a6854b134e2a2de1bc
# bad: [c4bd6cb87c9e28a7d9f4a97db5a06cc538eb5e48] powerpc: Move 64-
bit feature fixup earlier
git bisect bad c4bd6cb87c9e28a7d9f4a97db5a06cc538eb5e48
# bad: [9402c684613163888714df0955fa1f17142b08bf] powerpc: Factor
do_feature_fixup calls
git bisect bad 9402c684613163888714df0955fa1f17142b08bf
# good: [27d1149667352772240655b65372a4294f992ea7] powerpc/32: Remove
RELOCATABLE_PPC32
git bisect good 27d1149667352772240655b65372a4294f992ea7
# first bad commit: [9402c684613163888714df0955fa1f17142b08bf]
powerpc: Factor do_feature_fixup calls
=========================================
HTH,
Christian.
2c0f99516f539 ("powerpc/32: Fix early access to cpu_spec relocation") is
in mainline, but my machine is still unable to boot, same error, different address:
> Invalid memory access at $SRR0: 0121686c $SRR1: 00003030
Happy to test more patches :-)
Christian.
It should be in Michael's tree if not already in Linus.
Cheers,
Ben.
quoted
quoted
================================================================
copying OF device tree...
Building dt strings...
Building dt stucture...
Device tree strings 0x01e72000 -> 0x01e73615
Device tree struct 0x01e74000 -> 0x01e7e000
Quiescing Open Firmware...
Bootng Linux via __start()...
Invalid memory access at $SRR0: 0140f86c $SRR1: 00003030
Apple PowerBook6,8 4.9.0f0 BootROM built on 01/10/05 at 10:39:14
[...]
ok
0:> _
================================================================
Going back to 4.7-rc7 (w/o installing Yaboot again) works just
fine. The
config is mostly the same (used "make oldconfig" from 4.7), but
I've said
YES to CONFIG_SLAB_FREELIST_RANDOM - could this be causing the
boot
failure? Full .config and screen shot: http://nerdbynature.de/bits/
4.8.0-rc1/
A git-bisect led me to:
=========================================
commit 9402c684613163888714df0955fa1f17142b08bf
Author: Benjamin Herrenschmidt [off-list ref]
Date: Tue Jul 5 15:03:41 2016 +1000
powerpc: Factor do_feature_fixup calls
32 and 64-bit do a similar set of calls early on, we move it all
to
a single common function to make the boot code more readable.
Signed-off-by: Benjamin Herrenschmidt [off-list ref]
Signed-off-by: Michael Ellerman [off-list ref]
=========================================
But I'm unable to revert just this patch:
$ git revert 9402c684613163888714df0955fa1f17142b08bf
error: could not revert 9402c68... powerpc: Factor do_feature_fixup
calls
hint: after resolving the conflicts, mark the corrected paths
The bisect-log:
=========================================
$ git bisect log
git bisect start '--' 'arch/powerpc'
# good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect good 523d939ef98fd712632d93a5a2b588e477a7565e
# bad: [29b4817d4018df78086157ea3a55c1d9424a7cfc] Linux 4.8-rc1
git bisect bad 29b4817d4018df78086157ea3a55c1d9424a7cfc
# bad: [3808a88985b4f5f5e947c364debce4441a380fb8] powerpc: Move FW
feature probing out of pseries probe()
git bisect bad 3808a88985b4f5f5e947c364debce4441a380fb8
# good: [a203658b5ed37c11e5016d3fbbbab9ce018c1b78] powerpc/opal: Wake
up kopald polling thread before waiting for events
git bisect good a203658b5ed37c11e5016d3fbbbab9ce018c1b78
# good: [0dfffb48cecd8f84c6e649baee9bacd9be925734] powerpc/powernv:
abstraction for saving SPRs before entering deep idle states
git bisect good 0dfffb48cecd8f84c6e649baee9bacd9be925734
# good: [66c570f545e056babdd9510595ce762dcedadd71] powerpc/mm: use
_raw variant of page table accessors
git bisect good 66c570f545e056babdd9510595ce762dcedadd71
# good: [c2ca9f6b4cc4c45eb598b24b8b06beee668052d5] powerpc/powernv:
Fix pci-cxl.c build when CONFIG_MODULES=n
git bisect good c2ca9f6b4cc4c45eb598b24b8b06beee668052d5
# good: [4c91bd6eeabb004f283db8a6854b134e2a2de1bc] powerpc: Merge the
RELOCATABLE config entries for ppc32 and ppc64
git bisect good 4c91bd6eeabb004f283db8a6854b134e2a2de1bc
# bad: [c4bd6cb87c9e28a7d9f4a97db5a06cc538eb5e48] powerpc: Move 64-
bit feature fixup earlier
git bisect bad c4bd6cb87c9e28a7d9f4a97db5a06cc538eb5e48
# bad: [9402c684613163888714df0955fa1f17142b08bf] powerpc: Factor
do_feature_fixup calls
git bisect bad 9402c684613163888714df0955fa1f17142b08bf
# good: [27d1149667352772240655b65372a4294f992ea7] powerpc/32: Remove
RELOCATABLE_PPC32
git bisect good 27d1149667352772240655b65372a4294f992ea7
# first bad commit: [9402c684613163888714df0955fa1f17142b08bf]
powerpc: Factor do_feature_fixup calls
=========================================
HTH,
Christian.
--
BOFH excuse #62:
need to wrap system in aluminum foil to fix problem
=20
That fix is in rc1, so this must be a different bug.
Does the git bisect help?
No it doesn't sorry.
Because as soon as you bisected prior to that fix, you would have been
hitting the bug fixed by that commit.
To make the bisect work you need to try and apply the above fix at every
stage with patch. If the point you're bisecting already has the fix then
obviously you don't need to apply it again. You then build the kernel,
test it, and unapply the patch before doing git bisect good/bad.
eg.
$ git bisect start
$ git bisect good xxx
$ git bisect bad yyy
<checks out some version>
$ git show 2c0f99516f53 | patch -p1
$ make
... test kernel ....
$ git reset --hard
$ git bisect good/bad
...
cheers
That fix is in rc1, so this must be a different bug.
It's all the jump label cruft that landed in apply_feature_fixups()
You can't call random call there. On ppc32, it's running in that
weirdo environment where the kernel isn't running at its linked
address and we need to manually RELOC() everything.
I'm moving them to a separate init call, patch on its way...
Cheers,
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2016-08-10 07:28:11
We cannot do those initializations from apply_feature_fixups() as
this function runs in a very restricted environment in 32-bit where
the kernel isn't running at its linked address and the PTRRELOC()
macro must be used for any global accesss.
Instead, split them into a separtate steup_feature_keys() function
which is called in a more suitable spot on ppc32.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
@@ -102,6 +102,9 @@ extern unsigned int memset_nocache_branch; /* Insn to be replaced by NOP */notracevoid__initmachine_init(u64dt_ptr){+/* Configure static keys first */+setup_feature_keys();+/* Enable early debugging if any specified (see udbg.h) */udbg_early_init();
@@ -300,6 +300,7 @@ void __init early_setup(unsigned long dt_ptr)/* Apply all the dynamic patching */apply_feature_fixups();+setup_feature_keys();/* Initialize the hash table or TLB handling */early_init_mmu();
From: Christian Kujau <hidden> Date: 2016-08-10 08:18:02
On Wed, 10 Aug 2016, Benjamin Herrenschmidt wrote:
We cannot do those initializations from apply_feature_fixups() as
this function runs in a very restricted environment in 32-bit where
the kernel isn't running at its linked address and the PTRRELOC()
macro must be used for any global accesss.
Instead, split them into a separtate steup_feature_keys() function
which is called in a more suitable spot on ppc32.
Wow, cool. With that applied (on top of mainline from some minutes ago),
this PowerPC G4 boots again. Thanks!
Tested-by: Christian Kujau [off-list ref]
@Michael: thanks for the git-bisect tutorial, although I'm glad that I was
able to skip it this time.
Christian.
quoted hunk
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
@@ -102,6 +102,9 @@ extern unsigned int memset_nocache_branch; /* Insn to be replaced by NOP */notracevoid__initmachine_init(u64dt_ptr){+/* Configure static keys first */+setup_feature_keys();+/* Enable early debugging if any specified (see udbg.h) */udbg_early_init();
@@ -300,6 +300,7 @@ void __init early_setup(unsigned long dt_ptr)/* Apply all the dynamic patching */apply_feature_fixups();+setup_feature_keys();/* Initialize the hash table or TLB handling */early_init_mmu();
From: Gabriel Paubert <hidden> Date: 2016-08-10 09:27:43
On Wed, Aug 10, 2016 at 01:17:55AM -0700, Christian Kujau wrote:
On Wed, 10 Aug 2016, Benjamin Herrenschmidt wrote:
quoted
We cannot do those initializations from apply_feature_fixups() as
this function runs in a very restricted environment in 32-bit where
the kernel isn't running at its linked address and the PTRRELOC()
macro must be used for any global accesss.
Instead, split them into a separtate steup_feature_keys() function
which is called in a more suitable spot on ppc32.
Wow, cool. With that applied (on top of mainline from some minutes ago),
this PowerPC G4 boots again. Thanks!
Just a question, does sleep work on your PowerBook?
It has been broken for several releases of the kernel on mine, but I've not
had time to investigate it and it might also be a distro/systemd issue.
Regards,
Gabriel
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2016-08-10 09:33:56
Benjamin Herrenschmidt [off-list ref] writes:
It's all the jump label cruft that landed in=C2=A0apply_feature_fixups()
You can't call random call there. On ppc32, it's running in that
weirdo environment where the kernel isn't running at its linked
address and we need to manually RELOC() everything.
Crud. My qemu-mac99 boot test should have caught it, but of course
pmac32 defconfig doesn't enable JUMP_LABEL >:E
I'm moving them to a separate init call, patch on its way...
From: Christian Kujau <hidden> Date: 2016-08-11 00:25:43
On Wed, 10 Aug 2016, Gabriel Paubert wrote:
Just a question, does sleep work on your PowerBook?
Oh, this PowerBook is on 24/7, it's a small home server and I don't think
I ever used any sleep or hibernation modes on this machine. Sorry :\
C.
--
BOFH excuse #145:
Flat tire on station wagon with tapes. ("Never underestimate the bandwidth of a station wagon full of tapes hurling down the highway" Andrew S. Tannenbaum)
From: Michael Ellerman <hidden> Date: 2016-08-11 11:16:44
On Wed, 2016-10-08 at 07:27:34 UTC, Benjamin Herrenschmidt wrote:
We cannot do those initializations from apply_feature_fixups() as
this function runs in a very restricted environment in 32-bit where
the kernel isn't running at its linked address and the PTRRELOC()
macro must be used for any global accesss.
Instead, split them into a separtate steup_feature_keys() function
which is called in a more suitable spot on ppc32.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>