aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* perf: Convert perf tracing data into a tracing_data eventTom Zanussi2010-04-14
| | | | | | | | | | | | | | | | | | | | | | | Bypasses the tracing_data perf header code and replaces it with a synthesized event and processing function that accomplishes the same thing, used when reading/writing perf data to/from a pipe. The tracing data is pretty large, and this patch doesn't attempt to break it down into component events. The tracing_data event itself doesn't actually contain the tracing data, rather it arranges for the event processing code to skip over it after it's read, using the skip return value added to the event processing loop in a previous patch. Signed-off-by: Tom Zanussi <tzanussi@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: fweisbec@gmail.com Cc: rostedt@goodmis.org Cc: k-keiichi@bx.jp.nec.com Cc: acme@ghostprotocols.net LKML-Reference: <1270184365-8281-8-git-send-email-tzanussi@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* perf: Convert perf event types into event type eventsTom Zanussi2010-04-14
| | | | | | | | | | | | | | | Bypasses the event type perf header code and replaces it with a synthesized event and processing function that accomplishes the same thing, used when reading/writing perf data to/from a pipe. Signed-off-by: Tom Zanussi <tzanussi@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: fweisbec@gmail.com Cc: rostedt@goodmis.org Cc: k-keiichi@bx.jp.nec.com Cc: acme@ghostprotocols.net LKML-Reference: <1270184365-8281-7-git-send-email-tzanussi@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* perf: Convert perf header attrs into attr eventsTom Zanussi2010-04-14
| | | | | | | | | | | | | | | | | | | | Bypasses the attr perf header code and replaces it with a synthesized event and processing function that accomplishes the same thing, used when reading/writing perf data to/from a pipe. Making the attrs into events allows them to be streamed over a pipe along with the rest of the header data (in later patches). It also paves the way to allowing events to be added and removed from perf sessions dynamically. Signed-off-by: Tom Zanussi <tzanussi@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: fweisbec@gmail.com Cc: rostedt@goodmis.org Cc: k-keiichi@bx.jp.nec.com Cc: acme@ghostprotocols.net LKML-Reference: <1270184365-8281-6-git-send-email-tzanussi@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* perf trace: Introduce special handling for pipe inputTom Zanussi2010-04-14
| | | | | | | | | | | | | | | | | | | Adds special treatment for stdin - if the user specifies '-i -' to perf trace, the intent is that the event stream be read from stdin rather than from a disk file. The actual handling of the '-' filename is done by the session; this just adds a signal handler to stop reporting, and turns off interference by the pager. Signed-off-by: Tom Zanussi <tzanussi@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: fweisbec@gmail.com Cc: rostedt@goodmis.org Cc: k-keiichi@bx.jp.nec.com Cc: acme@ghostprotocols.net LKML-Reference: <1270184365-8281-5-git-send-email-tzanussi@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* perf report: Introduce special handling for pipe inputTom Zanussi2010-04-14
| | | | | | | | | | | | | | | | | | | Adds special treatment for stdin - if the user specifies '-i -' to perf report, the intent is that the event stream be written to stdin rather than from a disk file. The actual handling of the '-' filename is done by the session; this just adds a signal handler to stop reporting, and turns off interference by the pager. Signed-off-by: Tom Zanussi <tzanussi@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: fweisbec@gmail.com Cc: rostedt@goodmis.org Cc: k-keiichi@bx.jp.nec.com Cc: acme@ghostprotocols.net LKML-Reference: <1270184365-8281-4-git-send-email-tzanussi@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* perf record: Introduce special handling for pipe outputTom Zanussi2010-04-14
| | | | | | | | | | | | | | | | | | | | Adds special treatment for stdout - if the user specifies '-o -' to perf record, the intent is that the event stream be written to stdout rather than to a disk file. Also, redirect stdout of forked child to stderr - in pipe mode, stdout of the forked child interferes with the stdout perf stream, so redirect it to stderr where it can still be seen but won't be mixed in with the perf output. Signed-off-by: Tom Zanussi <tzanussi@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: fweisbec@gmail.com Cc: rostedt@goodmis.org Cc: k-keiichi@bx.jp.nec.com Cc: acme@ghostprotocols.net LKML-Reference: <1270184365-8281-3-git-send-email-tzanussi@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* perf: Add pipe-specific header read/write and event processing codeTom Zanussi2010-04-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes several changes to allow the perf event stream to be sent and received over a pipe: - adds pipe-specific versions of the header read/write code - adds pipe-specific version of the event processing code - adds a range of event types to be used for header or other pseudo events, above the range used by the kernel - checks the return value of event handlers, which they can use to skip over large events during event processing rather than actually reading them into event objects. - unifies the multiple do_read() functions and updates its users. Note that none of these changes affect the existing perf data file format or processing - this code only comes into play if perf output is sent to stdout (or is read from stdin). Signed-off-by: Tom Zanussi <tzanussi@gmail.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: fweisbec@gmail.com Cc: rostedt@goodmis.org Cc: k-keiichi@bx.jp.nec.com Cc: acme@ghostprotocols.net LKML-Reference: <1270184365-8281-2-git-send-email-tzanussi@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* perf: Fix endianness argument compatibility with OPT_BOOLEAN() and introduce ↵Ian Munsie2010-04-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OPT_INCR() Parsing an option from the command line with OPT_BOOLEAN on a bool data type would not work on a big-endian machine due to the manner in which the boolean was being cast into an int and incremented. For example, running 'perf probe --list' on a PowerPC machine would fail to properly set the list_events bool and would therefore print out the usage information and terminate. This patch makes OPT_BOOLEAN work as expected with a bool datatype. For cases where the original OPT_BOOLEAN was intentionally being used to increment an int each time it was passed in on the command line, this patch introduces OPT_INCR with the old behaviour of OPT_BOOLEAN (the verbose variable is currently the only such example of this). I have reviewed every use of OPT_BOOLEAN to verify that a true C99 bool was passed. Where integers were used, I verified that they were only being used for boolean logic and changed them to bools to ensure that they would not be mistakenly used as ints. The major exception was the verbose variable which now uses OPT_INCR instead of OPT_BOOLEAN. Signed-off-by: Ian Munsie <imunsie@au.ibm.com> Acked-by: David S. Miller <davem@davemloft.net> Cc: <stable@kernel.org> # NOTE: wont apply to .3[34].x cleanly, please backport Cc: Git development list <git@vger.kernel.org> Cc: Ian Munsie <imunsie@au1.ibm.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Eric B Munson <ebmunson@us.ibm.com> Cc: Valdis.Kletnieks@vt.edu Cc: WANG Cong <amwang@redhat.com> Cc: Thiago Farina <tfransosi@gmail.com> Cc: Masami Hiramatsu <mhiramat@redhat.com> Cc: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Cc: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Mike Galbraith <efault@gmx.de> Cc: Tom Zanussi <tzanussi@gmail.com> Cc: Anton Blanchard <anton@samba.org> Cc: John Kacur <jkacur@redhat.com> Cc: Li Zefan <lizf@cn.fujitsu.com> Cc: Steven Rostedt <rostedt@goodmis.org> LKML-Reference: <1271147857-11604-1-git-send-email-imunsie@au.ibm.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* perf tools: Fix perl support installation when O= is usedArnaldo Carvalho de Melo2010-04-09
| | | | | | | | | | | We need to create the $O/scripts/perl/Perf-Trace-Util/ directory too. Cc: Frédéric Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> LKML-Reference: <new-submission> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
* perf trace: Ignore "overwrite" field if present in /events/header_pageArnaldo Carvalho de Melo2010-04-08
| | | | | | | | | | | | | | | | | | | | | | That is not used in perf where we have the LOST events. Without this patch we get: [root@doppio ~]# perf lock report | head -3 Warning: Error: expected 'data' but read 'overwrite' So, to make the same perf command work with kernels with and without this field, introduce variants for the parsing routines to not warn the user in such case. Discussed-with: Steven Rostedt <rostedt@goodmis.org> Cc: Frédéric Weisbecker <fweisbec@gmail.com> Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> LKML-Reference: <new-submission> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
* perf: cleanup some DocumentationRandy Dunlap2010-04-08
| | | | | | | | | Correct typos in perf bench & perf sched help text. Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>, Cc: Paul Mackerras <paulus@samba.org> LKML-Reference: <20100331113100.cc898487.randy.dunlap@oracle.com> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
* perf bench: fix spelloRandy Dunlap2010-04-08
| | | | | | | | | Fix spello in user message. Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>, Cc: Paul Mackerra <paulus@samba.org>s LKML-Reference: <20100331113056.2c7df509.randy.dunlap@oracle.com> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
* perf tools: Reorganize some structs to save spaceArnaldo Carvalho de Melo2010-04-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using 'pahole --packable' I found some structs that could be reorganized to eliminate alignment holes, in some cases getting them to be cacheline multiples. [acme@doppio linux-2.6-tip]$ codiff perf.old ~/bin/perf builtin-annotate.c: struct perf_session | -8 struct perf_header | -8 2 structs changed builtin-diff.c: struct sample_data | -8 1 struct changed diff__process_sample_event | -8 1 function changed, 8 bytes removed, diff: -8 builtin-sched.c: struct sched_atom | -8 1 struct changed builtin-timechart.c: struct per_pid | -8 1 struct changed cmd_timechart | -16 1 function changed, 16 bytes removed, diff: -16 builtin-probe.c: struct perf_probe_point | -8 struct perf_probe_event | -8 2 structs changed opt_add_probe_event | -3 1 function changed, 3 bytes removed, diff: -3 util/probe-finder.c: struct probe_finder | -8 1 struct changed find_kprobe_trace_events | -16 1 function changed, 16 bytes removed, diff: -16 /home/acme/bin/perf: 4 functions changed, 43 bytes removed, diff: -43 [acme@doppio linux-2.6-tip]$ Cc: Frédéric Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> LKML-Reference: <new-submission> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
* perf TUI: Move "Yes" button to before "No"Arnaldo Carvalho de Melo2010-04-08
| | | | | | | | | | | | Esc + Enter should be enough warning to avoid accidentaly exiting from the browser. Cc: Frédéric Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> LKML-Reference: <new-submission> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
* perf TUI: Show filters on the title and add help line about how to zoom outArnaldo Carvalho de Melo2010-04-08
| | | | | | | | | | Suggested-by: Ingo Molnar <molnar@elte.hu> Cc: Frédéric Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> LKML-Reference: <new-submission> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
* Merge branch 'linus' into perf/coreIngo Molnar2010-04-08
|\ | | | | | | | | | | | | | | Semantic conflict: arch/x86/kernel/cpu/perf_event_intel_ds.c Merge reason: pick up latest fixes, fix the conflict Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * Merge git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linusLinus Torvalds2010-04-07
| |\ | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus: hvc_console: Fix race between hvc_close and hvc_remove virtio: disable multiport console support. virtio: console makes incorrect assumption about virtio API virtio: console: Fix early_put_chars usage MAINTAINERS: Put the virtio-console entry in correct alphabetical order
| | * hvc_console: Fix race between hvc_close and hvc_removeAnton Blanchard2010-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I don't claim to understand the tty layer, but it seems like hvc_open and hvc_close should be balanced in their kref reference counting. Right now we get a kref every call to hvc_open: if (hp->count++ > 0) { tty_kref_get(tty); <----- here spin_unlock_irqrestore(&hp->lock, flags); hvc_kick(); return 0; } /* else count == 0 */ tty->driver_data = hp; hp->tty = tty_kref_get(tty); <------ or here if hp->count was 0 But hvc_close has: tty_kref_get(tty); if (--hp->count == 0) { ... /* Put the ref obtained in hvc_open() */ tty_kref_put(tty); ... } tty_kref_put(tty); Since the outside kref get/put balance we only do a single kref_put when count reaches 0. The patch below changes things to call tty_kref_put once for every hvc_close call, and with that my machine boots fine. Signed-off-by: Anton Blanchard <anton@samba.org> Acked-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| | * virtio: disable multiport console support.Michael S. Tsirkin2010-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move MULTIPORT feature and related config changes out of exported headers, and disable the feature at runtime. At this point, it seems less risky to keep code around until we can enable it than rip it out completely. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| | * virtio: console makes incorrect assumption about virtio APIRusty Russell2010-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The get_buf() API sets the second arg to the number of bytes *written* by the other side; in this case it should be zero as these are output buffers. lguest gets this right (obviously kvm's console doesn't), resulting in continual buildup of console writes. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Amit Shah <amit.shah@redhat.com>
| | * virtio: console: Fix early_put_chars usageFrançois Diakhaté2010-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently early_put_chars is not used by virtio_console because it can only be used once a port has been found, at which point it's too late because it is no longer needed. This patch should fix it. Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| | * MAINTAINERS: Put the virtio-console entry in correct alphabetical orderAmit Shah2010-04-07
| | | | | | | | | | | | | | | | | | | | | Move around the entry for virtio-console to keep the file sorted. Signed-off-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| * | rwsem generic spinlock: use IRQ save/restore spinlocksKevin Hilman2010-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rwsems can be used with IRQs disabled, particularily in early boot before IRQs are enabled. Currently the spin_unlock_irq() usage in the slow-patch will unconditionally enable interrupts and cause problems since interrupts are not yet initialized or enabled. This patch uses save/restore versions of IRQ spinlocks in the slowpath to ensure interrupts are not unintentionally disabled. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * | Have nfs ->d_revalidate() report errors properlyAl Viro2010-04-07
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If nfs atomic open implementation ends up doing open request from ->d_revalidate() codepath and gets an error from server, return that error to caller explicitly and don't bother with lookup_instantiate_filp() at all. ->d_revalidate() can return an error itself just fine... See http://bugzilla.kernel.org/show_bug.cgi?id=15674 http://marc.info/?l=linux-kernel&m=126988782722711&w=2 for original report. Reported-by: Daniel J Blueman <daniel.blueman@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * Merge branch 'perf-fixes-for-linus' of ↵Linus Torvalds2010-04-07
| |\ | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: perf, x86: Enable Nehalem-EX support perf kmem: Fix breakage introduced by 5a0e3ad slab.h script
| | * perf, x86: Enable Nehalem-EX supportVince Weaver2010-04-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to Intel Software Devel Manual Volume 3B, the Nehalem-EX PMU is just like regular Nehalem (except for the uncore support, which is completely different). Signed-off-by: Vince Weaver <vweaver1@eecs.utk.edu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Lin Ming <ming.m.lin@intel.com> LKML-Reference: <alpine.DEB.2.00.1004060956580.1417@cl320.eecs.utk.edu> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| | * perf kmem: Fix breakage introduced by 5a0e3ad slab.h scriptArnaldo Carvalho de Melo2010-04-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 5a0e3ad ("include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h") added a '#include <linux/slab.h>' to tools/perf/builtin-kmem.h because: that tool has lines like this: if (!strcmp(event->name, "kmalloc") || !strcmp(event->name, "kmem_cache_alloc")) { process_alloc_event(data, event, cpu, timestamp, thread, 0); return; } So, using the script regex: >>> import re >>> s = re.compile(r'^(|.*[^a-zA-Z0-9_])_*(slab_is_available|kmem_cache_|k[mzc]alloc|krealloc|kz?free|ksize|__getname|putname)') >>> l = ' !strcmp(event->name, "kmem_cache_alloc")) {' >>> s.search(l) <_sre.SRE_Match object at 0xb77b1ad0> >>> Remove that file that is not available in the tools/perf include path and thus builtin-kmem.c couldn't be compiled. Reported-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Christoph Lameter <cl@linux-foundation.org> Cc: Frédéric Weisbecker <fweisbec@gmail.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Tejun Heo <tj@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> LKML-Reference: <1270561053-14308-1-git-send-email-acme@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| * | Merge branch 'davinci-fixes-for-linus' of ↵Linus Torvalds2010-04-07
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci * 'davinci-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci: davinci: fix compile warning: <mach/da8xx.h>: #include <linux/platform_device.h> davinci: DM365: fix duplicate default IRQ priorities davinci: edma: clear events in edma_start() davinci: da8xx/omap-l1: fix build error when CONFIG_DAVINCI_MUX is undefined davinci: timers: don't enable timer until clocksource is initialized
| | * | davinci: fix compile warning: <mach/da8xx.h>: #include <linux/platform_device.h>Sergei Shtylyov2010-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This hushes the following warning: arch/arm/mach-davinci/include/mach/da8xx.h:104: warning: ‘struct platform_device’ declared inside parameter list arch/arm/mach-davinci/include/mach/da8xx.h:104: warning: its scope is only this definition or declaration, which is probably not what you want Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
| | * | davinci: DM365: fix duplicate default IRQ prioritiesKevin Hilman2010-04-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IRQ 29 has two possible interrupts DDRINT and RTC, but having both in the default priority table is confusing (and triggers a warning from sparse.) This patch removes the lower priority DDRINT from the default priority table leaving the RTC setting as the default. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
| | * | davinci: edma: clear events in edma_start()Brian Niebuhr2010-04-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes an issue where a DMA channel can erroneously process an event generated by a previous transfer. A failure case is where DMA is being used for SPI transmit and receive channels on OMAP L138. In this case there is a single bit that controls all event generation from the SPI peripheral. Therefore it is possible that between when edma_stop() has been called for the transmit channel on a previous transfer and edma_start() is called for the transmit channel on a subsequent transfer, that a transmit event has been generated. The fix is to clear events in edma_start(). This prevents false events from being processed when events are enabled for that channel. Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
| | * | davinci: da8xx/omap-l1: fix build error when CONFIG_DAVINCI_MUX is undefinedSekhar Nori2010-04-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The da8xx/omap-l1 boards refuse to build when CONFIG_DAVINCI_MUX is undefined because arch/arm/mach-davinci/mux.c:da8xx_pinmux_setup() is not defined. This patch fixes this issue. This is build tested with davinci_all_defconfig and da8xx_omapl_defconfig and boot tested on DA830 EVM. Reported-by: Shanmuga Sundaram Mahendran <shanmuga@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
| | * | davinci: timers: don't enable timer until clocksource is initializedKevin Hilman2010-04-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On da830, when the same timer is used for clocksource and clockevent, the timer can be started before the clockevent is registered/initialzed. This creates a window where a timer interrupt might fire before the clockevent handler has been setup and causes a crash. This patch moves the actual enable/start of the timer after the clockevent has ben registered. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
| * | | Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds2010-04-07
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip: x86: Fix double enable_IR_x2apic() call on SMP kernel on !SMP boards x86: Increase CONFIG_NODES_SHIFT max to 10 ibft, x86: Change reserve_ibft_region() to find_ibft_region() x86, hpet: Fix bug in RTC emulation x86, hpet: Erratum workaround for read after write of HPET comparator bootmem, x86: Fix 32bit numa system without RAM on node 0 nobootmem, x86: Fix 32bit numa system without RAM on node 0 x86: Handle overlapping mptables x86: Make e820_remove_range to handle all covered case x86-32, resume: do a global tlb flush in S4 resume
| | * | | x86: Fix double enable_IR_x2apic() call on SMP kernel on !SMP boardsSuresh Siddha2010-04-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jan Grossmann reported kernel boot panic while booting SMP kernel on his system with a single core cpu. SMP kernels call enable_IR_x2apic() from native_smp_prepare_cpus() and on platforms where the kernel doesn't find SMP configuration we ended up again calling enable_IR_x2apic() from the APIC_init_uniprocessor() call in the smp_sanity_check(). Thus leading to kernel panic. Don't call enable_IR_x2apic() and default_setup_apic_routing() from APIC_init_uniprocessor() in CONFIG_SMP case. NOTE: this kind of non-idempotent and assymetric initialization sequence is rather fragile and unclean, we'll clean that up in v2.6.35. This is the minimal fix for v2.6.34. Reported-by: Jan.Grossmann@kielnet.net Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: <jbarnes@virtuousgeek.org> Cc: <david.woodhouse@intel.com> Cc: <weidong.han@intel.com> Cc: <youquan.song@intel.com> Cc: <Jan.Grossmann@kielnet.net> Cc: <stable@kernel.org> # [v2.6.32.x, v2.6.33.x] LKML-Reference: <1270083887.7835.78.camel@sbs-t61.sc.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| | * | | x86: Increase CONFIG_NODES_SHIFT max to 10David Rientjes2010-04-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some larger systems require more than 512 nodes, so increase the maximum CONFIG_NODES_SHIFT to 10 for a new max of 1024 nodes. This was tested with numa=fake=64M on systems with more than 64GB of RAM. A total of 1022 nodes were initialized. Successfully builds with no additional warnings on x86_64 allyesconfig. ( No effect on any existing config. Newly enabled CONFIG_MAXSMP=y will see the new default. ) Signed-off-by: David Rientjes <rientjes@google.com> LKML-Reference: <alpine.DEB.2.00.1003251538060.8589@chino.kir.corp.google.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| | * | | ibft, x86: Change reserve_ibft_region() to find_ibft_region()Yinghai Lu2010-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows arch code could decide the way to reserve the ibft. And we should reserve ibft as early as possible, instead of BOOTMEM stage, in case the table is in RAM range and is not reserved by BIOS (this will often be the case.) Move to just after find_smp_config(). Also when CONFIG_NO_BOOTMEM=y, We will not have reserve_bootmem() anymore. -v2: fix typo about ibft pointed by Konrad Rzeszutek Wilk <konrad@darnok.org> Signed-off-by: Yinghai Lu <yinghai@kernel.org> LKML-Reference: <4BB510FB.80601@kernel.org> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Peter Jones <pjones@redhat.com> Cc: Konrad Rzeszutek Wilk <konrad@kernel.org> CC: Jan Beulich <jbeulich@novell.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
| | * | | x86, hpet: Fix bug in RTC emulationAlok Kataria2010-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We think there exists a bug in the HPET code that emulates the RTC. In the normal case, when the RTC frequency is set, the rtc driver tells the hpet code about it here: int hpet_set_periodic_freq(unsigned long freq) { uint64_t clc; if (!is_hpet_enabled()) return 0; if (freq <= DEFAULT_RTC_INT_FREQ) hpet_pie_limit = DEFAULT_RTC_INT_FREQ / freq; else { clc = (uint64_t) hpet_clockevent.mult * NSEC_PER_SEC; do_div(clc, freq); clc >>= hpet_clockevent.shift; hpet_pie_delta = (unsigned long) clc; } return 1; } If freq is set to 64Hz (DEFAULT_RTC_INT_FREQ) or lower, then hpet_pie_limit (a static) is set to non-zero. Then, on every one-shot HPET interrupt, hpet_rtc_timer_reinit is called to compute the next timeout. Well, that function has this logic: if (!(hpet_rtc_flags & RTC_PIE) || hpet_pie_limit) delta = hpet_default_delta; else delta = hpet_pie_delta; Since hpet_pie_limit is not 0, hpet_default_delta is used. That corresponds to 64Hz. Now, if you set a different rtc frequency, you'll take the else path through hpet_set_periodic_freq, but unfortunately no one resets hpet_pie_limit back to 0. Boom....now you are stuck with 64Hz RTC interrupts forever. The patch below just resets the hpet_pie_limit value when requested freq is greater than DEFAULT_RTC_INT_FREQ, which we think fixes this problem. Signed-off-by: Alok N Kataria <akataria@vmware.com> LKML-Reference: <201003112200.o2BM0Hre012875@imap1.linux-foundation.org> Signed-off-by: Daniel Hecht <dhecht@vmware.com> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
| | * | | x86, hpet: Erratum workaround for read after write of HPET comparatorPallipadi, Venkatesh2010-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Wed, Feb 24, 2010 at 03:37:04PM -0800, Justin Piszcz wrote: > Hello, > > Again, on the Intel DP55KG board: > > # uname -a > Linux host 2.6.33 #1 SMP Wed Feb 24 18:31:00 EST 2010 x86_64 GNU/Linux > > [ 1.237600] ------------[ cut here ]------------ > [ 1.237890] WARNING: at arch/x86/kernel/hpet.c:404 hpet_next_event+0x70/0x80() > [ 1.238221] Hardware name: > [ 1.238504] hpet: compare register read back failed. > [ 1.238793] Modules linked in: > [ 1.239315] Pid: 0, comm: swapper Not tainted 2.6.33 #1 > [ 1.239605] Call Trace: > [ 1.239886] <IRQ> [<ffffffff81056c13>] ? warn_slowpath_common+0x73/0xb0 > [ 1.240409] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0 > [ 1.240699] [<ffffffff81056cb0>] ? warn_slowpath_fmt+0x40/0x50 > [ 1.240992] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0 > [ 1.241281] [<ffffffff81041ad0>] ? hpet_next_event+0x70/0x80 > [ 1.241573] [<ffffffff81079608>] ? tick_dev_program_event+0x38/0xc0 > [ 1.241859] [<ffffffff81078e32>] ? tick_handle_oneshot_broadcast+0xe2/0x100 > [ 1.246533] [<ffffffff8102a67a>] ? timer_interrupt+0x1a/0x30 > [ 1.246826] [<ffffffff81085499>] ? handle_IRQ_event+0x39/0xd0 > [ 1.247118] [<ffffffff81087368>] ? handle_edge_irq+0xb8/0x160 > [ 1.247407] [<ffffffff81029f55>] ? handle_irq+0x15/0x20 > [ 1.247689] [<ffffffff810294a2>] ? do_IRQ+0x62/0xe0 > [ 1.247976] [<ffffffff8146be53>] ? ret_from_intr+0x0/0xa > [ 1.248262] <EOI> [<ffffffff8102f277>] ? mwait_idle+0x57/0x80 > [ 1.248796] [<ffffffff8102645c>] ? cpu_idle+0x5c/0xb0 > [ 1.249080] ---[ end trace db7f668fb6fef4e1 ]--- > > Is this something Intel has to fix or is it a bug in the kernel? This is a chipset erratum. Thomas: You mentioned we can retain this check only for known-buggy and hpet debug kind of options. But here is the simple workaround patch for this particular erratum. Some chipsets have a erratum due to which read immediately following a write of HPET comparator returns old comparator value instead of most recently written value. Erratum 15 in "Intel I/O Controller Hub 9 (ICH9) Family Specification Update" (http://www.intel.com/assets/pdf/specupdate/316973.pdf) Workaround for the errata is to read the comparator twice if the first one fails. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> LKML-Reference: <20100225185348.GA9674@linux-os.sc.intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@gmail.com> Cc: <stable@kernel.org>
| | * | | bootmem, x86: Fix 32bit numa system without RAM on node 0Yinghai Lu2010-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When 32bit numa is used, free_all_bootmem() will still only go over with node id 0. If node 0 doesn't have RAM installed, the lowest populated node becomes low RAM. This one fixes BOOTMEM path by iterating over the bdata_list. -v3: add more comments, and fix bootmem path too. -v4: seperate from one big patch Signed-off-by: Yinghai Lu <yinghai@kernel.org> LKML-Reference: <4BB416D7.6090203@kernel.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
| | * | | nobootmem, x86: Fix 32bit numa system without RAM on node 0Yinghai Lu2010-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On one system without RAM on node0, got following boot dump with a 32 bit NUMA kernel: early_node_map[4] active PFN ranges 1: 0x00000010 -> 0x00000099 1: 0x00000100 -> 0x0007da00 1: 0x0007e800 -> 0x0007ffa0 1: 0x0007ffae -> 0x0007ffb0 ... Subtract (29 early reservations) #000 [0000001000 - 0000002000] #001 [0000089000 - 000008f000] #002 [0000091000 - 0000093500] ... #027 [007cbfef40 - 007e800000] #028 [007e9ca000 - 007ff95000] (0 free memory ranges) Initializing HighMem for node 0 (00000000:00000000) Initializing HighMem for node 1 (00000000:00000000) Memory: 0k/2096832k available (6662k kernel code, 2096300k reserved, 4829k data, 484k init, 0k highmem) ... Checking if this processor honours the WP bit even in supervisor mode...Ok. swapper: page allocation failure. order:0, mode:0x0 Pid: 0, comm: swapper Not tainted 2.6.34-rc3-tip-03818-g4b1ea6c-dirty #35 Call Trace: [<4087a5dc>] ? printk+0xf/0x11 [<40286728>] __alloc_pages_nodemask+0x417/0x487 [<402a9ce1>] new_slab+0xe2/0x1fe [<402aa5b2>] kmem_cache_open+0x185/0x358 [<402abbc0>] T.954+0x1c/0x60 [<40d52a29>] kmem_cache_init+0x24/0x113 [<40d39738>] start_kernel+0x166/0x2e4 [<40d3940e>] ? unknown_bootoption+0x0/0x18e [<40d390ce>] i386_start_kernel+0xce/0xd5 Mem-Info: Node 1 DMA per-cpu: CPU 0: hi: 0, btch: 1 usd: 0 Node 1 Normal per-cpu: CPU 0: hi: 0, btch: 1 usd: 0 active_anon:0 inactive_anon:0 isolated_anon:0 active_file:0 inactive_file:0 isolated_file:0 unevictable:0 dirty:0 writeback:0 unstable:0 free:0 slab_reclaimable:0 slab_unreclaimable:0 mapped:0 shmem:0 pagetables:0 bounce:0 When 32bit NUMA is used, free_all_bootmem() will still only go over with node id 0. If node 0 doesn't have RAM installed, We need to go with node1 because early_node_map still use 1 for all ranges, and ram from node1 become low ram. Use MAX_NUMNODES like 64-bit NUMA does. Note: BOOTMEM path has the same problem. this bug exist before We have NO_BOOTMEM support. -v3: add more comments, and fix bootmem path too. -v4: seperate bootmem path fix Signed-off-by: Yinghai Lu <yinghai@kernel.org> LKML-Reference: <4BB41689.9090502@kernel.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
| | * | | x86: Handle overlapping mptablesAndi Kleen2010-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We found a system where the MP table MPC and MPF structures overlap. That doesn't really matter because the mptable is not used anyways with ACPI, but it leads to a panic in the early allocator due to the overlapping reservations in 2.6.33. Earlier kernels handled this without problems. Simply change these reservations to reserve_early_overlap_ok to avoid the panic. Reported-by: Thomas Renninger <trenn@suse.de> Tested-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com> LKML-Reference: <20100329074111.GA22821@basil.fritz.box> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: <stable@kernel.org>
| | * | | x86: Make e820_remove_range to handle all covered caseYinghai Lu2010-03-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rusty found on lguest with trim_bios_range, max_pfn is not right anymore, and looks e820_remove_range does not work right. [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] LGUEST: 0000000000000000 - 0000000004000000 (usable) [ 0.000000] Notice: NX (Execute Disable) protection missing in CPU or disabled in BIOS! [ 0.000000] DMI not present or invalid. [ 0.000000] last_pfn = 0x3fa0 max_arch_pfn = 0x100000 [ 0.000000] init_memory_mapping: 0000000000000000-0000000003fa0000 root cause is: the e820_remove_range doesn't handle the all covered case. e820_remove_range(BIOS_START, BIOS_END - BIOS_START, ...) produces a bogus range as a result. Make it match e820_update_range() by handling that case too. Reported-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Tested-by: Rusty Russell <rusty@rustcorp.com.au> LKML-Reference: <4BB18E55.6090903@kernel.org> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
| | * | | x86-32, resume: do a global tlb flush in S4 resumeShaohua Li2010-03-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Colin King reported a strange oops in S4 resume code path (see below). The test system has i5/i7 CPU. The kernel doesn't open PAE, so 4M page table is used. The oops always happen a virtual address 0xc03ff000, which is mapped to the last 4k of first 4M memory. Doing a global tlb flush fixes the issue. EIP: 0060:[<c0493a01>] EFLAGS: 00010086 CPU: 0 EIP is at copy_loop+0xe/0x15 EAX: 36aeb000 EBX: 00000000 ECX: 00000400 EDX: f55ad46c ESI: 0f800000 EDI: c03ff000 EBP: f67fbec4 ESP: f67fbea8 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 ... ... CR2: 00000000c03ff000 Tested-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> LKML-Reference: <20100305005932.GA22675@sli10-desk.sh.intel.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: <stable@kernel.org>
| * | | | Merge branch 'for-linus' of git://git.monstr.eu/linux-2.6-microblazeLinus Torvalds2010-04-07
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'for-linus' of git://git.monstr.eu/linux-2.6-microblaze: microblaze: Remove unused variable from ptrace microblaze: io.h: Add io big-endian function microblaze: Enable memory leak detector microblaze: Fix futex code microblaze: Fix ftrace_update_ftrace_func panic
| | * | | | microblaze: Remove unused variable from ptraceMichal Simek2010-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch b3c1e01a09d6af2dd7811a066ffcfc5171be2bed should do it. Signed-off-by: Michal Simek <monstr@monstr.eu>
| | * | | | microblaze: io.h: Add io big-endian functionJohn Linn2010-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add new io big-endian function. They will be used for uartlite and spi driver. Signed-off-by: John Linn <john.linn@xilinx.com> Signed-off-by: Michal Simek <monstr@monstr.eu>
| | * | | | microblaze: Enable memory leak detectorMichal Simek2010-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable DEBUG_KMEMLEAK for microblaze Signed-off-by: Michal Simek <monstr@monstr.eu>
| | * | | | microblaze: Fix futex codeMichal Simek2010-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use logical and NOT for ANDN. It was likely type fault. Signed-off-by: Michal Simek <monstr@monstr.eu>
| | * | | | microblaze: Fix ftrace_update_ftrace_func panicSteven J. Magnani2010-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Microblaze dynamic ftrace code assumes a call ordering that is not met in all scenarios. Specifically, executing a command similar to: echo 105 > /sys/kernel/debug/tracing/set_ftrace_pid before any other tracing-related commands results in a kernel panic: BUG: failure at arch/microblaze/kernel/ftrace.c:198/ftrace_update_ftrace_func()! Recoding ftrace_update_ftrace_func() to use &ftrace_caller directly eliminates the need to capture its address elsewhere (and thus rely on a particular call sequence). Signed-off-by: Steven J. Magnani <steve@digidescorp.com> Signed-off-by: Michal Simek <monstr@monstr.eu>