1. 14 7月, 2009 3 次提交
  2. 10 7月, 2009 1 次提交
  3. 18 6月, 2009 1 次提交
  4. 13 6月, 2009 1 次提交
  5. 12 6月, 2009 17 次提交
  6. 11 6月, 2009 4 次提交
  7. 12 5月, 2009 1 次提交
  8. 08 5月, 2009 4 次提交
  9. 13 3月, 2009 1 次提交
  10. 03 3月, 2009 1 次提交
  11. 18 2月, 2009 1 次提交
  12. 17 2月, 2009 1 次提交
  13. 05 2月, 2009 2 次提交
    • I
      perfcounters: fix "perf counters kills oprofile" bug, v2 · 82aa9a18
      Ingo Molnar 提交于
      Impact: fix kernel crash
      
      Both oprofile and perfcounters register an NMI die handler, but only one
      can handle the NMI.  Conveniently, oprofile unregisters it's notifier
      when not actively in use, so setting it's notifier priority higher than
      perfcounter's allows oprofile to borrow the NMI for the duration of it's
      run.  Tested/works both as module and built-in.
      
      While testing, I found that if kerneltop was generating NMIs at very
      high frequency, the kernel may panic when oprofile registered it's
      handler.  This turned out to be because oprofile registers it's handler
      before reset_value has been allocated, so if an NMI comes in while it's
      still setting up, kabOom.  Rather than try more invasive changes, I
      followed the lead of other places in op_model_ppro.c, and simply
      returned in that highly unlikely event.  (debug warnings attached)
      Signed-off-by: NMike Galbraith <efault@gmx.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      82aa9a18
    • M
      perfcounters: fix "perf counters kill oprofile" bug · 5b75af0a
      Mike Galbraith 提交于
      With oprofile as a module, and unloaded by profiling script,
      both oprofile and kerneltop work fine.. unless you leave kerneltop
      running when you start profiling, then you may see badness.
      Signed-off-by: NMike Galbraith <efault@gmx.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5b75af0a
  14. 08 1月, 2009 2 次提交