1. 29 10月, 2009 1 次提交
  2. 12 10月, 2009 1 次提交
  3. 24 9月, 2009 1 次提交
  4. 03 8月, 2009 1 次提交
    • I
      debug lockups: Improve lockup detection, fix generic arch fallback · 47cab6a7
      Ingo Molnar 提交于
      As Andrew noted, my previous patch ("debug lockups: Improve lockup
      detection") broke/removed SysRq-L support from architecture that do
      not provide a __trigger_all_cpu_backtrace implementation.
      
      Restore a fallback path and clean up the SysRq-L machinery a bit:
      
       - Rename the arch method to arch_trigger_all_cpu_backtrace()
      
       - Simplify the define
      
       - Document the method a bit - in the hope of more architectures
         adding support for it.
      
      [ The patch touches Sparc code for the rename. ]
      
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      LKML-Reference: <20090802140809.7ec4bb6b.akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      47cab6a7
  5. 02 8月, 2009 1 次提交
    • I
      debug lockups: Improve lockup detection · c1dc0b9c
      Ingo Molnar 提交于
      When debugging a recent lockup bug i found various deficiencies
      in how our current lockup detection helpers work:
      
       - SysRq-L is not very efficient as it uses a workqueue, hence
         it cannot punch through hard lockups and cannot see through
         most soft lockups either.
      
       - The SysRq-L code depends on the NMI watchdog - which is off
         by default.
      
       - We dont print backtraces from the RCU code's built-in
         'RCU state machine is stuck' debug code. This debug
         code tends to be one of the first (and only) mechanisms
         that show that a lockup has occured.
      
      This patch changes the code so taht we:
      
       - Trigger the NMI backtrace code from SysRq-L instead of using
         a workqueue (which cannot punch through hard lockups)
      
       - Trigger print-all-CPU-backtraces from the RCU lockup detection
         code
      
      Also decouple the backtrace printing code from the NMI watchdog:
      
       - Dont use variable size cpumasks (it might not be initialized
         and they are a bit more fragile anyway)
      
       - Trigger an NMI immediately via an IPI, instead of waiting
         for the NMI tick to occur. This is a lot faster and can
         produce more relevant backtraces. It will also work if the
         NMI watchdog is disabled.
      
       - Dont print the 'dazed and confused' message when we print
         a backtrace from the NMI
      
       - Do a show_regs() plus a dump_stack() to get maximum info
         out of the dump. Worst-case we get two stacktraces - which
         is not a big deal. Sometimes, if register content is
         corrupted, the precise stack walker in show_regs() wont
         give us a full backtrace - in this case dump_stack() will
         do it.
      
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c1dc0b9c
  6. 10 7月, 2009 1 次提交
  7. 29 5月, 2009 1 次提交
    • A
      x86, mce: use 64bit machine check code on 32bit · 4efc0670
      Andi Kleen 提交于
      The 64bit machine check code is in many ways much better than
      the 32bit machine check code: it is more specification compliant,
      is cleaner, only has a single code base versus one per CPU,
      has better infrastructure for recovery, has a cleaner way to communicate
      with user space etc. etc.
      
      Use the 64bit code for 32bit too.
      
      This is the second attempt to do this. There was one a couple of years
      ago to unify this code for 32bit and 64bit.  Back then this ran into some
      trouble with K7s and was reverted.
      
      I believe this time the K7 problems (and some others) are addressed.
      I went over the old handlers and was very careful to retain
      all quirks.
      
      But of course this needs a lot of testing on old systems. On newer
      64bit capable systems I don't expect much problems because they have been
      already tested with the 64bit kernel.
      
      I made this a CONFIG for now that still allows to select the old
      machine check code. This is mostly to make testing easier,
      if someone runs into a problem we can ask them to try
      with the CONFIG switched.
      
      The new code is default y for more coverage.
      
      Once there is confidence the 64bit code works well on older hardware
      too the CONFIG_X86_OLD_MCE and the associated code can be easily
      removed.
      
      This causes a behaviour change for 32bit installations. They now
      have to install the mcelog package to be able to log
      corrected machine checks.
      
      The 64bit machine check code only handles CPUs which support the
      standard Intel machine check architecture described in the IA32 SDM.
      The 32bit code has special support for some older CPUs which
      have non standard machine check architectures, in particular
      WinChip C3 and Intel P5.  I made those a separate CONFIG option
      and kept them for now. The WinChip variant could be probably
      removed without too much pain, it doesn't really do anything
      interesting. P5 is also disabled by default (like it
      was before) because many motherboards have it miswired, but
      according to Alan Cox a few embedded setups use that one.
      
      Forward ported/heavily changed version of old patch, original patch
      included review/fixes from Thomas Gleixner, Bert Wesarg.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      4efc0670
  8. 21 4月, 2009 2 次提交
  9. 12 4月, 2009 1 次提交
    • J
      x86: clean up declarations and variables · 2c1b284e
      Jaswinder Singh Rajput 提交于
      Impact: cleanup, no code changed
      
       - syscalls.h       update declarations due to unifications
       - irq.c            declare smp_generic_interrupt() before it gets used
       - process.c        declare sys_fork() and sys_vfork() before they get used
       - tsc.c            rename tsc_khz shadowed variable
       - apic/probe_32.c  declare apic_default before it gets used
       - apic/nmi.c       prev_nmi_count should be unsigned
       - apic/io_apic.c   declare smp_irq_move_cleanup_interrupt() before it gets used
       - mm/init.c        declare direct_gbpages and free_initrd_mem before they get used
      Signed-off-by: NJaswinder Singh Rajput <jaswinder@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2c1b284e
  10. 13 3月, 2009 1 次提交
  11. 18 2月, 2009 2 次提交
  12. 17 2月, 2009 1 次提交
  13. 29 1月, 2009 1 次提交
  14. 18 1月, 2009 1 次提交
  15. 06 1月, 2009 1 次提交
  16. 03 1月, 2009 1 次提交
  17. 31 10月, 2008 1 次提交
  18. 28 10月, 2008 2 次提交
  19. 23 9月, 2008 1 次提交
    • A
      x86, NMI watchdog: setup before enabling NMI watchdog · b3e15bde
      Aristeu Rozanski 提交于
      There's a small window when NMI watchdog is being set up that if any NMIs
      are triggered, the NMI code will make make use of not initalized wd_ops
      elements:
      	void setup_apic_nmi_watchdog(void *unused)
      	{
      		if (__get_cpu_var(wd_enabled))
      			return;
      
      		/* cheap hack to support suspend/resume */
      		/* if cpu0 is not active neither should the other cpus */
      		if (smp_processor_id() != 0 && atomic_read(&nmi_active) <= 0)
      			return;
      
      		switch (nmi_watchdog) {
      		case NMI_LOCAL_APIC:
      			/* enable it before to avoid race with handler */
      -->			__get_cpu_var(wd_enabled) = 1;
      -->			if (lapic_watchdog_init(nmi_hz) < 0) {
      (...)
      	asmlinkage notrace __kprobes void default_do_nmi(struct pt_regs *regs)
      	{
      	(...)
      			if (nmi_watchdog_tick(regs, reason))
      				return;
      (...)
      	notrace __kprobes int
      	nmi_watchdog_tick(struct pt_regs *regs, unsigned reason)
      	{
      	(...)
      		if (!__get_cpu_var(wd_enabled))
      			return rc;
      		switch (nmi_watchdog) {
      		case NMI_LOCAL_APIC:
      			rc |= lapic_wd_event(nmi_hz);
      (...)
      int lapic_wd_event(unsigned nmi_hz)
      {
      	struct nmi_watchdog_ctlblk *wd = &__get_cpu_var(nmi_watchdog_ctlblk);
      	u64 ctr;
      
      -->	rdmsrl(wd->perfctr_msr, ctr);
      
      and wd->*_msr will be initialized on each processor type specific setup, after
      enabling NMIs for PMIs. Since the counter was just set, the chances of an
      performance counter generated NMI is minimal, but any other unknown NMI would
      trigger the problem. This patch fixes the problem by setting everything up
      before enabling performance counter generated NMIs and will set wd_enabled
      using a callback function.
      Signed-off-by: NAristeu Rozanski <aris@redhat.com>
      Acked-by: NDon Zickus <dzickus@redhat.com>
      Acked-by: NPrarit Bhargava <prarit@redhat.com>
      Acked-by: NVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b3e15bde
  20. 15 8月, 2008 2 次提交
    • I
      x86, nmi: clean UP NMI watchdog failure message · 8bb85190
      Ingo Molnar 提交于
      clean up the failure message - and redirect people to bugzilla
      instead of lkml.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8bb85190
    • A
      x86, NMI: fix watchdog failure message · 15636668
      Aristeu Rozanski 提交于
      > it just won't work at boot time - the second logic unit will be stuck:
      >
      > Booting processor 1/2 APIC 0x1
      > Initializing CPU#1
      > Calibrating delay using timer specific routine.. 5586.12 BogoMIPS (lpj=2793063)
      > CPU: Trace cache: 12K uops, L1 D cache: 16K
      > CPU: L2 cache: 1024K
      > CPU: Physical Processor ID: 0
      > CPU: Processor Core ID: 1
      > CPU1: Thermal monitoring enabled (TM1)
      >               Intel(R) Pentium(R) D CPU 2.80GHz stepping 04
      > Brought up 2 CPUs
      > testing NMI watchdog ... <4>WARNING: CPU#1: NMI appears to be stuck (0->0)!
      
      while at it... - fix that newline
      Signed-off-by: NAristeu Rozanski <aris@redhat.com>
      Cc: jvillalo@redhat.com
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      15636668
  21. 20 7月, 2008 1 次提交
  22. 18 7月, 2008 1 次提交
    • M
      x86: APIC: remove apic_write_around(); use alternatives · 593f4a78
      Maciej W. Rozycki 提交于
      Use alternatives to select the workaround for the 11AP Pentium erratum
      for the affected steppings on the fly rather than build time.  Remove the
      X86_GOOD_APIC configuration option and replace all the calls to
      apic_write_around() with plain apic_write(), protecting accesses to the
      ESR as appropriate due to the 3AP Pentium erratum.  Remove
      apic_read_around() and all its invocations altogether as not needed.
      Remove apic_write_atomic() and all its implementing backends.  The use of
      ASM_OUTPUT2() is not strictly needed for input constraints, but I have
      used it for readability's sake.
      
      I had the feeling no one else was brave enough to do it, so I went ahead
      and here it is.  Verified by checking the generated assembly and tested
      with both a 32-bit and a 64-bit configuration, also with the 11AP
      "feature" forced on and verified with gdb on /proc/kcore to work as
      expected (as an 11AP machines are quite hard to get hands on these days).
      Some script complained about the use of "volatile", but apic_write() needs
      it for the same reason and is effectively a replacement for writel(), so I
      have disregarded it.
      
      I am not sure what the policy wrt defconfig files is, they are generated
      and there is risk of a conflict resulting from an unrelated change, so I
      have left changes to them out.  The option will get removed from them at
      the next run.
      
      Some testing with machines other than mine will be needed to avoid some
      stupid mistake, but despite its volume, the change is not really that
      intrusive, so I am fairly confident that because it works for me, it will
      everywhere.
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      593f4a78
  23. 12 7月, 2008 1 次提交
  24. 08 7月, 2008 3 次提交
  25. 19 6月, 2008 1 次提交
  26. 12 6月, 2008 1 次提交
  27. 05 6月, 2008 2 次提交
    • M
      x86, nmi: fix build · 75b9f5d2
      mingo@elte.hu 提交于
      fix:
      
      arch/x86/kernel/built-in.o: In function `proc_nmi_enabled':
      : undefined reference to `nmi_watchdog_default'
      arch/x86/kernel/built-in.o: In function `native_smp_prepare_cpus':
      : undefined reference to `nmi_watchdog_default'
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      75b9f5d2
    • C
      x86: nmi - consolidate nmi_watchdog_default for 32bit mode · 3ed3f062
      Cyrill Gorcunov 提交于
      64bit mode bootstrap code does set nmi_watchdog to NMI_NONE
      by default and doing the same on 32bit mode is safe too.
      Such an action saves us from several #ifdef.
      
      Btw, my previous commit
      
      commit 19ec673c
      Author: Cyrill Gorcunov <gorcunov@gmail.com>
      Date:   Wed May 28 23:00:47 2008 +0400
      
          x86: nmi - fix incorrect NMI watchdog used by default
      
      did not fix the problem completely, moreover it
      introduced additional bug - nmi_watchdog would be
      set to either NMI_LOCAL_APIC or NMI_IO_APIC
      _regardless_ to boot option if being enabled thru
      /proc/sys/kernel/nmi_watchdog. Sorry for that.
      Fix it too.
      Signed-off-by: NCyrill Gorcunov <gorcunov@gmail.com>
      Cc: mingo@redhat.com
      Cc: hpa@zytor.com
      Cc: macro@linux-mips.org
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      3ed3f062
  28. 02 6月, 2008 2 次提交
  29. 29 5月, 2008 1 次提交
  30. 26 5月, 2008 3 次提交