On Thu, 07 Jun 2007 16:51:50 +0400 Pavel Emelianov wrote:
> 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.
>
> The p
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.
The previous version was buggy and reported the kernel
to be tainted at the
Pavel Emelianov <[EMAIL PROTECTED]>
>> To: Andrew Morton <[EMAIL PROTECTED]>,
>>Linux Kernel Mailing List ,
>>[EMAIL PROTECTED]
>> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
>> Subject: [PATCH] Report that kernel is tainted if there were an OOPS before
t;[EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
>Subject: [PATCH] Report that kernel is tainted if there were an OOPS before
>(v2)
>
>If the kernel OOPS-ed or BUG-ed then it probably should
>considered as tainted. Use die_counter introduced by many
>arch
If the kernel OOPS-ed or BUG-ed then it probably should
considered as tainted. Use die_counter introduced by many
architectures to determine whether or not the kernel died.
This saves a lot of time explaining oddities in the
calltrace seen via SysRq-P.
Signed-off-by: Pavel Emelianov <[EMAIL PROTE
On Mon, 16 Apr 2007 14:23:26 +0400 Pavel Emelianov wrote:
> If the kernel OOPS-ed or BUG-ed then it probably should
> considered as tainted. Use die_counter introduced by many
> architectures to determine whether or not the kernel died.
>
> This saves a lot of time explaining oddities in the
> ca
If the kernel OOPS-ed or BUG-ed then it probably should
considered as tainted. Use die_counter introduced by many
architectures to determine whether or not the kernel died.
This saves a lot of time explaining oddities in the
calltrace seen via SysRq-P.
diff --git a/arch/arm/kernel/traps.c b/arch/a
7 matches
Mail list logo