07 Nov, 2011
1 commit
-
Use of the GPL or a compatible licence doesn't necessarily make the code
any good. We already consider staging modules to be suspect, and this
should also be true for out-of-tree modules which may receive very
little review.Signed-off-by: Ben Hutchings
Reviewed-by: Dave Jones
Acked-by: Greg Kroah-Hartman
Signed-off-by: Rusty Russell (patched oops-tracing.txt)
27 Jul, 2011
1 commit
-
When a kernel BUG or oops occurs, ChromeOS intends to panic and
immediately reboot, with stacktrace and other messages preserved in RAM
across reboot.But the longer we delay, the more likely the user is to poweroff and
lose the info.panic_timeout (seconds before rebooting) is set by panic= boot option or
sysctl or /proc/sys/kernel/panic; but 0 means wait forever, so at
present we have to delay at least 1 second.Let a negative number mean reboot immediately (with the small cosmetic
benefit of suppressing that newline-less "Rebooting in %d seconds.."
message).Signed-off-by: Hugh Dickins
Signed-off-by: Mandeep Singh Baines
Cc: Huang Ying
Cc: Andi Kleen
Cc: Hugh Dickins
Cc: Olaf Hering
Cc: Jesse Barnes
Cc: Dave Airlie
Cc: Greg Kroah-Hartman
Cc: Alan Cox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
23 Mar, 2011
1 commit
-
The oops=panic cmdline option is not x86 specific, move it to generic code.
Update documentation.Signed-off-by: Olaf Hering
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
12 Jan, 2011
1 commit
-
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying
Reviewed-by: Andi Kleen
Signed-off-by: Len Brown
11 Aug, 2010
2 commits
-
We are missing the oops end marker for the exception based WARN implementation
in lib/bug.c. This is useful for logfile analysis tools.Signed-off-by: Anton Blanchard
Cc: Ingo Molnar
Cc: Arjan van de Ven
Cc: "Kirill A. Shutemov"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
To keep panic_timeout accuracy when running under a hypervisor, the
current implementation only spins on long time (1 second) calls to mdelay.
That brings a good effect, but the problem is the keyboard LEDs don't
blink at all on that situation.This patch changes to call to panic_blink_enter() between every mdelay and
keeps blinking in spite of long spin timer mode.The time to call to mdelay is now 100ms. Even this change will keep
panic_timeout accuracy enough when running under a hypervisor.Signed-off-by: TAMUKI Shoichi
Cc: Ben Dooks
Cc: Russell King
Acked-by: Dmitry Torokhov
Cc: Anton Blanchard
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
28 May, 2010
1 commit
-
Most distros turn the console verbosity down and that means a backtrace
after a panic never makes it to the console. I assume we haven't seen
this because a panic is often preceeded by an oops which will have called
console_verbose. There are however a lot of places we call panic
directly, and they are broken.Use console_verbose like we do in the oops path to ensure a directly
called panic will print a backtrace.Signed-off-by: Anton Blanchard
Acked-by: Greg Kroah-Hartman
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
19 May, 2010
2 commits
-
This taint flag will initially be used when warning about invalid ACPI
DMAR tables.Signed-off-by: Ben Hutchings
Signed-off-by: David Woodhouse -
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
Acked-by: Helge Deller
Tested-by: Paul Mundt
Signed-off-by: David Woodhouse
07 Mar, 2010
1 commit
-
I've had some complaints about panic_timeout being wildly innacurate on
shared processor PowerPC partitions (a 3 minute panic_timeout taking 30
minutes).The problem is we loop on mdelay(1) and with a 1ms in 10ms hypervisor
timeslice each of these will take 10ms (ie 10x) longer. I expect other
platforms with shared processor hypervisors will see the same issue.This patch keeps the old behaviour if we have a panic_blink (only keyboard
LEDs right now) and does 1 second mdelays if we don't.Signed-off-by: Anton Blanchard
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 Jan, 2010
1 commit
-
crash_kexec gets called before kmsg_dump(KMSG_DUMP_OOPS) if
panic_on_oops is set, so the kernel log buffer is not stored
for this case.This patch adds a KMSG_DUMP_KEXEC dump type which gets called
when crash_kexec() is invoked. To avoid getting double dumps,
the old KMSG_DUMP_PANIC is moved below crash_kexec(). The
mtdoops driver is modified to handle KMSG_DUMP_KEXEC in the
same way as a panic.Signed-off-by: KOSAKI Motohiro
Acked-by: Simon Kagstrom
Signed-off-by: David Woodhouse
17 Dec, 2009
1 commit
-
* git://git.infradead.org/mtd-2.6: (90 commits)
jffs2: Fix long-standing bug with symlink garbage collection.
mtd: OneNAND: Fix test of unsigned in onenand_otp_walk()
mtd: cfi_cmdset_0002, fix lock imbalance
Revert "mtd: move mxcnd_remove to .exit.text"
mtd: m25p80: add support for Macronix MX25L4005A
kmsg_dump: fix build for CONFIG_PRINTK=n
mtd: nandsim: add support for 4KiB pages
mtd: mtdoops: refactor as a kmsg_dumper
mtd: mtdoops: make record size configurable
mtd: mtdoops: limit the maximum mtd partition size
mtd: mtdoops: keep track of used/unused pages in an array
mtd: mtdoops: several minor cleanups
core: Add kernel message dumper to call on oopses and panics
mtd: add ARM pismo support
mtd: pxa3xx_nand: Fix PIO data transfer
mtd: nand: fix multi-chip suspend problem
mtd: add support for switching old SST chips into QRY mode
mtd: fix M29W800D dev_id and uaddr
mtd: don't use PF_MEMALLOC
mtd: Add bad block table overrides to Davinci NAND driver
...Fixed up conflicts (mostly trivial) in
drivers/mtd/devices/m25p80.c
drivers/mtd/maps/pcmciamtd.c
drivers/mtd/nand/pxa3xx_nand.c
kernel/printk.c
30 Nov, 2009
1 commit
-
The core functionality is implemented as per Linus suggestion from
http://lists.infradead.org/pipermail/linux-mtd/2009-October/027620.html
(with the kmsg_dump implementation by Linus). A struct kmsg_dumper has
been added which contains a callback to dump the kernel log buffers on
crashes. The kmsg_dump function gets called from oops_exit() and panic()
and invokes this callbacks with the crash reason.[dwmw2: Fix log_end handling]
Signed-off-by: Simon Kagstrom
Reviewed-by: Anders Grafstrom
Reviewed-by: Linus Torvalds
Acked-by: Ingo Molnar
Signed-off-by: Artem Bityutskiy
Signed-off-by: David Woodhouse
09 Oct, 2009
1 commit
-
…/git/tip/linux-2.6-tip
* 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
futex: fix requeue_pi key imbalance
futex: Fix typo in FUTEX_WAIT/WAKE_BITSET_PRIVATE definitions
rcu: Place root rcu_node structure in separate lockdep class
rcu: Make hot-unplugged CPU relinquish its own RCU callbacks
rcu: Move rcu_barrier() to rcutree
futex: Move exit_pi_state() call to release_mm()
futex: Nullify robust lists after cleanup
futex: Fix locking imbalance
panic: Fix panic message visibility by calling bust_spinlocks(0) before dying
rcu: Replace the rcu_barrier enum with pointer to call_rcu*() function
rcu: Clean up code based on review feedback from Josh Triplett, part 4
rcu: Clean up code based on review feedback from Josh Triplett, part 3
rcu: Fix rcu_lock_map build failure on CONFIG_PROVE_LOCKING=y
rcu: Clean up code to address Ingo's checkpatch feedback
rcu: Clean up code based on review feedback from Josh Triplett, part 2
rcu: Clean up code based on review feedback from Josh Triplett
06 Oct, 2009
1 commit
-
Commit ffd71da4e3f ("panic: decrease oops_in_progress only after
having done the panic") moved bust_spinlocks(0) to the end of the
function, which in practice is never reached.As a result console_unblank() is not called, and on some systems
the user may not see the panic message.Move it back up to before the unblanking.
Signed-off-by: Aaro Koskinen
Reviewed-by: Frederic Weisbecker
LKML-Reference:
Signed-off-by: Ingo Molnar
21 Sep, 2009
1 commit
-
Signed-off-by: Robert P. J. Day
Signed-off-by: Jiri Kosina
25 Jul, 2009
1 commit
-
If trace_printk_on_oops is set we lose interesting trace information
when the tracer is enabled across oops handling and printing. We want
the trace which might give us information _WHY_ we oopsed.Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
17 May, 2009
1 commit
-
Ian Campbell noticed that since "Eliminate thousands of warnings with
gcc 3.2 build" (commit 57adc4d2dbf968fdbe516359688094eef4d46581) all
WARN_ON()'s currently appear to come from warn_slowpath_null(), eg:WARNING: at kernel/softirq.c:143 warn_slowpath_null+0x1c/0x20()
because now that warn_slowpath_null() is in the call path, the
__builtin_return_address(0) returns that, rather than the place that
caused the warning.Fix this by splitting up the warn_slowpath_null/fmt cases differently,
using a common helper function, and getting the return address in the
right place. This also happens to avoid the unnecessary stack usage for
the non-stdargs case, and just generally cleans things up.Make the function name printout use %pS while at it.
Cc: Ian Campbell
Cc: Jesper Nilsson
Cc: Johannes Weiner
Cc: Arjan van de Ven
Cc: Andi Kleen
Cc: Hugh Dickins
Cc: Andrew Morton
Signed-off-by: Linus Torvalds
07 May, 2009
1 commit
-
When building with gcc 3.2 I get thousands of warnings such as
include/linux/gfp.h: In function `allocflags_to_migratetype':
include/linux/gfp.h:105: warning: null format stringdue to passing a NULL format string to warn_slowpath() in
#define __WARN() warn_slowpath(__FILE__, __LINE__, NULL)
Split this case out into a separate call. This also shrinks the kernel
slightly:text data bss dec hex filename
4802274 707668 712704 6222646 5ef336 vmlinux
text data bss dec hex filename
4799027 703572 712704 6215303 5ed687 vmlinuxdue to removeing one argument from the commonly-called __WARN().
[akpm@linux-foundation.org: reduce scope of `empty']
Acked-by: Jesper Nilsson
Acked-by: Johannes Weiner
Acked-by: Arjan van de Ven
Signed-off-by: Andi Kleen
Cc: Hugh Dickins
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
23 Apr, 2009
1 commit
-
Andi Kleen reported this message triggering on non-lockdep kernels:
Disabling lockdep due to kernel taint
Clarify the message to say 'lock debugging' - debug_locks_off()
turns off all things lock debugging, not just lockdep.[ Impact: change kernel warning message text ]
Reported-by: Andi Kleen
Cc: Peter Zijlstra
Cc: Andrew Morton
Signed-off-by: Ingo Molnar
12 Apr, 2009
2 commits
-
Impact: broaden lockdep checks
Lockdep is disabled after any kernel taints. This might be convenient
to ignore bad locking issues which sources come from outside the kernel
tree. Nevertheless, it might be a frustrating experience for the
staging developers or those who experience a warning but are focused
on another things that require lockdep.The v2 of this patch simply don't disable anymore lockdep in case
of TAINT_CRAP and TAINT_WARN events.Signed-off-by: Frederic Weisbecker
Cc: LTP
Cc: Peter Zijlstra
Cc: Greg KH
LKML-Reference:
Signed-off-by: Ingo Molnar -
Impact: provide useful missing info for developers
Kernel taint can occur in several situations such as warnings,
load of prorietary or staging modules, bad page, etc...But when such taint happens, a developer might still be working on
the kernel, expecting that lockdep is still enabled. But a taint
disables lockdep without ever warning about it.
Such a kernel behaviour doesn't really help for kernel development.This patch adds this missing warning.
Since the taint is done most of the time after the main message that
explain the real source issue, it seems safe to warn about it inside
add_taint() so that it appears at last, without hurting the main
information.v2: Use a generic helper to disable lockdep instead of an
open coded xchg().Signed-off-by: Frederic Weisbecker
Cc: Peter Zijlstra
LKML-Reference:
Signed-off-by: Ingo Molnar
13 Mar, 2009
3 commits
-
Impact: cleanup, no code changed
Clean up kernel/panic.c some more and make it more consistent.
LKML-Reference:
Signed-off-by: Ingo Molnar -
Impact: cleanup, no code changed
Remove an ugly #ifdef CONFIG_SMP from panic(), by providing
an smp_send_stop() wrapper on UP too.LKML-Reference:
Signed-off-by: Ingo Molnar -
Impact: eliminate secondary warnings during panic()
We can panic() in a number of difficult, atomic contexts, hence
we use bust_spinlocks(1) in panic() to increase oops_in_progress,
which prevents various debug checks we have in place.But in practice this protection only covers the first few printk's
done by panic() - it does not cover the later attempt to stop all
other CPUs and kexec(). If a secondary warning triggers in one of
those facilities that can make the panic message scroll off.So do bust_spinlocks(0) only much later in panic(). (which code
is only reached if panic policy is relaxed that it can return
after a warning message)Reported-by: Jan Beulich
LKML-Reference:
Signed-off-by: Ingo Molnar
10 Feb, 2009
1 commit
-
Impact: no default -fno-stack-protector if stackp is enabled, cleanup
Stackprotector make rules had the following problems.
* cc support test and warning are scattered across makefile and
kernel/panic.c.* -fno-stack-protector was always added regardless of configuration.
Update such that cc support test and warning are contained in makefile
and -fno-stack-protector is added iff stackp is turned off. While at
it, prepare for 32bit support.Signed-off-by: Tejun Heo
Signed-off-by: Ingo Molnar
19 Jan, 2009
1 commit
-
Conflicts:
arch/x86/include/asm/pda.h
arch/x86/include/asm/system.hAlso, moved include/asm-x86/stackprotector.h to arch/x86/include/asm.
Signed-off-by: Ingo Molnar
07 Jan, 2009
1 commit
-
... because we do want repeated same-oops to be seen by automated
tools like kerneloops.orgSigned-off-by: Arjan van de Ven
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
31 Dec, 2008
1 commit
-
Conflicts:
arch/x86/include/asm/pda.h
kernel/fork.c
25 Dec, 2008
1 commit
02 Dec, 2008
1 commit
-
The description for 'D' was missing in the comment... (causing me a
minute of WTF followed by looking at more of the code)Signed-off-by: Arjan van de Ven
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
29 Nov, 2008
3 commits
-
Impact: cleanup, eliminate code
now that warn_on_slowpath() uses warn_slowpath(...,NULL), we can
eliminate warn_on_slowpath() altogether and use warn_slowpath().Signed-off-by: Ingo Molnar
-
Impact: extend WARN_ON() output with DMI_PRODUCT_NAME
It's very useful for many low level WARN_ON's to find out which
motherboard has the broken BIOS etc... this patch adds a printk
to the WARN_ON code for this.On architectures without DMI, gcc should optimize the code out.
Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar -
Impact: cleanup, code reduction
warn_slowpath is a superset of warn_on_slowpath; just have
warn_on_slowpath call warn_slowpath with a NULL 3rd argument.Signed-off-by: Arjan van de Ven
Signed-off-by: Ingo Molnar
22 Oct, 2008
1 commit
-
This allows them to be examined and set after boot, plus means they
actually give errors if they are misused (eg. panic=yes).Signed-off-by: Rusty Russell
18 Oct, 2008
1 commit
-
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6: (25 commits)
staging: at76_usb wireless driver
Staging: workaround build system bug
Staging: Lindent sxg.c
Staging: SLICOSS: Call pci_release_regions at driver exit
Staging: SLICOSS: Fix remaining type names
Staging: SLICOSS: Fix warnings due to static usage
Staging: SLICOSS: lots of checkpatch fixes
Staging: go7007 v4l fixes
Staging: Fix gcc warnings in sxg
Staging: add echo cancelation module
Staging: add wlan-ng prism2 usb driver
Staging: add w35und wifi driver
Staging: USB/IP: add host driver
Staging: USB/IP: add client driver
Staging: USB/IP: add common functions needed
Staging: add the go7007 video driver
Staging: add me4000 pci data collection driver
Staging: add me4000 firmware files
Staging: add sxg network driver
Staging: add Alacritech slicoss network driver
...Fixed up conflicts due to taint flags changes and MAINTAINERS cleanup in
MAINTAINERS, include/linux/kernel.h and kernel/panic.c.
17 Oct, 2008
2 commits
-
Move print_tainted() kernel-doc to avoid the following error:
Error(/var/linsrc/mmotm-2008-1002-1617//kernel/panic.c:155): cannot understand prototype: 'struct tnt '
Signed-off-by: Randy Dunlap
Cc: Andi Kleen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
It's somewhat unlikely that it happens, but right now a race window
between interrupts or machine checks or oopses could corrupt the tainted
bitmap because it is modified in a non atomic fashion.Convert the taint variable to an unsigned long and use only atomic bit
operations on it.Unfortunately this means the intvec sysctl functions cannot be used on it
anymore.It turned out the taint sysctl handler could actually be simplified a bit
(since it only increases capabilities) so this patch actually removes
code.[akpm@linux-foundation.org: remove unneeded include]
Signed-off-by: Andi Kleen
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 Oct, 2008
1 commit
-
Conflicts:
arch/x86/kernel/Makefile
include/asm-x86/pda.h
11 Oct, 2008
1 commit
-
We need to add a flag for all code that is in the drivers/staging/
directory to prevent all other kernel developers from worrying about
issues here, and to notify users that the drivers might not be as good
as they are normally used to.Based on code from Andreas Gruenbacher and Jeff Mahoney to provide a
TAINT flag for the support level of a kernel module in the Novell
enterprise kernel release.This is the kernel portion of this feature, the ability for the flag to
be set needs to be done in the build process and will happen in a
follow-up patch.Cc: Andreas Gruenbacher
Cc: Jeff Mahoney
Signed-off-by: Greg Kroah-Hartman
