On Wed, Jul 18, 2007 at 11:22:10AM +0400, Pavel Emelianov wrote: > Russell King wrote: > >On Wed, Jul 18, 2007 at 09:29:39AM +0400, Pavel Emelianov wrote: > >>Russell King wrote: > >>>On Tue, Jul 17, 2007 at 04:03:42AM -0700, [EMAIL PROTECTED] > >>>wrote: > >>>>From: Pavel Emelianov <[EMAIL PROTECTED]> > >>>> > >>>>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. > >>>A bug causes an oops. Oops are counted. So, why do we need this > >>>additional complexity when we already have the '#' counter in oops > >>>dumps? > >>> > >>>For instance, on ARM: > >>> > >>>Unable to handle kernel NULL pointer dereference at virtual address > >>>00000090 > >>>pgd = c0004000 > >>>[00000090] *pgd=00000000 > >>>Internal error: Oops: 817 [#1] > >>> ^^^^ > >>>This is the oops counter. Anything oops report from anyone other than > >>>the > >>>first should always be questioned. Also note that this counter is not > >>>re-settable at run time, unlike the taint flags. > >>> > >>Press SysRq-P and you won't see any oops-counters, but just the info that > >>the kernel is tainted. This is helpful to know that kernel oopsed when > >>observing the SysRq-p output. This is just one of the reasons. > > > >Maybe it'd make more sense to print the oops counter in places where > >the tainted status is printed? > > > > Maybe. But the "tainted" mask is a common way to tell people that the > kernel is not clean. Besides, the "D" taint flag and "non-zero" oops > counter both mean the same thing, while "D" looks better.
The oops counter provides further (obvious) information. However, if it's no longer needed due to adding the "D" taint flag, it can be removed entirely. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
