1. 14 Apr, 2015 7 commits
  2. 12 Feb, 2015 1 commit
    • Cyril Bur's avatar
      kernel/sched/clock.c: add another clock for use with the soft lockup watchdog · 545a2bf7
      Cyril Bur authored
      When the hypervisor pauses a virtualised kernel the kernel will observe a
      jump in timebase, this can cause spurious messages from the softlockup
      detector.
      
      Whilst these messages are harmless, they are accompanied with a stack
      trace which causes undue concern and more problematically the stack trace
      in the guest has nothing to do with the observed problem and can only be
      misleading.
      
      Futhermore, on POWER8 this is completely avoidable with the introduction
      of the Virtual Time Base (VTB) register.
      
      This patch (of 2):
      
      This permits the use of arch specific clocks for which virtualised kernels
      can use their notion of 'running' time, not the elpased wall time which
      will include host execution time.
      Signed-off-by: default avatarCyril Bur <cyrilbur@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Andrew Jones <drjones@redhat.com>
      Acked-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Ulrich Obergfell <uobergfe@redhat.com>
      Cc: chai wen <chaiw.fnst@cn.fujitsu.com>
      Cc: Fabian Frederick <fabf@skynet.be>
      Cc: Aaron Tomlin <atomlin@redhat.com>
      Cc: Ben Zhang <benzh@chromium.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      545a2bf7
  3. 13 Oct, 2014 1 commit
    • Ulrich Obergfell's avatar
      kernel/watchdog.c: control hard lockup detection default · 6e7458a6
      Ulrich Obergfell authored
      In some cases we don't want hard lockup detection enabled by default.
      An example is when running as a guest.  Introduce
      
        watchdog_enable_hardlockup_detector(bool)
      
      allowing those cases to disable hard lockup detection.  This must be
      executed early by the boot processor from e.g.  smp_prepare_boot_cpu, in
      order to allow kernel command line arguments to override it, as well as
      to avoid hard lockup detection being enabled before we've had a chance
      to indicate that it's unwanted.  In summary,
      
        initial boot:					default=enabled
        smp_prepare_boot_cpu
          watchdog_enable_hardlockup_detector(false):	default=disabled
        cmdline has 'nmi_watchdog=1':			default=enabled
      
      The running kernel still has the ability to enable/disable at any time
      with /proc/sys/kernel/nmi_watchdog us usual.  However even when the
      default has been overridden /proc/sys/kernel/nmi_watchdog will initially
      show '1'.  To truly turn it on one must disable/enable it, i.e.
      
        echo 0 > /proc/sys/kernel/nmi_watchdog
        echo 1 > /proc/sys/kernel/nmi_watchdog
      
      This patch will be immediately useful for KVM with the next patch of this
      series.  Other hypervisor guest types may find it useful as well.
      
      [akpm@linux-foundation.org: fix build]
      [dzickus@redhat.com: fix compile issues on sparc]
      Signed-off-by: default avatarUlrich Obergfell <uobergfe@redhat.com>
      Signed-off-by: default avatarAndrew Jones <drjones@redhat.com>
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6e7458a6
  4. 09 Oct, 2014 1 commit
    • chai wen's avatar
      softlockup: make detector be aware of task switch of processes hogging cpu · b1a8de1f
      chai wen authored
      For now, soft lockup detector warns once for each case of process
      softlockup.  But the thread 'watchdog/n' may not always get the cpu at the
      time slot between the task switch of two processes hogging that cpu to
      reset soft_watchdog_warn.
      
      An example would be two processes hogging the cpu.  Process A causes the
      softlockup warning and is killed manually by a user.  Process B
      immediately becomes the new process hogging the cpu preventing the
      softlockup code from resetting the soft_watchdog_warn variable.
      
      This case is a false negative of "warn only once for a process", as there
      may be a different process that is going to hog the cpu.  Resolve this by
      saving/checking the task pointer of the hogging process and use that to
      reset soft_watchdog_warn too.
      
      [dzickus@redhat.com: update comment]
      Signed-off-by: default avatarchai wen <chaiw.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b1a8de1f
  5. 26 Aug, 2014 1 commit
  6. 18 Aug, 2014 2 commits
  7. 08 Aug, 2014 1 commit
  8. 06 Aug, 2014 1 commit
  9. 23 Jun, 2014 2 commits
    • Aaron Tomlin's avatar
      kernel/watchdog.c: print traces for all cpus on lockup detection · ed235875
      Aaron Tomlin authored
      A 'softlockup' is defined as a bug that causes the kernel to loop in
      kernel mode for more than a predefined period to time, without giving
      other tasks a chance to run.
      
      Currently, upon detection of this condition by the per-cpu watchdog
      task, debug information (including a stack trace) is sent to the system
      log.
      
      On some occasions, we have observed that the "victim" rather than the
      actual "culprit" (i.e.  the owner/holder of the contended resource) is
      reported to the user.  Often this information has proven to be
      insufficient to assist debugging efforts.
      
      To avoid loss of useful debug information, for architectures which
      support NMI, this patch makes it possible to improve soft lockup
      reporting.  This is accomplished by issuing an NMI to each cpu to obtain
      a stack trace.
      
      If NMI is not supported we just revert back to the old method.  A sysctl
      and boot-time parameter is available to toggle this feature.
      
      [dzickus@redhat.com: add CONFIG_SMP in certain areas]
      [akpm@linux-foundation.org: additional CONFIG_SMP=n optimisations]
      [mq@suse.cz: fix warning]
      Signed-off-by: default avatarAaron Tomlin <atomlin@redhat.com>
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Mateusz Guzik <mguzik@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarJan Moskyto Matejka <mq@suse.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ed235875
    • Don Zickus's avatar
      kernel/watchdog.c: remove preemption restrictions when restarting lockup detector · bde92cf4
      Don Zickus authored
      Peter Wu noticed the following splat on his machine when updating
      /proc/sys/kernel/watchdog_thresh:
      
        BUG: sleeping function called from invalid context at mm/slub.c:965
        in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: init
        3 locks held by init/1:
         #0:  (sb_writers#3){.+.+.+}, at: [<ffffffff8117b663>] vfs_write+0x143/0x180
         #1:  (watchdog_proc_mutex){+.+.+.}, at: [<ffffffff810e02d3>] proc_dowatchdog+0x33/0x110
         #2:  (cpu_hotplug.lock){.+.+.+}, at: [<ffffffff810589c2>] get_online_cpus+0x32/0x80
        Preemption disabled at:[<ffffffff810e0384>] proc_dowatchdog+0xe4/0x110
      
        CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-rc1-testing #34
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        Call Trace:
          dump_stack+0x4e/0x7a
          __might_sleep+0x11d/0x190
          kmem_cache_alloc_trace+0x4e/0x1e0
          perf_event_alloc+0x55/0x440
          perf_event_create_kernel_counter+0x26/0xe0
          watchdog_nmi_enable+0x75/0x140
          update_timers_all_cpus+0x53/0xa0
          proc_dowatchdog+0xe4/0x110
          proc_sys_call_handler+0xb3/0xc0
          proc_sys_write+0x14/0x20
          vfs_write+0xad/0x180
          SyS_write+0x49/0xb0
          system_call_fastpath+0x16/0x1b
        NMI watchdog: disabled (cpu0): hardware events not enabled
      
      What happened is after updating the watchdog_thresh, the lockup detector
      is restarted to utilize the new value.  Part of this process involved
      disabling preemption.  Once preemption was disabled, perf tried to
      allocate a new event (as part of the restart).  This caused the above
      BUG_ON as you can't sleep with preemption disabled.
      
      The preemption restriction seemed agressive as we are not doing anything
      on that particular cpu, but with all the online cpus (which are
      protected by the get_online_cpus lock).  Remove the restriction and the
      BUG_ON goes away.
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.cz>
      Reported-by: default avatarPeter Wu <peter@lekensteyn.nl>
      Tested-by: default avatarPeter Wu <peter@lekensteyn.nl>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: <stable@vger.kernel.org>		[3.13+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bde92cf4
  10. 18 Apr, 2014 1 commit
  11. 03 Apr, 2014 1 commit
    • Ben Zhang's avatar
      kernel/watchdog.c: touch_nmi_watchdog should only touch local cpu not every one · 62572e29
      Ben Zhang authored
      I ran into a scenario where while one cpu was stuck and should have
      panic'd because of the NMI watchdog, it didn't.  The reason was another
      cpu was spewing stack dumps on to the console.  Upon investigation, I
      noticed that when writing to the console and also when dumping the
      stack, the watchdog is touched.
      
      This causes all the cpus to reset their NMI watchdog flags and the
      'stuck' cpu just spins forever.
      
      This change causes the semantics of touch_nmi_watchdog to be changed
      slightly.  Previously, I accidentally changed the semantics and we
      noticed there was a codepath in which touch_nmi_watchdog could be
      touched from a preemtible area.  That caused a BUG() to happen when
      CONFIG_DEBUG_PREEMPT was enabled.  I believe it was the acpi code.
      
      My attempt here re-introduces the change to have the
      touch_nmi_watchdog() code only touch the local cpu instead of all of the
      cpus.  But instead of using __get_cpu_var(), I use the
      __raw_get_cpu_var() version.
      
      This avoids the preemption problem.  However my reasoning wasn't because
      I was trying to be lazy.  Instead I rationalized it as, well if
      preemption is enabled then interrupts should be enabled to and the NMI
      watchdog will have no reason to trigger.  So it won't matter if the
      wrong cpu is touched because the percpu interrupt counters the NMI
      watchdog uses should still be incrementing.
      
      Don said:
      
      : I'm ok with this patch, though it does alter the behaviour of how
      : touch_nmi_watchdog works.  For the most part I don't think most callers
      : need to touch all of the watchdogs (on each cpu).  Perhaps a corner case
      : will pop up (the scheduler??  to mimic touch_all_softlockup_watchdogs() ).
      :
      : But this does address an issue where if a system is locked up and one cpu
      : is spewing out useful debug messages (or error messages), the hard lockup
      : will fail to go off.  We have seen this on RHEL also.
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarBen Zhang <benzh@chromium.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      62572e29
  12. 24 Feb, 2014 1 commit
    • Frederic Weisbecker's avatar
      watchdog: Simplify a little the IPI call · e0a23b06
      Frederic Weisbecker authored
      In order to remotely restart the watchdog hrtimer, update_timers()
      allocates a csd on the stack and pass it to __smp_call_function_single().
      
      There is no partcular need, however, for a specific csd here. Lets
      simplify that a little by calling smp_call_function_single()
      which can already take care of the csd allocation by itself.
      Acked-by: default avatarDon Zickus <dzickus@redhat.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.cz>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      e0a23b06
  13. 24 Sep, 2013 2 commits
    • Michal Hocko's avatar
      watchdog: update watchdog_thresh properly · 9809b18f
      Michal Hocko authored
      watchdog_tresh controls how often nmi perf event counter checks per-cpu
      hrtimer_interrupts counter and blows up if the counter hasn't changed
      since the last check.  The counter is updated by per-cpu
      watchdog_hrtimer hrtimer which is scheduled with 2/5 watchdog_thresh
      period which guarantees that hrtimer is scheduled 2 times per the main
      period.  Both hrtimer and perf event are started together when the
      watchdog is enabled.
      
      So far so good.  But...
      
      But what happens when watchdog_thresh is updated from sysctl handler?
      
      proc_dowatchdog will set a new sampling period and hrtimer callback
      (watchdog_timer_fn) will use the new value in the next round.  The
      problem, however, is that nobody tells the perf event that the sampling
      period has changed so it is ticking with the period configured when it
      has been set up.
      
      This might result in an ear ripping dissonance between perf and hrtimer
      parts if the watchdog_thresh is increased.  And even worse it might lead
      to KABOOM if the watchdog is configured to panic on such a spurious
      lockup.
      
      This patch fixes the issue by updating both nmi perf even counter and
      hrtimers if the threshold value has changed.
      
      The nmi one is disabled and then reinitialized from scratch.  This has
      an unpleasant side effect that the allocation of the new event might
      fail theoretically so the hard lockup detector would be disabled for
      such cpus.  On the other hand such a memory allocation failure is very
      unlikely because the original event is deallocated right before.
      
      It would be much nicer if we just changed perf event period but there
      doesn't seem to be any API to do that right now.  It is also unfortunate
      that perf_event_alloc uses GFP_KERNEL allocation unconditionally so we
      cannot use on_each_cpu() and do the same thing from the per-cpu context.
      The update from the current CPU should be safe because
      perf_event_disable removes the event atomically before it clears the
      per-cpu watchdog_ev so it cannot change anything under running handler
      feet.
      
      The hrtimer is simply restarted (thanks to Don Zickus who has pointed
      this out) if it is queued because we cannot rely it will fire&adopt to
      the new sampling period before a new nmi event triggers (when the
      treshold is decreased).
      
      [akpm@linux-foundation.org: the UP version of __smp_call_function_single ended up in the wrong place]
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.cz>
      Acked-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Fabio Estevam <festevam@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9809b18f
    • Michal Hocko's avatar
      watchdog: update watchdog attributes atomically · 359e6fab
      Michal Hocko authored
      proc_dowatchdog doesn't synchronize multiple callers which might lead to
      confusion when two parallel callers might confuse watchdog_enable_all_cpus
      resp watchdog_disable_all_cpus (eg watchdog gets enabled even if
      watchdog_thresh was set to 0 already).
      
      This patch adds a local mutex which synchronizes callers to the sysctl
      handler.
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.cz>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Acked-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      359e6fab
  14. 30 Jul, 2013 1 commit
  15. 20 Jun, 2013 2 commits
    • Frederic Weisbecker's avatar
      watchdog: Boot-disable by default on full dynticks · 940be35a
      Frederic Weisbecker authored
      When the watchdog runs, it prevents the full dynticks
      CPUs from stopping their tick because the hard lockup
      detector uses perf events internally, which in turn
      rely on the periodic tick.
      
      Since this is a rather confusing behaviour that is not
      easy to track down and identify for those who want to
      test CONFIG_NO_HZ_FULL, let's default disable the
      watchdog on boot time when full dynticks is enabled.
      
      The user can still enable it later on runtime using
      proc or sysctl.
      Reported-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Suggested-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Cc: Anish Singh <anish198519851985@gmail.com>
      940be35a
    • Frederic Weisbecker's avatar
      watchdog: Rename confusing state variable · 3c00ea82
      Frederic Weisbecker authored
      We have two very conflicting state variable names in the
      watchdog:
      
      * watchdog_enabled: This one reflects the user interface. It's
      set to 1 by default and can be overriden with boot options
      or sysctl/procfs interface.
      
      * watchdog_disabled: This is the internal toggle state that
      tells if watchdog threads, timers and NMI events are currently
      running or not. This state mostly depends on the user settings.
      It's a convenient state latch.
      
      Now we really need to find clearer names because those
      are just too confusing to encourage deep review.
      
      watchdog_enabled now becomes watchdog_user_enabled to reflect
      its purpose as an interface.
      
      watchdog_disabled becomes watchdog_running to suggest its
      role as a pure internal state.
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Cc: Anish Singh <anish198519851985@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Don Zickus <dzickus@redhat.com>
      3c00ea82
  16. 19 Jun, 2013 1 commit
    • Frederic Weisbecker's avatar
      watchdog: Register / unregister watchdog kthreads on sysctl control · b8900bc0
      Frederic Weisbecker authored
      The user activation/deactivation of the watchdog through boot parameters
      or systcl is currently implemented with a dance involving kthreads parking
      and unparking methods: the threads are unconditionally registered on
      boot and they park as soon as the user want the watchdog to be disabled.
      
      This method involves a few noisy details to handle though: the watchdog
      kthreads may be unparked anytime due to hotplug operations, after which
      the watchdog internals have to decide to park again if it is user-disabled.
      
      As a result the setup() and unpark() methods need to be able to request a
      reparking. This is not currently supported in the kthread infrastructure
      so this piece of the watchdog code only works halfway.
      
      Besides, unparking/reparking the watchdog kthreads consume unnecessary
      cputime on hotplug operations when those could be simply ignored in the
      first place.
      
      As suggested by Srivatsa, let's instead only register the watchdog
      threads when they are needed. This way we don't need to think about
      hotplug operations and we don't burden the CPU onlining when the watchdog
      is simply disabled.
      Suggested-by: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Cc: Anish Singh <anish198519851985@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Don Zickus <dzickus@redhat.com>
      b8900bc0
  17. 14 Mar, 2013 1 commit
  18. 19 Feb, 2013 1 commit
  19. 07 Feb, 2013 1 commit
  20. 19 Dec, 2012 1 commit
    • Bjørn Mork's avatar
      watchdog: Fix disable/enable regression · 3935e895
      Bjørn Mork authored
      Commit 8d451690 ("watchdog: Fix CPU hotplug regression") causes an
      oops or hard lockup when doing
      
       echo 0 > /proc/sys/kernel/nmi_watchdog
       echo 1 > /proc/sys/kernel/nmi_watchdog
      
      and the kernel is booted with nmi_watchdog=1 (default)
      
      Running laptop-mode-tools and disconnecting/connecting AC power will
      cause this to trigger, making it a common failure scenario on laptops.
      
      Instead of bailing out of watchdog_disable() when !watchdog_enabled we
      can initialize the hrtimer regardless of watchdog_enabled status.  This
      makes it safe to call watchdog_disable() in the nmi_watchdog=0 case,
      without the negative effect on the enabled => disabled => enabled case.
      
      All these tests pass with this patch:
      - nmi_watchdog=1
        echo 0 > /proc/sys/kernel/nmi_watchdog
        echo 1 > /proc/sys/kernel/nmi_watchdog
      
      - nmi_watchdog=0
        echo 0 > /sys/devices/system/cpu/cpu1/online
      
      - nmi_watchdog=0
        echo mem > /sys/power/state
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51661
      
      Cc: <stable@vger.kernel.org> # v3.7
      Cc: Norbert Warmuth <nwarmuth@t-online.de>
      Cc: Joseph Salisbury <joseph.salisbury@canonical.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3935e895
  21. 17 Dec, 2012 1 commit
  22. 04 Dec, 2012 1 commit
  23. 26 Nov, 2012 1 commit
  24. 13 Aug, 2012 1 commit
  25. 08 Aug, 2012 1 commit
  26. 30 Jul, 2012 1 commit
    • Sameer Nanda's avatar
      NMI watchdog: fix for lockup detector breakage on resume · 45226e94
      Sameer Nanda authored
      On the suspend/resume path the boot CPU does not go though an
      offline->online transition.  This breaks the NMI detector post-resume
      since it depends on PMU state that is lost when the system gets
      suspended.
      
      Fix this by forcing a CPU offline->online transition for the lockup
      detector on the boot CPU during resume.
      
      To provide more context, we enable NMI watchdog on Chrome OS.  We have
      seen several reports of systems freezing up completely which indicated
      that the NMI watchdog was not firing for some reason.
      
      Debugging further, we found a simple way of repro'ing system freezes --
      issuing the command 'tasket 1 sh -c "echo nmilockup > /proc/breakme"'
      after the system has been suspended/resumed one or more times.
      
      With this patch in place, the system freeze result in panics, as
      expected.
      
      These panics provide a nice stack trace for us to debug the actual issue
      causing the freeze.
      
      [akpm@linux-foundation.org: fiddle with code comment]
      [akpm@linux-foundation.org: make lockup_detector_bootcpu_resume() conditional on CONFIG_SUSPEND]
      [akpm@linux-foundation.org: fix section errors]
      Signed-off-by: default avatarSameer Nanda <snanda@chromium.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Mandeep Singh Baines <msb@chromium.org>
      Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      45226e94
  27. 14 Jun, 2012 1 commit
    • Don Zickus's avatar
      watchdog: Quiet down the boot messages · a7027046
      Don Zickus authored
      A bunch of bugzillas have complained how noisy the nmi_watchdog
      is during boot-up especially with its expected failure cases
      (like virt and bios resource contention).
      
      This is my attempt to quiet them down and keep it less confusing
      for the end user.  What I did is print the message for cpu0 and
      save it for future comparisons.  If future cpus have an
      identical message as cpu0, then don't print the redundant info.
      However, if a future cpu has a different message, happily print
      that loudly.
      
      Before the change, you would see something like:
      
          ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
          CPU0: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz stepping 0a
          Performance Events: PEBS fmt0+, Core2 events, Intel PMU driver.
          ... version:                2
          ... bit width:              40
          ... generic registers:      2
          ... value mask:             000000ffffffffff
          ... max period:             000000007fffffff
          ... fixed-purpose events:   3
          ... event mask:             0000000700000003
          NMI watchdog enabled, takes one hw-pmu counter.
          Booting Node   0, Processors  #1
          NMI watchdog enabled, takes one hw-pmu counter.
           #2
          NMI watchdog enabled, takes one hw-pmu counter.
           #3 Ok.
          NMI watchdog enabled, takes one hw-pmu counter.
          Brought up 4 CPUs
          Total of 4 processors activated (22607.24 BogoMIPS).
      
      After the change, it is simplified to:
      
          ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
          CPU0: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz stepping 0a
          Performance Events: PEBS fmt0+, Core2 events, Intel PMU driver.
          ... version:                2
          ... bit width:              40
          ... generic registers:      2
          ... value mask:             000000ffffffffff
          ... max period:             000000007fffffff
          ... fixed-purpose events:   3
          ... event mask:             0000000700000003
          NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
          Booting Node   0, Processors  #1 #2 #3 Ok.
          Brought up 4 CPUs
      
      V2: little changes based on Joe Perches' feedback
      V3: printk cleanup based on Ingo's feedback; checkpatch fix
      V4: keep printk as one long line
      V5: Ingo fix ups
      Reported-and-tested-by: default avatarNathan Zimmer <nzimmer@sgi.com>
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: nzimmer@sgi.com
      Cc: joe@perches.com
      Link: http://lkml.kernel.org/r/1339594548-17227-1-git-send-email-dzickus@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a7027046
  28. 08 Apr, 2012 1 commit
  29. 23 Mar, 2012 2 commits