1. 05 6月, 2018 1 次提交
  2. 04 6月, 2018 1 次提交
  3. 03 6月, 2018 8 次提交
  4. 28 5月, 2018 1 次提交
  5. 24 5月, 2018 1 次提交
  6. 22 5月, 2018 1 次提交
  7. 21 5月, 2018 1 次提交
  8. 18 5月, 2018 2 次提交
  9. 17 5月, 2018 2 次提交
    • N
      powerpc/powernv: Fix NVRAM sleep in invalid context when crashing · c1d2a313
      Nicholas Piggin 提交于
      Similarly to opal_event_shutdown, opal_nvram_write can be called in
      the crash path with irqs disabled. Special case the delay to avoid
      sleeping in invalid context.
      
      Fixes: 3b807033 ("powerpc/powernv: Fix OPAL NVRAM driver OPAL_BUSY loops")
      Cc: stable@vger.kernel.org # v3.2
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      c1d2a313
    • N
      powerpc/powernv: Fix opal_event_shutdown() called with interrupts disabled · c0beffc4
      Nicholas Piggin 提交于
      A kernel crash in process context that calls emergency_restart from
      panic will end up calling opal_event_shutdown with interrupts disabled
      but not in interrupt. This causes a sleeping function to be called
      which gives the following warning with sysrq+c:
      
          Rebooting in 10 seconds..
          BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
          in_atomic(): 0, irqs_disabled(): 1, pid: 7669, name: bash
          CPU: 20 PID: 7669 Comm: bash Tainted: G      D W         4.17.0-rc5+ #3
          Call Trace:
          dump_stack+0xb0/0xf4 (unreliable)
          ___might_sleep+0x174/0x1a0
          mutex_lock+0x38/0xb0
          __free_irq+0x68/0x460
          free_irq+0x70/0xc0
          opal_event_shutdown+0xb4/0xf0
          opal_shutdown+0x24/0xa0
          pnv_shutdown+0x28/0x40
          machine_shutdown+0x44/0x60
          machine_restart+0x28/0x80
          emergency_restart+0x30/0x50
          panic+0x2a0/0x328
          oops_end+0x1ec/0x1f0
          bad_page_fault+0xe8/0x154
          handle_page_fault+0x34/0x38
          --- interrupt: 300 at sysrq_handle_crash+0x44/0x60
          LR = __handle_sysrq+0xfc/0x260
          flag_spec.62335+0x12b844/0x1e8db4 (unreliable)
          __handle_sysrq+0xfc/0x260
          write_sysrq_trigger+0xa8/0xb0
          proc_reg_write+0xac/0x110
          __vfs_write+0x6c/0x240
          vfs_write+0xd0/0x240
          ksys_write+0x6c/0x110
      
      Fixes: 9f0fd049 ("powerpc/powernv: Add a virtual irqchip for opal events")
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      c0beffc4
  10. 14 5月, 2018 2 次提交
  11. 07 5月, 2018 1 次提交
  12. 25 4月, 2018 1 次提交
  13. 24 4月, 2018 4 次提交
  14. 11 4月, 2018 1 次提交
  15. 07 4月, 2018 1 次提交
  16. 03 4月, 2018 2 次提交
    • N
      powerpc/powernv: Always stop secondaries before reboot/shutdown · f2748bdf
      Nicholas Piggin 提交于
      Currently powernv reboot and shutdown requests just leave secondaries
      to do their own things. This is undesirable because they can trigger
      any number of watchdogs while waiting for reboot, but also we don't
      know what else they might be doing -- they might be causing trouble,
      trampling memory, etc.
      
      The opal scheduled flash update code already ran into watchdog problems
      due to flashing taking a long time, and it was fixed with 2196c6f1
      ("powerpc/powernv: Return secondary CPUs to firmware before FW update"),
      which returns secondaries to opal. It's been found that regular reboots
      can take over 10 seconds, which can result in the hard lockup watchdog
      firing,
      
        reboot: Restarting system
        [  360.038896709,5] OPAL: Reboot request...
        Watchdog CPU:0 Hard LOCKUP
        Watchdog CPU:44 detected Hard LOCKUP other CPUS:16
        Watchdog CPU:16 Hard LOCKUP
        watchdog: BUG: soft lockup - CPU#16 stuck for 3s! [swapper/16:0]
      
      This patch removes the special case for flash update, and calls
      smp_send_stop in all cases before calling reboot/shutdown.
      
      smp_send_stop could return CPUs to OPAL, the main reason not to is
      that the request could come from a NMI that interrupts OPAL code,
      so re-entry to OPAL can cause a number of problems. Putting
      secondaries into simple spin loops improves the chances of a
      successful reboot.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Reviewed-by: NVasant Hegde <hegdevasant@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      f2748bdf
    • N
      powerpc/powernv: Fix SMT4 forcing idle code · a2b5e056
      Nicholas Piggin 提交于
      The PSSCR value is not stored to PACA_REQ_PSSCR if the CPU does not
      have the XER[SO] bug.
      
      Fix this by storing up-front, outside the workaround code. The initial
      test is not required because it is a slow path.
      
      The workaround is made to depend on CONFIG_KVM_BOOK3S_HV_POSSIBLE, to
      match pnv_power9_force_smt4_catch() where it is used. Drop the comment
      on pnv_power9_force_smt4_catch() as it's no longer true.
      
      Fixes: 7672691a ("powerpc/powernv: Provide a way to force a core into SMT4 mode")
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      a2b5e056
  17. 31 3月, 2018 1 次提交
  18. 30 3月, 2018 2 次提交
  19. 27 3月, 2018 4 次提交
  20. 23 3月, 2018 1 次提交
    • P
      powerpc/powernv: Provide a way to force a core into SMT4 mode · 7672691a
      Paul Mackerras 提交于
      POWER9 processors up to and including "Nimbus" v2.2 have hardware
      bugs relating to transactional memory and thread reconfiguration.
      One of these bugs has a workaround which is to get the core into
      SMT4 state temporarily.  This workaround is only needed when
      running bare-metal.
      
      This patch provides a function which gets the core into SMT4 mode
      by preventing threads from going to a stop state, and waking up
      those which are already in a stop state.  Once at least 3 threads
      are not in a stop state, the core will be in SMT4 and we can
      continue.
      
      To do this, we add a "dont_stop" flag to the paca to tell the
      thread not to go into a stop state.  If this flag is set,
      power9_idle_stop() just returns immediately with a return value
      of 0.  The pnv_power9_force_smt4_catch() function does the following:
      
      1. Set the dont_stop flag for each thread in the core, except
         ourselves (in fact we use an atomic_inc() in case more than
         one thread is calling this function concurrently).
      2. See how many threads are awake, indicated by their
         requested_psscr field in the paca being 0.  If this is at
         least 3, skip to step 5.
      3. Send a doorbell interrupt to each thread that was seen as
         being in a stop state in step 2.
      4. Until at least 3 threads are awake, scan the threads to which
         we sent a doorbell interrupt and check if they are awake now.
      
      This relies on the following properties:
      
      - Once dont_stop is non-zero, requested_psccr can't go from zero to
        non-zero, except transiently (and without the thread doing stop).
      - requested_psscr being zero guarantees that the thread isn't in
        a state-losing stop state where thread reconfiguration could occur.
      - Doing stop with a PSSCR value of 0 won't be a state-losing stop
        and thus won't allow thread reconfiguration.
      - Once threads_per_core/2 + 1 (i.e. 3) threads are awake, the core
        must be in SMT4 mode, since SMT modes are powers of 2.
      
      This does add a sync to power9_idle_stop(), which is necessary to
      provide the correct ordering between setting requested_psscr and
      checking dont_stop.  The overhead of the sync should be unnoticeable
      compared to the latency of going into and out of a stop state.
      
      Because some objected to incurring this extra latency on systems where
      the XER[SO] bug is not relevant, I have put the test in
      power9_idle_stop inside a feature section.  This means that
      pnv_power9_force_smt4_catch() WILL NOT WORK correctly on systems
      without the CPU_FTR_P9_TM_XER_SO_BUG feature bit set, and will
      probably hang the system.
      
      In order to cater for uses where the caller has an operation that
      has to be done while the core is in SMT4, the core continues to be
      kept in SMT4 after pnv_power9_force_smt4_catch() function returns,
      until the pnv_power9_force_smt4_release() function is called.
      It undoes the effect of step 1 above and allows the other threads
      to go into a stop state.
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      7672691a
  21. 20 3月, 2018 1 次提交
  22. 14 3月, 2018 1 次提交