Re: [Bug 203597] New: kernel 4.9.175 fails to boot on a PowerMac G4 3,6 at early stage

Hi Greg,

Could you please apply b45ba4a51cde29b2939365ef0c07ad34c8321789 to 4.9 since 51c3c62b58b357e8d35e4cc32f7b4ec907426fe3 was applied allthought marked for #4.13+

Thanks Christophe

Le 13/05/2019 à 22:18, bugzilla-daemon@bugzilla.kernel.org a écrit :

https://bugzilla.kernel.org/show_bug.cgi?id=203597

         Bug ID: 203597
        Summary: kernel 4.9.175 fails to boot on a PowerMac G4 3,6 at
                 early stage
        Product: Platform Specific/Hardware
        Version: 2.5
 Kernel Version: 4.9.175
       Hardware: PPC-32
             OS: Linux
           Tree: Mainline
         Status: NEW
       Severity: normal
       Priority: P1
      Component: PPC-32
       Assignee: platform_ppc-32@kernel-bugs.osdl.org
       Reporter: erhard_f@mailbox.org
     Regression: No

Created attachment 282743 --> https://bugzilla.kernel.org/attachment.cgi?id=282743&action=edit kernel .config (PowerMac G4 MDD)

Trying out older kernels on the G4 MDD I noticed recent 4.9.x freeze the machine. Only message displayed in black letters on a white screen:

done found display : /pco@f0000000/ATY,AlteracParent@10/ATY,Alterac_B@1, opening...

It's a hard freeze, RCU_CPU_STALL_TIMEOUT does not kick in.

Tried other stable kernels, which all worked: 4.19.37 4.14.114 4.4.179

So I suppose it's only a 4.9.x issue. Last working 4.9.x kernel I had in service was 4.9.161. First one I spotted freezing was 4.9.171. A bisect gave me the following commit:

1c38a84d45862be06ac418618981631eddbda741 is the first bad commit commit 1c38a84d45862be06ac418618981631eddbda741 Author: Michael Neuling mikey@neuling.org Date: Thu Apr 11 21:45:59 2019 +1000

 powerpc: Avoid code patching freed init sections

 commit 51c3c62b58b357e8d35e4cc32f7b4ec907426fe3 upstream.

 This stops us from doing code patching in init sections after they've
 been freed.

 In this chain:
   kvm_guest_init() ->
     kvm_use_magic_page() ->
       fault_in_pages_readable() ->
          __get_user() ->
            __get_user_nocheck() ->
              barrier_nospec();

 We have a code patching location at barrier_nospec() and
 kvm_guest_init() is an init function. This whole chain gets inlined,
 so when we free the init section (hence kvm_guest_init()), this code
 goes away and hence should no longer be patched.

 We seen this as userspace memory corruption when using a memory
 checker while doing partition migration testing on powervm (this
 starts the code patching post migration via
 /sys/kernel/mobility/migration). In theory, it could also happen when
 using /sys/kernel/debug/powerpc/barrier_nospec.

 Cc: stable@vger.kernel.org # 4.13+
 Signed-off-by: Michael Neuling <mikey@neuling.org>
 Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
 Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
 Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
 Signed-off-by: Sasha Levin <sashal@kernel.org>