1. 25 1月, 2014 3 次提交
  2. 13 11月, 2013 1 次提交
    • J
      x86/dumpstack: Fix printk_address for direct addresses · 5f01c988
      Jiri Slaby 提交于
      Consider a kernel crash in a module, simulated the following way:
      
       static int my_init(void)
       {
               char *map = (void *)0x5;
               *map = 3;
               return 0;
       }
       module_init(my_init);
      
      When we turn off FRAME_POINTERs, the very first instruction in
      that function causes a BUG. The problem is that we print IP in
      the BUG report using %pB (from printk_address). And %pB
      decrements the pointer by one to fix printing addresses of
      functions with tail calls.
      
      This was added in commit 71f9e598 ("x86, dumpstack: Use
      %pB format specifier for stack trace") to fix the call stack
      printouts.
      
      So instead of correct output:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000005
        IP: [<ffffffffa01ac000>] my_init+0x0/0x10 [pb173]
      
      We get:
      
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000005
        IP: [<ffffffffa0152000>] 0xffffffffa0151fff
      
      To fix that, we use %pS only for stack addresses printouts (via
      newly added printk_stack_address) and %pB for regs->ip (via
      printk_address). I.e. we revert to the old behaviour for all
      except call stacks. And since from all those reliable is 1, we
      remove that parameter from printk_address.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: joe@perches.com
      Cc: jirislaby@gmail.com
      Link: http://lkml.kernel.org/r/1382706418-8435-1-git-send-email-jslaby@suse.czSigned-off-by: NIngo Molnar <mingo@kernel.org>
      5f01c988
  3. 12 11月, 2013 1 次提交
    • I
      Revert "x86/UV: Add uvtrace support" · b5dfcb09
      Ingo Molnar 提交于
      This reverts commit 8eba1842.
      
      uv_trace() is not used by anything, nor is uv_trace_nmi_func, nor
      uv_trace_func.
      
      That's not how we do instrumentation code in the kernel: we add
      tracepoints, printk()s, etc. so that everyone not just those with
      magic kernel modules can debug a system.
      
      So remove this unused (and misguied) piece of code.
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      Cc: Hedi Berriche <hedi@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/n/tip-tumfBffmr4jmnt8Gyxanoblg@git.kernel.org
      b5dfcb09
  4. 04 10月, 2013 1 次提交
    • M
      x86/UV: Add call to KGDB/KDB from NMI handler · e379ea82
      Mike Travis 提交于
      This patch restores the capability to enter KDB (and KGDB) from
      the UV NMI handler.  This is needed because the UV system
      console is not capable of sending the 'break' signal to the
      serial console port.  It is also useful when the kernel is hung
      in such a way that it isn't responding to normal external I/O,
      so sending 'g' to sysreq-trigger does not work either.
      
      Another benefit of the external NMI command is that all the cpus
      receive the NMI signal at roughly the same time so they are more
      closely aligned timewise.
      
      It utilizes the newly added kgdb_nmicallin function to gain
      entry to KGDB/KDB by the master.  The slaves still enter via the
      standard kgdb_nmicallback function.  It also uses the new
      'send_ready' pointer to tell KGDB/KDB to signal the slaves when
      to proceed into the KGDB slave loop.
      
      It is enabled when the nmi action is set to "kdb" and the kernel
      is built with CONFIG_KDB enabled.  Note that if kgdb is
      connected that interface will be used instead.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: NHedi Berriche <hedi@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/r/20131002151418.089692683@asylum.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      e379ea82
  5. 24 9月, 2013 6 次提交
    • I
      x86/UV: Check for alloc_cpumask_var() failures properly in uv_nmi_setup() · 8a1f4653
      Ingo Molnar 提交于
      GCC warned about:
      
         arch/x86/platform/uv/uv_nmi.c: In function ‘uv_nmi_setup’:
         arch/x86/platform/uv/uv_nmi.c:664:2: warning: the address of ‘uv_nmi_cpu_mask’ will always evaluate as ‘true’
      
      The reason is this code:
      
              alloc_cpumask_var(&uv_nmi_cpu_mask, GFP_KERNEL);
              BUG_ON(!uv_nmi_cpu_mask);
      
      which is not the way to check for alloc_cpumask_var() failures - its
      return code should be checked instead.
      
      Cc: Mike Travis <travis@sgi.com>
      Link: http://lkml.kernel.org/n/tip-2pXRemsjupmvonbpmmnzleo1@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      8a1f4653
    • M
      x86/UV: Add uvtrace support · 8eba1842
      Mike Travis 提交于
      This patch adds support for the uvtrace module by providing a
      skeleton call to the registered trace function.  It also
      provides another separate 'NMI' tracer that is triggered by the
      system wide 'power nmi' command.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: NHedi Berriche <hedi@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/r/20130923212501.185052551@asylum.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      8eba1842
    • M
      x86/UV: Add kdump to UV NMI handler · 12ba6c99
      Mike Travis 提交于
      If a system has hung and it no longer responds to external
      events, this patch adds the capability of doing a standard kdump
      and system reboot then triggered by the system NMI command.
      
      It is enabled when the nmi action is changed to "kdump" and the
      kernel is built with CONFIG_KEXEC enabled.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: NHedi Berriche <hedi@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/r/20130923212500.660567460@asylum.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      12ba6c99
    • M
      x86/UV: Add summary of cpu activity to UV NMI handler · 3c121d9a
      Mike Travis 提交于
      The standard NMI handler dumps the states of all the cpus.  This
      includes a full register dump and stack trace.  This can be way
      more information than what is needed.  This patch adds a
      "summary" dump that is basically a form of the "ps" command.  It
      includes the symbolic IP address as well as the command field
      and basic process information.
      
      It is enabled when the nmi action is changed to "ips".
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: NHedi Berriche <hedi@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/r/20130923212500.507922930@asylum.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3c121d9a
    • M
      x86/UV: Update UV support for external NMI signals · 0d12ef0c
      Mike Travis 提交于
      The current UV NMI handler has not been updated for the changes
      in the system NMI handler and the perf operations.  The UV NMI
      handler reads an MMR in the UV Hub to check to see if the NMI
      event was caused by the external 'system NMI' that the operator
      can initiate on the System Mgmt Controller.
      
      The problem arises when the perf tools are running, causing
      millions of perf events per second on very large CPU count
      systems.  Previously this was okay because the perf NMI handler
      ran at a higher priority on the NMI call chain and if the NMI
      was a perf event, it would stop calling other NMI handlers
      remaining on the NMI call chain.
      
      Now the system NMI handler calls all the handlers on the NMI
      call chain including the UV NMI handler.  This causes the UV NMI
      handler to read the MMRs at the same millions per second rate.
      This can lead to significant performance loss and possible
      system failures.  It also can cause thousands of 'Dazed and
      Confused' messages being sent to the system console.  This
      effectively makes perf tools unusable on UV systems.
      
      To avoid this excessive overhead when perf tools are running,
      this code has been optimized to minimize reading of the MMRs as
      much as possible, by moving to the NMI_UNKNOWN notifier chain.
      This chain is called only when all the users on the standard
      NMI_LOCAL call chain have been called and none of them have
      claimed this NMI.
      
      There is an exception where the NMI_LOCAL notifier chain is
      used.  When the perf tools are in use, it's possible that the UV
      NMI was captured by some other NMI handler and then either
      ignored or mistakenly processed as a perf event.  We set a
      per_cpu ('ping') flag for those CPUs that ignored the initial
      NMI, and then send them an IPI NMI signal.  The NMI_LOCAL
      handler on each cpu does not need to read the MMR, but instead
      checks the in memory flag indicating it was pinged.  There are
      two module variables, 'ping_count' indicating how many requested
      NMI events occurred, and 'ping_misses' indicating how many stray
      NMI events.  These most likely are perf events so it shows the
      overhead of the perf NMI interrupts and how many MMR reads were avoided.
      
      This patch also minimizes the reads of the MMRs by having the
      first cpu entering the NMI handler on each node set a per HUB
      in-memory atomic value.  (Having a per HUB value avoids sending
      lock traffic over NumaLink.)  Both types of UV NMIs from the SMI
      layer are supported.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: NHedi Berriche <hedi@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/r/20130923212500.353547733@asylum.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      0d12ef0c
    • M
      x86/UV: Move NMI support · 1e019421
      Mike Travis 提交于
      This patch moves the UV NMI support from the x2apic file to a
      new separate uv_nmi.c file in preparation for the next sequence
      of patches. It prevents upcoming bloat of the x2apic file, and
      has the added benefit of putting the upcoming /sys/module
      parameters under the name 'uv_nmi' instead of 'x2apic_uv_x',
      which was obscure.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: NHedi Berriche <hedi@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/r/20130923212500.183295611@asylum.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1e019421