aboutsummaryrefslogtreecommitdiff
path: root/arch/alpha/kernel/traps.c
AgeCommit message (Collapse)Author
2008-11-30false __cpuinit positives on alphaAl Viro
pure noise - alpha doesn't have CPU hotplug Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-06-20alpha: fix compile failures with gcc-4.3 (bug #10438)Ivan Kokshaysky
Vast majority of these build failures are gcc-4.3 warnings about static functions and objects being referenced from non-static (read: "extern inline") functions, in conjunction with our -Werror. We cannot just convert "extern inline" to "static inline", as people keep suggesting all the time, because "extern inline" logic is crucial for generic kernel build. So - just make sure that all callees of critical "extern inline" functions are also "extern inline"; - use "static inline", wherever it's possible. traps.c: work around gcc-4.3 being too smart about array bounds-checking. TODO: add "gnu_inline" attribute to all our "extern inline" functions to ensure desired behaviour with future compilers. Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-28arch/alpha/kernel/traps.c: use time_* macrosS.Caglar Onur
The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. So implement usage of the time_after() macro, defined in linux/jiffies.h, which deals with wrapping correctly [akpm@linux-foundation.org: fix warning] Signed-off-by: S.Caglar Onur <caglar@pardus.org.tr> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-19Use helpers to obtain task pid in printks (arch code)Alexey Dobriyan
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 <adobriyan@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-17Report that kernel is tainted if there was an OOPSPavel Emelianov
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 <xemul@openvz.org> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> [ Added parisc patch from Matthew Wilson -Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2005-10-02[PATCH] alpha: fix kernel alignment trapsRichard Henderson
Pass in the pointer to the on-stack registers rather than using them directly as the arguments. Ivan noticed that I missed a spot when purging the registers as first stack parameter idiom. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-30[PATCH] alpha smp fixIvan Kokshaysky
As usual, the reason of this breakage is quite silly: in do_entIF, we are checking for PS == 0 to see whether it was a kernel BUG() or userspace trap. It works, unless BUG() happens in interrupt - PS is not 0 in kernel mode due to non-zero IPL, and the things get messed up horribly then. In this particular case it was BUG_ON(!irqs_disabled()) triggered in run_posix_cpu_timers(), so we ended up shooting "current" with the bursts of one SIGTRAP and three SIGILLs on every timer tick. ;-)
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!