keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
unless you really know what this hack does.
-config UNUSED_SYMBOLS
- bool "Enable unused/obsolete exported symbols"
- default y if X86
- help
- Unused but exported symbols make the kernel needlessly bigger. For
- that reason most of these unused exports will soon be removed. This
- option is provided temporarily to provide a transition period in case
- some external kernel module needs one of these symbols anyway. If you
- encounter such a case in your module, consider if you are actually
- using the right API. (rationale: since nobody in the kernel is using
- this in a module, there is a pretty good chance it's actually the
- wrong interface to use). If you really need the symbol, please send a
- mail to the linux kernel mailing list mentioning the symbol and why
- you really need it, and what the merge plan to the mainline kernel for
- your module is.
-
config DEBUG_KERNEL
bool "Kernel debugging"
help
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" if DEBUG_KERNEL
range 12 21
- default 17 if S390 || LOCKDEP
+ default 17 if S390
default 16 if X86_NUMAQ || IA64
default 15 if SMP
default 14
this adds.
config DEBUG_SLAB
- bool "Debug slab memory allocations"
+ bool "Debug memory allocations"
depends on DEBUG_KERNEL && SLAB
help
Say Y here to have the kernel do limited verification on memory
allocation as well as poisoning memory on free to catch use of freed
memory. This can make kmalloc/kfree-intensive workloads much slower.
-config DEBUG_SLAB_LEAK
- bool "Memory leak debugging"
- depends on DEBUG_SLAB
-
config DEBUG_PREEMPT
bool "Debug preemptible kernel"
- depends on DEBUG_KERNEL && PREEMPT && TRACE_IRQFLAGS_SUPPORT
+ depends on DEBUG_KERNEL && PREEMPT
default y
help
If you say Y here then the kernel will use a debug variant of the
if kernel code uses it in a preemption-unsafe way. Also, the kernel
will detect preemption count underflows.
-config DEBUG_RT_MUTEXES
- bool "RT Mutex debugging, deadlock detection"
- depends on DEBUG_KERNEL && RT_MUTEXES
- help
- This allows rt mutex semantics violations and rt mutex related
- deadlocks (lockups) to be detected and reported automatically.
-
-config DEBUG_PI_LIST
- bool
+config DEBUG_MUTEXES
+ bool "Mutex debugging, deadlock detection"
default y
- depends on DEBUG_RT_MUTEXES
-
-config RT_MUTEX_TESTER
- bool "Built-in scriptable tester for rt-mutexes"
- depends on DEBUG_KERNEL && RT_MUTEXES
+ depends on DEBUG_KERNEL
help
- This option enables a rt-mutex tester.
+ This allows mutex semantics violations and mutex related deadlocks
+ (lockups) to be detected and reported automatically.
config DEBUG_SPINLOCK
- bool "Spinlock and rw-lock debugging: basic checks"
+ bool "Spinlock debugging"
depends on DEBUG_KERNEL
help
Say Y here and build SMP to catch missing spinlock initialization
best used in conjunction with the NMI watchdog so that spinlock
deadlocks are also debuggable.
-config DEBUG_MUTEXES
- bool "Mutex debugging: basic checks"
- depends on DEBUG_KERNEL
- help
- This feature allows mutex semantics violations to be detected and
- reported.
-
-config DEBUG_RWSEMS
- bool "RW-sem debugging: basic checks"
- depends on DEBUG_KERNEL
- help
- This feature allows read-write semaphore semantics violations to
- be detected and reported.
-
-config DEBUG_LOCK_ALLOC
- bool "Lock debugging: detect incorrect freeing of live locks"
- depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
- select DEBUG_SPINLOCK
- select DEBUG_MUTEXES
- select DEBUG_RWSEMS
- select LOCKDEP
- help
- This feature will check whether any held lock (spinlock, rwlock,
- mutex or rwsem) is incorrectly freed by the kernel, via any of the
- memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
- vfree(), etc.), whether a live lock is incorrectly reinitialized via
- spin_lock_init()/mutex_init()/etc., or whether there is any lock
- held during task exit.
-
-config PROVE_LOCKING
- bool "Lock debugging: prove locking correctness"
- depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
- select LOCKDEP
- select DEBUG_SPINLOCK
- select DEBUG_MUTEXES
- select DEBUG_RWSEMS
- select DEBUG_LOCK_ALLOC
- default n
- help
- This feature enables the kernel to prove that all locking
- that occurs in the kernel runtime is mathematically
- correct: that under no circumstance could an arbitrary (and
- not yet triggered) combination of observed locking
- sequences (on an arbitrary number of CPUs, running an
- arbitrary number of tasks and interrupt contexts) cause a
- deadlock.
-
- In short, this feature enables the kernel to report locking
- related deadlocks before they actually occur.
-
- The proof does not depend on how hard and complex a
- deadlock scenario would be to trigger: how many
- participant CPUs, tasks and irq-contexts would be needed
- for it to trigger. The proof also does not depend on
- timing: if a race and a resulting deadlock is possible
- theoretically (no matter how unlikely the race scenario
- is), it will be proven so and will immediately be
- reported by the kernel (once the event is observed that
- makes the deadlock theoretically possible).
-
- If a deadlock is impossible (i.e. the locking rules, as
- observed by the kernel, are mathematically correct), the
- kernel reports nothing.
-
- NOTE: this feature can also be enabled for rwlocks, mutexes
- and rwsems - in which case all dependencies between these
- different locking variants are observed and mapped too, and
- the proof of observed correctness is also maintained for an
- arbitrary combination of these separate locking variants.
-
- For more details, see Documentation/lockdep-design.txt.
-
-config LOCKDEP
- bool
- depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
- select STACKTRACE
- select FRAME_POINTER if !X86
- select KALLSYMS
- select KALLSYMS_ALL
-
-config DEBUG_LOCKDEP
- bool "Lock dependency engine debugging"
- depends on DEBUG_KERNEL && LOCKDEP
- help
- If you say Y here, the lock dependency engine will do
- additional runtime checks to debug itself, at the price
- of more runtime overhead.
-
-config TRACE_IRQFLAGS
- depends on DEBUG_KERNEL
- bool
- default y
- depends on TRACE_IRQFLAGS_SUPPORT
- depends on PROVE_LOCKING
-
config DEBUG_SPINLOCK_SLEEP
- bool "Spinlock debugging: sleep-inside-spinlock checking"
+ bool "Sleep-inside-spinlock checking"
depends on DEBUG_KERNEL
help
If you say Y here, various routines which may sleep will become very
noisy if they are called with a spinlock held.
-config DEBUG_LOCKING_API_SELFTESTS
- bool "Locking API boot-time self-tests"
- depends on DEBUG_KERNEL
- help
- Say Y here if you want the kernel to run a short self-test during
- bootup. The self-test checks whether common types of locking bugs
- are detected by debugging mechanisms or not. (if you disable
- lock debugging then those bugs wont be detected of course.)
- The following locking APIs are covered: spinlocks, rwlocks,
- mutexes and rwsems.
-
-config STACKTRACE
- bool
- depends on DEBUG_KERNEL
- depends on STACKTRACE_SUPPORT
-
config DEBUG_KOBJECT
bool "kobject debugging"
depends on DEBUG_KERNEL
If unsure, say N.
+config DEBUG_IOREMAP
+ bool "Enable ioremap() debugging"
+ depends on DEBUG_KERNEL && PARISC
+ help
+ Enabling this option will cause the kernel to distinguish between
+ ioremapped and physical addresses. It will print a backtrace (at
+ most one every 10 seconds), hopefully allowing you to see which
+ drivers need work. Fixing all these problems is a prerequisite
+ for turning on USE_HPPA_IOREMAP. The warnings are harmless;
+ the kernel has enough information to fix the broken drivers
+ automatically, but we'd like to make it more efficient by not
+ having to do that.
+
config DEBUG_FS
bool "Debug Filesystem"
- depends on SYSFS
+ depends on DEBUG_KERNEL && SYSFS
help
debugfs is a virtual file system that kernel developers use to put
debugging files into. Enable this option to be able to read and
If unsure, say N.
-config DEBUG_LIST
- bool "Debug linked list manipulation"
- depends on DEBUG_KERNEL
- help
- Enable this to turn on extended checks in the linked-list
- walking routines.
-
- If unsure, say N.
-
config FRAME_POINTER
bool "Compile the kernel with frame pointers"
- depends on DEBUG_KERNEL && (X86 || CRIS || M68K || M68KNOMMU || FRV || UML || S390)
+ depends on DEBUG_KERNEL && (X86 || CRIS || M68K || M68KNOMMU || FRV || UML)
default y if DEBUG_INFO && UML
help
If you say Y here the resulting kernel image will be slightly larger
some architectures or if you use external debuggers.
If you don't debug the kernel, you can say N.
-config UNWIND_INFO
- bool "Compile the kernel with frame unwind information"
- depends on !IA64 && !PARISC && !X86_64_XEN
- depends on !MODULES || !(MIPS || PPC || SUPERH || V850)
- help
- If you say Y here the resulting kernel image will be slightly larger
- but not slower, and it will give very useful debugging information.
- If you don't debug the kernel, you can say N, but we may not be able
- to solve problems without frame unwind information or frame pointers.
-
-config STACK_UNWIND
- bool "Stack unwind support"
- depends on UNWIND_INFO
- depends on X86
- help
- This enables more precise stack traces, omitting all unrelated
- occurrences of pointers into kernel code from the dump.
-
config FORCED_INLINING
bool "Force gcc to inline functions marked 'inline'"
depends on DEBUG_KERNEL
become the default in the future, until then this option is there to
test gcc for this.
-config BOOT_DELAY
- bool "Delay each boot message by N milliseconds"
- depends on DEBUG_KERNEL
- help
- This build option allows you to read kernel boot messages
- by inserting a short delay after each one. The delay is
- specified in milliseconds on the kernel command line,
- using "boot_delay=N".
-
- It is likely that you would also need to use "lpj=M" to preset
- the "loops per jiffie" value.
- See a previous boot log for the "lpj" value to use for your
- system, and then set "lpj=M" before setting "boot_delay=N".
- NOTE: Using this option may adversely affect SMP systems.
- I.e., processors other than the first one may not boot up.
- BOOT_DELAY also may cause DETECT_SOFTLOCKUP to detect
- what it believes to be lockup conditions.
-
config RCU_TORTURE_TEST
tristate "torture tests for RCU"
depends on DEBUG_KERNEL
git://git.onelab.eu / linux-2.6.git / blobdiff