1. 28 May, 2014 1 commit
  2. 22 May, 2014 21 commits
  3. 20 May, 2014 9 commits
  4. 12 May, 2014 2 commits
    • Anton Blanchard's avatar
      powerpc: irq work racing with timer interrupt can result in timer interrupt hang · 8050936c
      Anton Blanchard authored
      I am seeing an issue where a CPU running perf eventually hangs.
      Traces show timer interrupts happening every 4 seconds even
      when a userspace task is running on the CPU. /proc/timer_list
      also shows pending hrtimers have not run in over an hour,
      including the scheduler.
      
      Looking closer, decrementers_next_tb is getting set to
      0xffffffffffffffff, and at that point we will never take
      a timer interrupt again.
      
      In __timer_interrupt() we set decrementers_next_tb to
      0xffffffffffffffff and rely on ->event_handler to update it:
      
              *next_tb = ~(u64)0;
              if (evt->event_handler)
                      evt->event_handler(evt);
      
      In this case ->event_handler is hrtimer_interrupt. This will eventually
      call back through the clockevents code with the next event to be
      programmed:
      
      static int decrementer_set_next_event(unsigned long evt,
                                            struct clock_event_device *dev)
      {
              /* Don't adjust the decrementer if some irq work is pending */
              if (test_irq_work_pending())
                      return 0;
              __get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt;
      
      If irq work came in between these two points, we will return
      before updating decrementers_next_tb and we never process a timer
      interrupt again.
      
      This looks to have been introduced by 0215f7d8 (powerpc: Fix races
      with irq_work). Fix it by removing the early exit and relying on
      code later on in the function to force an early decrementer:
      
             /* We may have raced with new irq work */
             if (test_irq_work_pending())
                     set_dec(1);
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Cc: stable@vger.kernel.org # 3.14+
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8050936c
    • Gavin Shan's avatar
      powerpc/powernv: Reset root port in firmware · 372cf124
      Gavin Shan authored
      Resetting root port has more stuff to do than that for PCIe switch
      ports and we should have resetting root port done in firmware instead
      of the kernel itself. The problem was introduced by commit 5b2e198e
      ("powerpc/powernv: Rework EEH reset").
      
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      372cf124
  5. 09 May, 2014 1 commit
    • Scott Wood's avatar
      powerpc/fsl-rio: Fix fsl_rio_setup error paths and use-after-unmap · a614db9a
      Scott Wood authored
      Several of the error paths from fsl_rio_setup are missing error
      messages.
      
      Worse, fsl_rio_setup initializes several global pointers and does not
      NULL them out after freeing/unmapping on error.  This caused
      fsl_rio_mcheck_exception() to crash when accessing rio_regs_win which
      was non-NULL but had been unmapped.
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      Cc: Liu Gang <Gang.Liu@freescale.com>
      ---
      Liu Gang, are you sure all of these error conditions are fatal?  Why
      does the rio driver fail if rmu is not present (e.g.  on t4240)?
      a614db9a
  6. 05 May, 2014 1 commit
  7. 30 Apr, 2014 5 commits