1. 31 8月, 2017 11 次提交
    • D
      powerpc/83xx: Use sizeof correct type when ioremapping · c6554045
      Dan Carpenter 提交于
      There is a cut and paste error here so we use sizeof(struct mpc83xx_pmc)
      to remap the memory for "clock_regs". That sizeof() is 20 bytes and we
      only need to remap 12 bytes. It presumably doesn't affect run time too
      much...
      
      I changed them to both use sizeof(*variable_name) because that's the
      preferred kernel style these days.
      
      Fixes: d49747bd ("powerpc/mpc83xx: Power Management support")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      [mpe: It will map at least one page anyway, but still a good cleanup]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      c6554045
    • N
      powerpc: Machine check interrupt is a non-maskable interrupt · b96672dd
      Nicholas Piggin 提交于
      Use nmi_enter similarly to system reset interrupts. This uses NMI
      printk NMI buffers and turns off various debugging facilities that
      helps avoid tripping on ourselves or other CPUs.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b96672dd
    • N
      powerpc/powernv: Use kernel crash path for machine checks · 6fcd6baa
      Nicholas Piggin 提交于
      There are quite a few machine check exceptions that can be caused by
      kernel bugs. To make debugging easier, use the kernel crash path in
      cases of synchronous machine checks that occur in kernel mode, if that
      would not result in the machine going straight to panic or crash dump.
      
      There is a downside here that die()ing the process in kernel mode can
      still leave the system unstable. panic_on_oops will always force the
      system to fail-stop, so systems where that behaviour is important will
      still do the right thing.
      
      As a test, when triggering an i-side 0111b error (ifetch from foreign
      address) in kernel mode process context on POWER9, the kernel currently
      dies quickly like this:
      
        Severe Machine check interrupt [Not recovered]
          NIP [ffff000000000000]: 0xffff000000000000
          Initiator: CPU
          Error type: Real address [Instruction fetch (foreign)]
        [  127.426651616,0] OPAL: Reboot requested due to Platform error.
            Effective[  127.426693712,3] OPAL: Reboot requested due to Platform error. address: ffff000000000000
        opal: Reboot type 1 not supported
        Kernel panic - not syncing: PowerNV Unrecovered Machine Check
        CPU: 56 PID: 4425 Comm: syscall Tainted: G   M            4.12.0-rc1-13857-ga4700a26-dirty #35
        Call Trace:
        [  128.017988928,4] IPMI: BUG: Dropping ESEL on the floor due to
          buggy/mising code in OPAL for this BMC
          Rebooting in 10 seconds..
        Trying to free IRQ 496 from IRQ context!
      
      After this patch, the process is killed and the kernel continues with
      this message, which gives enough information to identify the offending
      branch (i.e., with CFAR):
      
        Severe Machine check interrupt [Not recovered]
          NIP [ffff000000000000]: 0xffff000000000000
          Initiator: CPU
          Error type: Real address [Instruction fetch (foreign)]
            Effective address: ffff000000000000
        Oops: Machine check, sig: 7 [#1]
        SMP NR_CPUS=2048
        NUMA
        PowerNV
        Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 ...
        CPU: 22 PID: 4436 Comm: syscall Tainted: G   M            4.12.0-rc1-13857-ga4700a26-dirty #36
        task: c000000932300000 task.stack: c000000932380000
        NIP: ffff000000000000 LR: 00000000217706a4 CTR: ffff000000000000
        REGS: c00000000fc8fd80 TRAP: 0200   Tainted: G   M             (4.12.0-rc1-13857-ga4700a26-dirty)
        MSR: 90000000001c1003 <SF,HV,ME,RI,LE>
          CR: 24000484  XER: 20000000
        CFAR: c000000000004c80 DAR: 0000000021770a90 DSISR: 0a000000 SOFTE: 1
        GPR00: 0000000000001ebe 00007fffce4818b0 0000000021797f00 0000000000000000
        GPR04: 00007fff8007ac24 0000000044000484 0000000000004000 00007fff801405e8
        GPR08: 900000000280f033 0000000024000484 0000000000000000 0000000000000030
        GPR12: 9000000000001003 00007fff801bc370 0000000000000000 0000000000000000
        GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
        GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
        GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
        GPR28: 00007fff801b0000 0000000000000000 00000000217707a0 00007fffce481918
        NIP [ffff000000000000] 0xffff000000000000
        LR [00000000217706a4] 0x217706a4
        Call Trace:
        Instruction dump:
        XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
        XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Reviewed-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      6fcd6baa
    • N
      powerpc/powernv: Flush console before platform error reboot · b746e3e0
      Nicholas Piggin 提交于
      Unrecovered MCE and HMI errors are sent through a special restart OPAL
      call to log the platform error. The downside is that they don't go
      through normal Linux crash paths, so they don't give much information
      to the Linux console.
      
      Change this by providing a special crash function which does some of
      the console flushing from the panic() path before calling firmware to
      reboot.
      
      The downside of this is a little more code to execute before reaching
      the firmware reboot. However in practice, it's critical to get the
      Linux console messages output in order to debug a problem. So this is
      a desirable tradeoff.
      
      Note on the implementation: It is difficult to plumb a custom reboot
      handler into the panic path, because panic does a little bit too much
      work. For example, it will try to delay with the timebase, but that
      may be corrupted in some cases resulting in a hang without reaching
      the platform reboot. Another problem is that panic can invoke the
      crash dump code which is not what we want in the case of a hardware
      platform error. Long-term the best solution will be to rework the
      panic path so it can be suitable for this kind of panic, but for now
      we just duplicate a bit of the code.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Reviewed-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b746e3e0
    • N
      powerpc: Do not send system reset request through the oops path · 4388c9b3
      Nicholas Piggin 提交于
      A system reset is a request to crash / debug the system rather than
      necessarily caused by encountering a BUG. So there is no need to
      serialize all CPUs behind the die lock, adding taints to all
      subsequent traces beyond the first, breaking console locks, etc.
      
      The system reset is NMI context which has its own printk buffers to
      prevent output being interleaved. Then it's better to have all
      secondaries print out their debug as quickly as possible and the
      primary will flush out all printk buffers during panic().
      
      So remove the 0x100 path from die, and move it into system_reset. Name
      the crash/dump reasons "System Reset".
      
      This gives "not tained" traces when crashing an untainted kernel. It
      also gives the panic reason as "System Reset" as opposed to "Fatal
      exception in interrupt" (or "die oops" for fadump).
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      4388c9b3
    • N
      powerpc/pseries/le: Work around a firmware quirk · bded0706
      Nicholas Piggin 提交于
      Some PowerVM firmware when delivering a system reset interrupt to a
      little endian OS will mess up SRR registers. They are byteswapped, and
      SRR1 is incorrect. An example from a crash:
      
        NIP: 14dd0900000000c0
        MSR: 1000000200000080
      
      It's possible to detect this pattern in SRR1 (that would never happen
      in normal operation), and at least fix the NIP. After this patch, the
      same interrupt reports NIP properly:
      
        NIP [c00000000009dd14] plpar_hcall_norets+0x1c/0x28
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      bded0706
    • N
      powerpc: Do not call ppc_md.panic in fadump panic notifier · a3b2cb30
      Nicholas Piggin 提交于
      If fadump is not registered, and no other crash or debug handlers are
      registered, the powerpc panic handler stops the guest before the
      generic panic code can push out debug information to the console.
      
      Currently, system reset injection causes the guest to silently stop.
      
      Stop calling ppc_md.panic in the panic notifier. crash_fadump already
      does rtas_os_term() to terminate the guest if fadump is registered.
      
      Remove ppc_md.panic. Move fadump panic notifier into fadump code.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Reviewed-by: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      a3b2cb30
    • N
      powerpc/64: Fix watchdog configuration regressions · 70412c55
      Nicholas Piggin 提交于
      This fixes a couple more bits of fallout from the new hard lockup watchdog
      patch.
      
      It restores the required hw_nmi_get_sample_period() function for the
      perf watchdog, and removes some function declarations on 64e that are only
      defined for 64s. This fixes the 64e build when the hardlockup detector is
      enabled.
      
      It restores the default behaviour of disabling the perf watchdog, and also
      fixes disabling the 64s watchdog when running as a guest.
      
      Fixes: 2104180a ("powerpc/64s: implement arch-specific hardlockup watchdog")
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      70412c55
    • N
      powerpc/64s/radix: Do not allocate SLB shadow structures · b68b1d74
      Nicholas Piggin 提交于
      These are unused in radix mode.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b68b1d74
    • N
      powerpc/64s/radix: Remove bolted-SLB address limit for per-cpu stacks · d5507190
      Nicholas Piggin 提交于
      Radix MMU does not take SLB or TLB interrupts when accessing kernel
      linear address. Remove this restriction for radix mode.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      d5507190
    • N
      powerpc/powernv: powernv platform is not constrained by RMA · 76b42e28
      Nicholas Piggin 提交于
      Remove incorrect comment about real mode address restrictions on
      powernv (bare metal), and unnecessary clamping to ppc64_rma_size.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      76b42e28
  2. 29 8月, 2017 6 次提交
  3. 28 8月, 2017 23 次提交