help
The section mismatch analysis checks if there are illegal
references from one section to another section.
- Linux will during link or during runtime drop some sections
- and any use of code/data previously in these sections will
+ During linktime or runtime, some sections are dropped;
+ any use of code/data previously in these sections would
most likely result in an oops.
- In the code functions and variables are annotated with
- __init, __devinit etc. (see full list in include/linux/init.h)
+ In the code, functions and variables are annotated with
+ __init, __devinit, etc. (see the full list in include/linux/init.h),
which results in the code/data being placed in specific sections.
- The section mismatch analysis is always done after a full
- kernel build but enabling this option will in addition
- do the following:
- - Add the option -fno-inline-functions-called-once to gcc
- When inlining a function annotated __init in a non-init
- function we would lose the section information and thus
+ The section mismatch analysis is always performed after a full
+ kernel build, and enabling this option causes the following
+ additional steps to occur:
+ - Add the option -fno-inline-functions-called-once to gcc commands.
+ When inlining a function annotated with __init in a non-init
+ function, we would lose the section information and thus
the analysis would not catch the illegal reference.
- This option tells gcc to inline less but will also
- result in a larger kernel.
- - Run the section mismatch analysis for each module/built-in.o
- When we run the section mismatch analysis on vmlinux.o we
+ This option tells gcc to inline less (but it does result in
+ a larger kernel).
+ - Run the section mismatch analysis for each module/built-in.o file.
+ When we run the section mismatch analysis on vmlinux.o, we
lose valueble information about where the mismatch was
introduced.
Running the analysis for each module/built-in.o file
- will tell where the mismatch happens much closer to the
- source. The drawback is that we will report the same
- mismatch at least twice.
- - Enable verbose reporting from modpost to help solving
- the section mismatches reported.
+ tells where the mismatch happens much closer to the
+ source. The drawback is that the same mismatch is
+ reported at least twice.
+ - Enable verbose reporting from modpost in order to help resolve
+ the section mismatches that are reported.
config DEBUG_KERNEL
bool "Kernel debugging"
config DETECT_HUNG_TASK
bool "Detect Hung Tasks"
depends on DEBUG_KERNEL
- default DETECT_SOFTLOCKUP
+ default LOCKUP_DETECTOR
help
Say Y here to enable the kernel to detect "hung tasks",
which are bugs that cause the task to be stuck in
to determine when a task has become non-responsive and should
be considered hung.
- It can be adjusted at runtime via the kernel.hung_task_timeout
- sysctl or by writing a value to /proc/sys/kernel/hung_task_timeout.
+ It can be adjusted at runtime via the kernel.hung_task_timeout_secs
+ sysctl or by writing a value to
+ /proc/sys/kernel/hung_task_timeout_secs.
A timeout of 0 disables the check. The default is two minutes.
Keeping the default should be fine in most cases.
Enables hooks to interrupt enabling and disabling for
either tracing or lock debugging.
-config DEBUG_SPINLOCK_SLEEP
- bool "Spinlock debugging: sleep-inside-spinlock checking"
+config DEBUG_ATOMIC_SLEEP
+ bool "Sleep inside atomic section checking"
+ select PREEMPT_COUNT
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.
+ noisy if they are called inside atomic sections: when a spinlock is
+ held, inside an rcu read side critical section, inside preempt disabled
+ sections, inside an interrupt, etc...
config DEBUG_LOCKING_API_SELFTESTS
bool "Locking API boot-time self-tests"
bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
depends on BUG
depends on ARM || AVR32 || M32R || M68K || SPARC32 || SPARC64 || \
- FRV || SUPERH || GENERIC_BUG || BLACKFIN || MN10300
+ FRV || SUPERH || GENERIC_BUG || BLACKFIN || MN10300 || TILE
default y
help
Say Y here to make BUG() panics output the file name and line number
#
# Select this config option from the architecture Kconfig, if it
-# it is preferred to always offer frame pointers as a config
+# is preferred to always offer frame pointers as a config
# option on the architecture (regardless of KERNEL_DEBUG):
#
config ARCH_WANT_FRAME_POINTERS
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_PRINTK_DELAY also may cause DETECT_SOFTLOCKUP to detect
+ BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect
what it believes to be lockup conditions.
config RCU_TORTURE_TEST
Only works with drivers that use the generic timeout handling,
for others it wont do anything.
+config FAIL_MMC_REQUEST
+ bool "Fault-injection capability for MMC IO"
+ select DEBUG_FS
+ depends on FAULT_INJECTION && MMC
+ help
+ Provide fault-injection capability for MMC IO.
+ This will make the mmc core return data errors. This is
+ useful to test the error handling in the mmc block device
+ and to test how the mmc host driver handles retries from
+ the block device.
+
config FAULT_INJECTION_DEBUG_FS
bool "Debugfs entries for fault-injection capabilities"
depends on FAULT_INJECTION && SYSFS && DEBUG_FS
depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
depends on !X86_64
select STACKTRACE
- select FRAME_POINTER if !PPC && !S390 && !MICROBLAZE
+ select FRAME_POINTER if !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND
help
Provide stacktrace filter for fault-injection capabilities
depends on DEBUG_KERNEL
depends on STACKTRACE_SUPPORT
depends on PROC_FS
- select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE
+ select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND
select KALLSYMS
select KALLSYMS_ALL
select STACKTRACE
projects / linux-flexiantxendom0.git / blobdiff