1. 12 3月, 2014 9 次提交
  2. 01 2月, 2014 1 次提交
  3. 19 1月, 2014 1 次提交
  4. 30 12月, 2013 1 次提交
    • S
      clocksource: cadence_ttc: Fix mutex taken inside interrupt context · c1dcc927
      Soren Brinkmann 提交于
      When the kernel is compiled with:
      CONFIG_HIGH_RES_TIMERS=no
      CONFIG_HZ_PERIODIC=yes
      CONFIG_DEBUG_ATOMIC_SLEEP=yes
      
      The following WARN appears:
      
      WARNING: CPU: 1 PID: 0 at linux/kernel/mutex.c:856 mutex_trylock+0x70/0x1fc()
      DEBUG_LOCKS_WARN_ON(in_interrupt())
      Modules linked in:
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.12.0-xilinx-dirty #93
      [<c0014a78>] (unwind_backtrace+0x0/0x11c) from [<c0011b6c>] (show_stack+0x10/0x14)
      [<c0011b6c>] (show_stack+0x10/0x14) from [<c039120c>] (dump_stack+0x7c/0xc0)
      [<c039120c>] (dump_stack+0x7c/0xc0) from [<c001fda4>] (warn_slowpath_common+0x60/0x84)
      [<c001fda4>] (warn_slowpath_common+0x60/0x84) from [<c001fe48>] (warn_slowpath_fmt+0x2c/0x3c)
      [<c001fe48>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0392658>] (mutex_trylock+0x70/0x1fc)
      [<c0392658>] (mutex_trylock+0x70/0x1fc) from [<c02dfc08>] (clk_prepare_lock+0xc/0xe4)
      [<c02dfc08>] (clk_prepare_lock+0xc/0xe4) from [<c02e099c>] (clk_get_rate+0xc/0x44)
      [<c02e099c>] (clk_get_rate+0xc/0x44) from [<c02d0394>] (ttc_set_mode+0x34/0x78)
      [<c02d0394>] (ttc_set_mode+0x34/0x78) from [<c005f794>] (clockevents_set_mode+0x28/0x5c)
      [<c005f794>] (clockevents_set_mode+0x28/0x5c) from [<c00607fc>] (tick_broadcast_on_off+0x190/0x1c0)
      [<c00607fc>] (tick_broadcast_on_off+0x190/0x1c0) from [<c005f168>] (clockevents_notify+0x58/0x1ac)
      [<c005f168>] (clockevents_notify+0x58/0x1ac) from [<c02b99dc>] (cpuidle_setup_broadcast_timer+0x20/0x24)
      [<c02b99dc>] (cpuidle_setup_broadcast_timer+0x20/0x24) from [<c006cd04>] (generic_smp_call_function_single_interrupt+0)
      [<c006cd04>] (generic_smp_call_function_single_interrupt+0xe0/0x130) from [<c00138c8>] (handle_IPI+0x88/0x118)
      [<c00138c8>] (handle_IPI+0x88/0x118) from [<c0008504>] (gic_handle_irq+0x58/0x60)
      [<c0008504>] (gic_handle_irq+0x58/0x60) from [<c0012644>] (__irq_svc+0x44/0x78)
      Exception stack(0xef099fa0 to 0xef099fe8)
      9fa0: 00000001 ef092100 00000000 ef092100 ef098000 00000015 c0399f2c c0579d74
      9fc0: 0000406a 413fc090 00000000 00000000 00000000 ef099fe8 c00666ec c000f46c
      9fe0: 20000113 ffffffff
      [<c0012644>] (__irq_svc+0x44/0x78) from [<c000f46c>] (arch_cpu_idle+0x34/0x3c)
      [<c000f46c>] (arch_cpu_idle+0x34/0x3c) from [<c0053980>] (cpu_startup_entry+0xa8/0x10c)
      [<c0053980>] (cpu_startup_entry+0xa8/0x10c) from [<000085a4>] (0x85a4)
      
      We are in an interrupt context (IPI) and we are calling clk_get_rate in the
      set_mode function which in turn ends up by getting a mutex... Even if that
      does not hang, it is a potential kernel deadlock.
      
      It is not allowed to call clk_get_rate() from interrupt context. To
      avoid such calls the timer input frequency is stored in the driver's
      data struct which makes it accessible to the driver in any context.
      
      [dlezcano] completed the changelog with the WARN trace and added a more
      detailed description. Tested on zync zc702.
      Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Tested-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      c1dcc927
  5. 18 12月, 2013 1 次提交
  6. 16 12月, 2013 1 次提交
  7. 14 12月, 2013 1 次提交
  8. 11 12月, 2013 22 次提交
  9. 27 11月, 2013 1 次提交
  10. 21 11月, 2013 2 次提交