| Age | Commit message (Collapse) | Author |
|---|
|
Fixes WARN_ON() on bitfiels ops for all architectures that have
been left out in 8d4fbcfbe0a4bfc73e7f0297c59ae514e1f1436f.
Cc: Alexey Dobriyan <adobriyan@sw.ru>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Kyle McMartin <kyle@parisc-linux.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Previously this was only set when CONFIG_BUG=y. While we rely
on that for handle_BUG() dispatch, we still want to hand the
opcode off to the die chain notifier for determining the trap
value.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
Wire up GENERIC_BUG for SH. This moves off of the special bug
frame and on to the generic struct bug_entry. Roughly the same
semantics are retained, and we can kill off some of the verbose
BUG() reporting code.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
Previously we haven't been doing anything with verbose BUG() reporting,
and we've been relying on the oops path for handling BUG()'s, which is
rather sub-optimal.
This switches BUG handling to use a fixed trapa vector (#0x3e) where we
construct a small bug frame post trapa instruction to get the context
right. This also makes it trivial to wire up a DIE_BUG for the atomic
die chain, which we couldn't really do before.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
|
|
This patch eliminates all kernel BUGs, trims about 35k off the typical
kernel, and makes the system slightly faster.
Signed-off-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
