A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
Aluminum. The bootstrap loads the initial kernel and issues the appropriate
start, but the machine hangs at that point.
The problem does not depend on the choice of PPC32 processor type. This machine
has a 7447A according to /proc/cpuinfo.
The problem was bisected to the following:
commit 0df977eafc792a5365a7f81d8d5920132e03afad
Author: Christophe Leroy <[email protected]>
Date: Thu Feb 21 10:37:54 2019 +0000
powerpc/6xx: Don't use SPRN_SPRG2 for storing stack pointer while in RTAS
When calling RTAS, the stack pointer is stored in SPRN_SPRG2
in order to be able to restore it in case of machine check in RTAS.
As machine check is not a perfomance critical path, this patch
frees SPRN_SPRG2 by using a field in thread struct instead.
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
I reverted this patch and found that the system began execution, and then
failed, likely due to the reassignment of SPRN_SPRG2.
I had found this problem with 5.1.0-rc1, but -rc2 was out by the time I finished
the bisection. Unfortunately, none of the changes in -rc2 fixed the problem.
Attached is the .config that I used.
Thanks,
Larry
Le 25/03/2019 à 01:49, Larry Finger a écrit :
> A build of kernel 5.1.0-rc2 resulted in a failure to boot on my
> PowerBook G4 Aluminum. The bootstrap loads the initial kernel and issues
> the appropriate start, but the machine hangs at that point.
Can you please be more explicit ? What do you mean by "issues the
appropriate start" ? What is "that point" ? Any messages on the console ?
Thanks
Christophe
>
> The problem does not depend on the choice of PPC32 processor type. This
> machine has a 7447A according to /proc/cpuinfo.
>
> The problem was bisected to the following:
>
> commit 0df977eafc792a5365a7f81d8d5920132e03afad
> Author: Christophe Leroy <[email protected]>
> Date: Thu Feb 21 10:37:54 2019 +0000
>
> powerpc/6xx: Don't use SPRN_SPRG2 for storing stack pointer while
> in RTAS
>
> When calling RTAS, the stack pointer is stored in SPRN_SPRG2
> in order to be able to restore it in case of machine check in RTAS.
>
> As machine check is not a perfomance critical path, this patch
> frees SPRN_SPRG2 by using a field in thread struct instead.
>
> Signed-off-by: Christophe Leroy <[email protected]>
> Signed-off-by: Michael Ellerman <[email protected]>
>
> I reverted this patch and found that the system began execution, and
> then failed, likely due to the reassignment of SPRN_SPRG2.
>
> I had found this problem with 5.1.0-rc1, but -rc2 was out by the time I
> finished the bisection. Unfortunately, none of the changes in -rc2 fixed
> the problem.
>
> Attached is the .config that I used.
>
> Thanks,
>
> Larry
Le 25/03/2019 à 01:49, Larry Finger a écrit :
> A build of kernel 5.1.0-rc2 resulted in a failure to boot on my
> PowerBook G4 Aluminum. The bootstrap loads the initial kernel and issues
> the appropriate start, but the machine hangs at that point.
>
> The problem does not depend on the choice of PPC32 processor type. This
> machine has a 7447A according to /proc/cpuinfo.
>
> The problem was bisected to the following:
>
> commit 0df977eafc792a5365a7f81d8d5920132e03afad
> Author: Christophe Leroy <[email protected]>
> Date: Thu Feb 21 10:37:54 2019 +0000
>
> powerpc/6xx: Don't use SPRN_SPRG2 for storing stack pointer while
> in RTAS
>
> When calling RTAS, the stack pointer is stored in SPRN_SPRG2
> in order to be able to restore it in case of machine check in RTAS.
>
> As machine check is not a perfomance critical path, this patch
> frees SPRN_SPRG2 by using a field in thread struct instead.
>
> Signed-off-by: Christophe Leroy <[email protected]>
> Signed-off-by: Michael Ellerman <[email protected]>
>
> I reverted this patch and found that the system began execution, and
> then failed, likely due to the reassignment of SPRN_SPRG2.
>
> I had found this problem with 5.1.0-rc1, but -rc2 was out by the time I
> finished the bisection. Unfortunately, none of the changes in -rc2 fixed
> the problem.
I think I identified the issue, see
https://patchwork.ozlabs.org/patch/1063962/
It is now booting properly under QEMU with your .config
Could you please test it on your target ?
Thanks
Christophe
>
> Attached is the .config that I used.
>
> Thanks,
>
> Larry
On 3/25/19 1:53 AM, Christophe Leroy wrote:
>
>
> Le 25/03/2019 à 01:49, Larry Finger a écrit :
>> A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
>> Aluminum. The bootstrap loads the initial kernel and issues the appropriate
>> start, but the machine hangs at that point.
>
> Can you please be more explicit ? What do you mean by "issues the appropriate
> start" ? What is "that point" ? Any messages on the console ?
Sorry to be unclear. The bootstrap code prints a line saying "Booting Linux via
__start() @ 0x00c00000" and then hangs.
Your idea of confusion between physical and virtual address sounds right. I am
building a kernel with that patch applied now. As it seems to be going quickly,
I should have the answer fairly quickly.
Thanks,
Larry
On 3/25/19 3:46 AM, Christophe Leroy wrote:
>
>
> Le 25/03/2019 à 01:49, Larry Finger a écrit :
>> A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
>> Aluminum. The bootstrap loads the initial kernel and issues the appropriate
>> start, but the machine hangs at that point.
>>
>> The problem does not depend on the choice of PPC32 processor type. This
>> machine has a 7447A according to /proc/cpuinfo.
>>
>> The problem was bisected to the following:
>>
>> commit 0df977eafc792a5365a7f81d8d5920132e03afad
>> Author: Christophe Leroy <[email protected]>
>> Date: Thu Feb 21 10:37:54 2019 +0000
>>
>> powerpc/6xx: Don't use SPRN_SPRG2 for storing stack pointer while in RTAS
>>
>> When calling RTAS, the stack pointer is stored in SPRN_SPRG2
>> in order to be able to restore it in case of machine check in RTAS.
>>
>> As machine check is not a perfomance critical path, this patch
>> frees SPRN_SPRG2 by using a field in thread struct instead.
>>
>> Signed-off-by: Christophe Leroy <[email protected]>
>> Signed-off-by: Michael Ellerman <[email protected]>
>>
>> I reverted this patch and found that the system began execution, and then
>> failed, likely due to the reassignment of SPRN_SPRG2.
>>
>> I had found this problem with 5.1.0-rc1, but -rc2 was out by the time I
>> finished the bisection. Unfortunately, none of the changes in -rc2 fixed the
>> problem.
>
> I think I identified the issue, see https://patchwork.ozlabs.org/patch/1063962/
>
> It is now booting properly under QEMU with your .config
>
> Could you please test it on your target ?
Thanks. That patch fixes the issue.
Larry