summaryrefslogtreecommitdiffstats
path: root/arch/sparc/kernel/nmi.c
AgeCommit message (Collapse)AuthorFilesLines
2010-11-26perf, arch: Cleanup perf-pmu init vs lockup-detectorPeter Zijlstra1-2/+0
The perf hardware pmu got initialized at various points in the boot, some before early_initcall() some after (notably arch_initcall). The problem is that the NMI lockup detector is ran from early_initcall() and expects the hardware pmu to be present. Sanitize this by moving all architecture hardware pmu implementations to initialize at early_initcall() and move the lockup detector to an explicit initcall right after that. Cc: paulus <paulus@samba.org> Cc: davem <davem@davemloft.net> Cc: Michael Cree <mcree@orcon.net.nz> Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com> Acked-by: Paul Mundt <lethal@linux-sh.org> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <1290707759.2145.119.camel@laptop> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2010-04-14sparc64: Run NMIs on the hardirq stack.David S. Miller1-0/+7
Otherwise we can overflow the main stack with the function tracer enabled. Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-12sparc64: Use a seperate counter for timer interrupts and NMI checks, like x86.David S. Miller1-2/+1
This keeps us from having to use kstat_irqs_cpu() from the NMI handler, the former of which is a profiled function. Instead we use a currently empty slot in the cpu_data Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-02Merge branch 'master' into percpuTejun Heo1-1/+2
2010-01-05local_t: Remove leftover local.hChristoph Lameter1-1/+0
Somehow the local.h was not removed when taking out the local_t usage during the 2.6.32 merge. CC: David Miller <davem@davemloft.net> Signed-off-by: Christoph Lameter <cl@linux-foundation.org> Signed-off-by: Tejun Heo <tj@kernel.org>
2010-01-04sparc64: Fix NMI programming when perf events are active.David S. Miller1-1/+2
If perf events are active, we should not reset the %pcr to PCR_PIC_PRIV. That perf events code does the management. Signed-off-by: David S. Miller <davem@davemloft.net>
2009-10-29percpu: remove per_cpu__ prefix.Rusty Russell1-3/+3
Now that the return from alloc_percpu is compatible with the address of per-cpu vars, it makes sense to hand around the address of per-cpu variables. To make this sane, we remove the per_cpu__ prefix we used created to stop people accidentally using these vars directly. Now we have sparse, we can use that (next patch). tj: * Updated to convert stuff which were missed by or added after the original patch. * Kill per_cpu_var() macro. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Christoph Lameter <cl@linux-foundation.org>
2009-10-12this_cpu: Use this_cpu_xx in nmi handlingChristoph Lameter1-4/+4
this_cpu_inc/dec reduces the number of instructions needed. Signed-off-by: Christoph Lameter <cl@linux-foundation.org> Signed-off-by: Tejun Heo <tj@kernel.org>
2009-09-21perf: Do the big rename: Performance Counters -> Performance EventsIngo Molnar1-2/+2
Bye-bye Performance Counters, welcome Performance Events! In the past few months the perfcounters subsystem has grown out its initial role of counting hardware events, and has become (and is becoming) a much broader generic event enumeration, reporting, logging, monitoring, analysis facility. Naming its core object 'perf_counter' and naming the subsystem 'perfcounters' has become more and more of a misnomer. With pending code like hw-breakpoints support the 'counter' name is less and less appropriate. All in one, we've decided to rename the subsystem to 'performance events' and to propagate this rename through all fields, variables and API names. (in an ABI compatible fashion) The word 'event' is also a bit shorter than 'counter' - which makes it slightly more convenient to write/handle as well. Thanks goes to Stephane Eranian who first observed this misnomer and suggested a rename. User-space tooling and ABI compatibility is not affected - this patch should be function-invariant. (Also, defconfigs were not touched to keep the size down.) This patch has been generated via the following script: FILES=$(find * -type f | grep -vE 'oprofile|[^K]config') sed -i \ -e 's/PERF_EVENT_/PERF_RECORD_/g' \ -e 's/PERF_COUNTER/PERF_EVENT/g' \ -e 's/perf_counter/perf_event/g' \ -e 's/nb_counters/nb_events/g' \ -e 's/swcounter/swevent/g' \ -e 's/tpcounter_event/tp_event/g' \ $FILES for N in $(find . -name perf_counter.[ch]); do M=$(echo $N | sed 's/perf_counter/perf_event/g') mv $N $M done FILES=$(find . -name perf_event.*) sed -i \ -e 's/COUNTER_MASK/REG_MASK/g' \ -e 's/COUNTER/EVENT/g' \ -e 's/\<event\>/event_id/g' \ -e 's/counter/event/g' \ -e 's/Counter/Event/g' \ $FILES ... to keep it as correct as possible. This script can also be used by anyone who has pending perfcounters patches - it converts a Linux kernel tree over to the new naming. We tried to time this change to the point in time where the amount of pending patches is the smallest: the end of the merge window. Namespace clashes were fixed up in a preparatory patch - and some stylistic fallout will be fixed up in a subsequent patch. ( NOTE: 'counters' are still the proper terminology when we deal with hardware registers - and these sed scripts are a bit over-eager in renaming them. I've undone some of that, but in case there's something left where 'counter' would be better than 'event' we can undo that on an individual basis instead of touching an otherwise nicely automated patch. ) Suggested-by: Stephane Eranian <eranian@google.com> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: Paul Mackerras <paulus@samba.org> Reviewed-by: Arjan van de Ven <arjan@linux.intel.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: David Howells <dhowells@redhat.com> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: <linux-arch@vger.kernel.org> LKML-Reference: <new-submission> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-11Merge branch 'master' of /home/davem/src/GIT/linux-2.6/David S. Miller1-1/+1
Conflicts: arch/sparc/Kconfig
2009-09-10sparc64: Initial hw perf counter support.David S. Miller1-2/+6
Only supports one simple counter and only UltraSPARC-IIIi chips. Signed-off-by: David S. Miller <davem@davemloft.net>
2009-09-10sparc64: Use nmi_enter() and nmi_exit(), as needed.David S. Miller1-0/+5
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-09-08sparc64: Make touch_nmi_watchdog() actually work.David S. Miller1-2/+1
It guards it's actions on nmi_watchdog_active, but nothing ever sets that and it's initial value is zero. Signed-off-by: David S. Miller <davem@davemloft.net>
2009-09-08sparc64: Manage NMI watchdog enabling like x86.David S. Miller1-17/+43
Use a per-cpu 'wd_enabled' boolean and a global atomic_t count of watchdog NMI enabled cpus which is set to '-1' if something is wrong with the watchdog and it can't be used. Signed-off-by: David S. Miller <davem@davemloft.net>
2009-09-03sparc64: Kill spurious NMI watchdog triggers by increasing limit to 30 seconds.David S. Miller1-1/+1
This is a compromise and a temporary workaround for bootup NMI watchdog triggers some people see with qla2xxx devices present. This happens when, for example: CPU 0 is in the driver init and looping submitting mailbox commands to load the firmware, then waiting for completion. CPU 1 is receiving the device interrupts. CPU 1 is where the NMI watchdog triggers. CPU 0 is submitting mailbox commands fast enough that by the time CPU 1 returns from the device interrupt handler, a new one is pending. This sequence runs for more than 5 seconds. The problematic case is CPU 1's timer interrupt running when the barrage of device interrupts begin. Then we have: timer interrupt return for softirq checking pending, thus enable interrupts qla2xxx interrupt return qla2xxx interrupt return ... 5+ seconds pass final qla2xxx interrupt for fw load return run timer softirq return At some point in the multi-second qla2xxx interrupt storm we trigger the NMI watchdog on CPU 1 from the NMI interrupt handler. The timer softirq, once we get back to running it, is smart enough to run the timer work enough times to make up for the missed timer interrupts. However, the NMI watchdogs (both x86 and sparc) use the timer interrupt count to notice the cpu is wedged. But in the above scenerio we'll receive only one such timer interrupt even if we last all the way back to running the timer softirq. The default watchdog trigger point is only 5 seconds, which is pretty low (the softwatchdog triggers at 60 seconds). So increase it to 30 seconds for now. Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-29sparc64: Fix reset hangs on Niagara systems.David S. Miller1-1/+22
Hypervisor versions older than version 1.6.1 cannot handle leaving the profile counter overflow interrupt chirping when the system does a soft reset. So use a reboot notifier to shut off the NMI watchdog. Signed-off-by: David S. Miller <davem@davemloft.net>
2009-02-04sparc64: Call dump_stack() in die_nmi().David S. Miller1-0/+1
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-02-02sparc: fixup for sparseirq changesStephen Rothwell1-1/+1
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-30sparc64: Implement NMI watchdog on capable cpus.David S. Miller1-0/+224
Signed-off-by: David S. Miller <davem@davemloft.net>