1. 27 1月, 2018 3 次提交
  2. 24 1月, 2018 7 次提交
  3. 22 1月, 2018 3 次提交
    • N
      powerpc/pseries, ps3: panic flush kernel messages before halting system · 35adacd6
      Nicholas Piggin 提交于
      Platforms with a panic handler that halts the system can have problems
      getting kernel messages out, because the panic notifiers are called
      before kernel/panic.c does its flushing of printk buffers an console
      etc.
      
      This was attempted to be solved with commit a3b2cb30 ("powerpc: Do
      not call ppc_md.panic in fadump panic notifier"), but that wasn't the
      right approach and caused other problems, and was reverted by commit
      ab9dbf77.
      
      Instead, the powernv shutdown paths have already had a similar
      problem, fixed by taking the message flushing sequence from
      kernel/panic.c. That's a little bit ugly, but while we have the code
      duplicated, it will work for this case as well. So have ppc panic
      handlers do the same flushing before they terminate.
      
      Without this patch, a qemu pseries_le_defconfig guest stops silently
      when issued the nmi command when xmon is off and no crash dumpers
      enabled. Afterwards, an oops is printed by each CPU as expected.
      
      Fixes: ab9dbf77 ("Revert "powerpc: Do not call ppc_md.panic in fadump panic notifier"")
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      35adacd6
    • G
      powerpc/powernv: Add ppc_pci_reset_phbs parameter to issue a PHB reset · 45baee14
      Guilherme G. Piccoli 提交于
      During a kdump kernel boot in PowerPC, we request a reset of the PHBs
      to the FW. It makes sense, since if we are booting a kdump kernel it
      means we had some trouble before and we cannot rely in the adapters'
      health; they could be in a bad state, hence the reset is needed.
      
      But this reset is useful not only in kdump - there are situations,
      specially when debugging drivers, that we could break an adapter in
      a way it requires such reset. One can tell to just go ahead and
      reboot the machine, but happens that many times doing kexec is much
      faster, and so preferable than a full power cycle.
      
      This patch adds the ppc_pci_reset_phbs parameter to perform such reset.
      Signed-off-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      45baee14
    • R
      powerpc: Use octal numbers for file permissions · 57ad583f
      Russell Currey 提交于
      Symbolic macros are unintuitive and hard to read, whereas octal constants
      are much easier to interpret.  Replace macros for the basic permission
      flags (user/group/other read/write/execute) with numeric constants
      instead, across the whole powerpc tree.
      
      Introducing a significant number of changes across the tree for no runtime
      benefit isn't exactly desirable, but so long as these macros are still
      used in the tree people will keep sending patches that add them.  Not only
      are they hard to parse at a glance, there are multiple ways of coming to
      the same value (as you can see with 0444 and 0644 in this patch) which
      hurts readability.
      Signed-off-by: NRussell Currey <ruscur@russell.cc>
      Reviewed-by: NCyril Bur <cyrilbur@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      57ad583f
  4. 20 1月, 2018 1 次提交
  5. 19 1月, 2018 1 次提交
    • A
      powerpc/powernv: Add debugfs interface for imc-mode and imc-command · 684d9840
      Anju T Sudhakar 提交于
      In memory Collection (IMC) counter pmu driver controls the ucode's
      execution state. At the system boot, IMC perf driver pause the ucode.
      Ucode state is changed to "running" only when any of the nest units
      are monitored or profiled using perf tool.
      
      Nest units support only limited set of hardware counters and ucode is
      always programmed in the "production mode" ("accumulation") mode. This
      mode is configured to provide key performance metric data for most of
      the nest units.
      
      But ucode also supports other modes which would be used for "debug" to
      drill down specific nest units. That is, ucode when switched to
      "powerbus" debug mode (for example), will dynamically reconfigure the
      nest counters to target only "powerbus" related events in the hardware
      counters. This allows the IMC nest unit to focus on powerbus related
      transactions in the system in more detail. At this point, production
      mode events may or may not be counted.
      
      IMC nest counters has both in-band (ucode access) and out of band
      access to it. Since not all nest counter configurations are supported
      by ucode, out of band tools are used to characterize other nest
      counter configurations.
      
      Patch provides an interface via "debugfs" to enable the switching of
      ucode modes in the system. To switch ucode mode, one has to first
      pause the microcode (imc_cmd), and then write the target mode value to
      the "imc_mode" file.
      
      Proposed Approach:
      
      In the proposed approach, the function (export_imc_mode_and_cmd) which
      creates the debugfs interface for imc mode and command is implemented
      in opal-imc.c. Thus we can use imc_get_mem_addr() to get the homer
      base address for each chip.
      
      The interface to expose imc mode and command is required only if we
      have nest pmu units registered. Employing the existing data structures
      to track whether we have any nest units registered will require to
      extend data from perf side to opal-imc.c. Instead an integer is
      introduced to hold that information by counting successful nest unit
      registration. Debugfs interface is removed based on the integer count.
      
      Example for the interface:
      
        $ ls /sys/kernel/debug/imc
        imc_cmd_0  imc_cmd_8  imc_mode_0  imc_mode_8
      Signed-off-by: NAnju T Sudhakar <anju@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      684d9840
  6. 16 1月, 2018 1 次提交
    • B
      powernv/kdump: Fix cases where the kdump kernel can get HMI's · 4145f358
      Balbir Singh 提交于
      Certain HMI's such as malfunction error propagate through
      all threads/core on the system. If a thread was offline
      prior to us crashing the system and jumping to the kdump
      kernel, bad things happen when it wakes up due to an HMI
      in the kdump kernel.
      
      There are several possible ways to solve this problem
      
      1. Put the offline cores in a state such that they are
      not woken up for machine check and HMI errors. This
      does not work, since we might need to wake up offline
      threads to handle TB errors
      2. Ignore HMI errors, setup HMEER to mask HMI errors,
      but this still leads the window open for any MCEs
      and masking them for the duration of the dump might
      be a concern
      3. Wake up offline CPUs, as in send them to
      crash_ipi_callback (not wake them up as in mark them
      online as seen by the hotplug). kexec does a
      wake_online_cpus() call, this patch does something
      similar, but instead sends an IPI and forces them to
      crash_ipi_callback()
      
      This patch takes approach #3.
      
      Care is taken to enable this only for powenv platforms
      via crash_wake_offline (a global value set at setup
      time). The crash code sends out IPI's to all CPU's
      which then move to crash_ipi_callback and kexec_smp_wait().
      Signed-off-by: NBalbir Singh <bsingharora@gmail.com>
      Reviewed-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      4145f358
  7. 10 1月, 2018 2 次提交
  8. 11 12月, 2017 2 次提交
  9. 04 12月, 2017 1 次提交
  10. 28 11月, 2017 1 次提交
  11. 22 11月, 2017 2 次提交
  12. 21 11月, 2017 1 次提交
  13. 13 11月, 2017 2 次提交
  14. 12 11月, 2017 13 次提交