user/sven/linux.git/arch/xtensa/kernel/traps.c, branch v3.2.58

Remove multiple KERN_ prefixes from printk formats

2009-07-08T17:30:03Z

Commit 5fd29d6ccbc98884569d6f3105aeca70858b3e0f ("printk: clean up handling of log-levels and newlines") changed printk semantics. printk lines with multiple KERN_ prefixes are no longer emitted as before the patch. is now included in the output on each additional use. Remove all uses of multiple KERN_s in formats. Signed-off-by: Joe Perches Signed-off-by: Linus Torvalds

xtensa: always use correct stack pointer for stack traces

2009-05-12T04:59:43Z

Commit '28a0ce7 xtensa: use correct stack pointer for stack traces' changed the stack tracer from always reading the stack pointer register to always using the saved value in the task descriptor. The author was too dense to consider the fact that the saved stack value is stale for a running process und thus unusable for 'current'. What we do now is to use the stack pointer register (a1) for when the task is unknown - we can't help it then - or when the task is 'current'. For everything else use the saved stack pointer value contained in the task descriptor. Signed-off-by: Johannes Weiner Signed-off-by: Chris Zankel

xtensa: nommu support

2009-04-03T06:41:50Z

Add support for !CONFIG_MMU setups. Signed-off-by: Johannes Weiner Signed-off-by: Chris Zankel

xtensa: use correct stack pointer for stack traces

2009-04-03T06:38:57Z

Right now, the xtensa stacktrace code reads the _current_ kernel stack pointer if nothing is supplied. With debugging facilities like sysrq this means that the backtrace of the sysrq-handler is printed instead of a trace of the given task's stack. When no stack pointer is specified in show_trace() and show_stack(), use the stack pointer that comes with the handed in task descriptor to make stack traces more useful. Signed-off-by: Johannes Weiner Signed-off-by: Chris Zankel

xtensa: fix compilation somewhat

2009-03-10T22:55:10Z

* ->put_char changes * HIGHMEM is bogus it seems, there is no kmap_atomic() et al * some includes Signed-off-by: Alexey Dobriyan Acked-by: Chris Zankel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[XTENSA] Add support for configurable registers and coprocessors

2008-02-14T01:41:43Z

The Xtensa architecture allows to define custom instructions and registers. Registers that are bound to a coprocessor are only accessible if the corresponding enable bit is set, which allows to implement a 'lazy' context switch mechanism. Other registers needs to be saved and restore at the time of the context switch or during interrupt handling. This patch adds support for these additional states: - save and restore registers that are used by the compiler upon interrupt entry and exit. - context switch additional registers unbound to any coprocessor - 'lazy' context switch of registers bound to a coprocessor - ptrace interface to provide access to additional registers - update configuration files in include/asm-xtensa/variant-fsf Signed-off-by: Chris Zankel

[XTENSA] Clean up elf-gregset.

2008-02-14T01:09:08Z

Remove additional registers from the ELF gregset structure that are only used by the kernel or are not required or invalid in user-space. The ar registers are always aligned to a windowbase value of 0, and the WB register is always assumed to be 0. Increase the size of the structure to 128 entries. This will provide enough space in future. Signed-off-by: Chris Zankel

Use helpers to obtain task pid in printks (arch code)

2007-10-19T18:53:43Z

One of the easiest things to isolate is the pid printed in kernel log. There was a patch, that made this for arch-independent code, this one makes so for arch/xxx files. It took some time to cross-compile it, but hopefully these are all the printks in arch code. Signed-off-by: Alexey Dobriyan Signed-off-by: Pavel Emelyanov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[XTENSA] fix wrong usage of init and initdata in traps.c

2007-08-27T20:52:49Z

A variable was defined with __init instead of __initdata and the function accessing that variable wasn't initialized with __init. Signed-off-by: Chris Zankel

Report that kernel is tainted if there was an OOPS

2007-07-17T17:23:02Z

If the kernel OOPSed or BUGed then it probably should be considered as tainted. Thus, all subsequent OOPSes and SysRq dumps will report the tainted kernel. This saves a lot of time explaining oddities in the calltraces. Signed-off-by: Pavel Emelianov Acked-by: Randy Dunlap Cc: Signed-off-by: Andrew Morton [ Added parisc patch from Matthew Wilson -Linus ] Signed-off-by: Linus Torvalds