Skip to content
  1. Sep 02, 2010
  2. Sep 01, 2010
  3. Aug 31, 2010
    • Michael Neuling's avatar
      powerpc: Don't use kernel stack with translation off · 54a83404
      Michael Neuling authored
      In f761622e
      
       we changed
      early_setup_secondary so it's called using the proper kernel stack
      rather than the emergency one.
      
      Unfortunately, this stack pointer can't be used when translation is off
      on PHYP as this stack pointer might be outside the RMO.  This results in
      the following on all non zero cpus:
        cpu 0x1: Vector: 300 (Data Access) at [c00000001639fd10]
            pc: 000000000001c50c
            lr: 000000000000821c
            sp: c00000001639ff90
           msr: 8000000000001000
           dar: c00000001639ffa0
         dsisr: 42000000
          current = 0xc000000016393540
          paca    = 0xc000000006e00200
            pid   = 0, comm = swapper
      
      The original patch was only tested on bare metal system, so it never
      caught this problem.
      
      This changes __secondary_start so that we calculate the new stack
      pointer but only start using it after we've called early_setup_secondary.
      
      With this patch, the above problem goes away.
      
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      54a83404
    • Paul Mackerras's avatar
      powerpc/perf_event: Reduce latency of calling perf_event_do_pending · b0d278b7
      Paul Mackerras authored
      Commit 0fe1ac48
      
       ("powerpc/perf_event: Fix oops due to
      perf_event_do_pending call") moved the call to perf_event_do_pending
      in timer_interrupt() down so that it was after the irq_enter() call.
      Unfortunately this moved it after the code that checks whether it
      is time for the next decrementer clock event.  The result is that
      the call to perf_event_do_pending() won't happen until the next
      decrementer clock event is due.  This was pointed out by Milton
      Miller.
      
      This fixes it by moving the check for whether it's time for the
      next decrementer clock event down to the point where we're about
      to call the event handler, after we've called perf_event_do_pending.
      
      This has the side effect that on old pre-Core99 Powermacs where we
      use the ppc_n_lost_interrupts mechanism to replay interrupts, a
      replayed interrupt will incur a little more latency since it will
      now do the code from the irq_enter down to the irq_exit, that it
      used to skip.  However, these machines are now old and rare enough
      that this doesn't matter.  To make it clear that ppc_n_lost_interrupts
      is only used on Powermacs, and to speed up the code slightly on
      non-Powermac ppc32 machines, the code that tests ppc_n_lost_interrupts
      is now conditional on CONFIG_PMAC as well as CONFIG_PPC32.
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Cc: stable@kernel.org
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      b0d278b7
    • Matthew McClintock's avatar
      powerpc/kexec: Adds correct calling convention for kexec purgatory · 4562c986
      Matthew McClintock authored
      
      
      Call kexec purgatory code correctly. We were getting lucky before.
      If you examine the powerpc 32bit kexec "purgatory" code you will
      see it expects the following:
      
      >From kexec-tools: purgatory/arch/ppc/v2wrap_32.S
      -> calling convention:
      ->   r3 = physical number of this cpu (all cpus)
      ->   r4 = address of this chunk (master only)
      
      As such, we need to set r3 to the current core, r4 happens to be
      unused by purgatory at the moment but we go ahead and set it
      here as well
      
      Signed-off-by: default avatarMatthew McClintock <msm@freescale.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      4562c986
  4. Aug 29, 2010