aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/oops-tracing.txt
Commit message (Collapse)AuthorAge
* panic: Add taint flag TAINT_FIRMWARE_WORKAROUND ('I')Ben Hutchings2010-05-19
| | | | | | | | This taint flag will initially be used when warning about invalid ACPI DMAR tables. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* panic: Allow warnings to set different taint flagsBen Hutchings2010-05-19
| | | | | | | | | | | | | | | | | WARN() is used in some places to report firmware or hardware bugs that are then worked-around. These bugs do not affect the stability of the kernel and should not set the flag for TAINT_WARN. To allow for this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint number as argument. Architectures that implement warnings using trap instructions instead of calls to warn_slowpath_*() now implement __WARN_TAINT(taint) instead of __WARN(). Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Acked-by: Helge Deller <deller@gmx.de> Tested-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
* docs: Describe the 'C' taint flag in oops-tracing.txtNick Bowler2009-11-09
| | | | | | | | If some of the flags are documented there, they all should be. Signed-off-by: Nick Bowler <nbowler@elliptictech.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Taint kernel after WARN_ON(condition)Nur Hussein2008-04-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel is sent to tainted within the warn_on_slowpath() function, and whenever a warning occurs the new taint flag 'W' is set. This is useful to know if a warning occurred before a BUG by preserving the warning as a flag in the taint state. This does not work on architectures where WARN_ON has its own definition. These archs are: 1. s390 2. superh 3. avr32 4. parisc The maintainers of these architectures have been added in the Cc: list in this email to alert them to the situation. The documentation in oops-tracing.txt has been updated to include the new flag. Signed-off-by: Nur Hussein <nurhussein@gmail.com> Cc: Arjan van de Ven <arjan@infradead.org> Cc: "Randy.Dunlap" <rdunlap@xenotime.net> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Report that kernel is tainted if there was an OOPSPavel Emelianov2007-07-17
| | | | | | | | | | | | | | 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>
* doc/oops-tracing: add Code: decode infoRandy Dunlap2007-07-16
| | | | | | | | | | | | | Add info that the Code: bytes line contains <xy> or (wxyz) in some architecture oops reports and what that means. Add a script by Andi Kleen that reads the Code: line from an Oops report file and generates assembly code from the hex bytes. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* doc: fix oops-tracing duplicateMichal Piotrowski2007-05-08
| | | | | | | | | Remove duplicate 'U' entry -- fix mis-merge. Signed-off-by: Michal Piotrowski <michal.k.k.piotrowski@gmail.com> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] update Doc/oops-tracing.txt for TAINT_USERRandy Dunlap2007-02-20
| | | | | | | | | Add TAINT_USER description to Tainted flags in oops-tracing.txt. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] doc: refer to kdump in oops-tracing.txtAkinobu Mita2006-01-11
| | | | | | | | | | Kdump has been merged and supported on several architectures. It is better to encourage to use kdump rather than non standard kernel crash dump patches. Signed-off-by: Akinobu Mita <mita@miraclelinux.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] oops-tracing: mention extended VGADave Jones2005-11-15
| | | | | | | | | Something I've found handy countless times when users do this.. Signed-off-by: Dave Jones <davej@redhat.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] oops-tracing: mention digital photosDiego Calleja2005-11-13
| | | | | Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] ksymoops related docs updateJesper Juhl2005-11-07
| | | | | | | | Update ksymoops related documentation to reflect current 2.6 reality. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Doc: update oops-tracing.txt (Tainted flags)Randy Dunlap2005-09-13
| | | | | | | | | | | Update Documentation/oops-tracing.txt: - add descriptions of 3 more "Tainted" flags; - fix some typos; Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2Linus Torvalds2005-04-16
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!