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

bugzilla-daemon at bugzilla.kernel.org bugzilla-daemon at bugzilla.kernel.org
Tue May 14 06:18:03 AEST 2019


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 at kernel-bugs.osdl.org
          Reporter: erhard_f at 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 at f0000000/ATY,AlteracParent at 10/ATY,Alterac_B at 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 at 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 at vger.kernel.org # 4.13+
    Signed-off-by: Michael Neuling <mikey at neuling.org>
    Reviewed-by: Nicholas Piggin <npiggin at gmail.com>
    Reviewed-by: Christophe Leroy <christophe.leroy at c-s.fr>
    Signed-off-by: Michael Ellerman <mpe at ellerman.id.au>
    Signed-off-by: Sasha Levin <sashal at kernel.org>

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


More information about the Linuxppc-dev mailing list