linux/lib/Kconfig.debug
<<
>>
Prefs
   1menu "printk and dmesg options"
   2
   3config PRINTK_TIME
   4        bool "Show timing information on printks"
   5        depends on PRINTK
   6        help
   7          Selecting this option causes time stamps of the printk()
   8          messages to be added to the output of the syslog() system
   9          call and at the console.
  10
  11          The timestamp is always recorded internally, and exported
  12          to /dev/kmsg. This flag just specifies if the timestamp should
  13          be included, not that the timestamp is recorded.
  14
  15          The behavior is also controlled by the kernel command line
  16          parameter printk.time=1. See Documentation/kernel-parameters.txt
  17
  18config DEFAULT_MESSAGE_LOGLEVEL
  19        int "Default message log level (1-7)"
  20        range 1 7
  21        default "4"
  22        help
  23          Default log level for printk statements with no specified priority.
  24
  25          This was hard-coded to KERN_WARNING since at least 2.6.10 but folks
  26          that are auditing their logs closely may want to set it to a lower
  27          priority.
  28
  29config BOOT_PRINTK_DELAY
  30        bool "Delay each boot printk message by N milliseconds"
  31        depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY
  32        help
  33          This build option allows you to read kernel boot messages
  34          by inserting a short delay after each one.  The delay is
  35          specified in milliseconds on the kernel command line,
  36          using "boot_delay=N".
  37
  38          It is likely that you would also need to use "lpj=M" to preset
  39          the "loops per jiffie" value.
  40          See a previous boot log for the "lpj" value to use for your
  41          system, and then set "lpj=M" before setting "boot_delay=N".
  42          NOTE:  Using this option may adversely affect SMP systems.
  43          I.e., processors other than the first one may not boot up.
  44          BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect
  45          what it believes to be lockup conditions.
  46
  47config DYNAMIC_DEBUG
  48        bool "Enable dynamic printk() support"
  49        default n
  50        depends on PRINTK
  51        depends on DEBUG_FS
  52        help
  53
  54          Compiles debug level messages into the kernel, which would not
  55          otherwise be available at runtime. These messages can then be
  56          enabled/disabled based on various levels of scope - per source file,
  57          function, module, format string, and line number. This mechanism
  58          implicitly compiles in all pr_debug() and dev_dbg() calls, which
  59          enlarges the kernel text size by about 2%.
  60
  61          If a source file is compiled with DEBUG flag set, any
  62          pr_debug() calls in it are enabled by default, but can be
  63          disabled at runtime as below.  Note that DEBUG flag is
  64          turned on by many CONFIG_*DEBUG* options.
  65
  66          Usage:
  67
  68          Dynamic debugging is controlled via the 'dynamic_debug/control' file,
  69          which is contained in the 'debugfs' filesystem. Thus, the debugfs
  70          filesystem must first be mounted before making use of this feature.
  71          We refer the control file as: <debugfs>/dynamic_debug/control. This
  72          file contains a list of the debug statements that can be enabled. The
  73          format for each line of the file is:
  74
  75                filename:lineno [module]function flags format
  76
  77          filename : source file of the debug statement
  78          lineno : line number of the debug statement
  79          module : module that contains the debug statement
  80          function : function that contains the debug statement
  81          flags : '=p' means the line is turned 'on' for printing
  82          format : the format used for the debug statement
  83
  84          From a live system:
  85
  86                nullarbor:~ # cat <debugfs>/dynamic_debug/control
  87                # filename:lineno [module]function flags format
  88                fs/aio.c:222 [aio]__put_ioctx =_ "__put_ioctx:\040freeing\040%p\012"
  89                fs/aio.c:248 [aio]ioctx_alloc =_ "ENOMEM:\040nr_events\040too\040high\012"
  90                fs/aio.c:1770 [aio]sys_io_cancel =_ "calling\040cancel\012"
  91
  92          Example usage:
  93
  94                // enable the message at line 1603 of file svcsock.c
  95                nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
  96                                                <debugfs>/dynamic_debug/control
  97
  98                // enable all the messages in file svcsock.c
  99                nullarbor:~ # echo -n 'file svcsock.c +p' >
 100                                                <debugfs>/dynamic_debug/control
 101
 102                // enable all the messages in the NFS server module
 103                nullarbor:~ # echo -n 'module nfsd +p' >
 104                                                <debugfs>/dynamic_debug/control
 105
 106                // enable all 12 messages in the function svc_process()
 107                nullarbor:~ # echo -n 'func svc_process +p' >
 108                                                <debugfs>/dynamic_debug/control
 109
 110                // disable all 12 messages in the function svc_process()
 111                nullarbor:~ # echo -n 'func svc_process -p' >
 112                                                <debugfs>/dynamic_debug/control
 113
 114          See Documentation/dynamic-debug-howto.txt for additional information.
 115
 116endmenu # "printk and dmesg options"
 117
 118menu "Compile-time checks and compiler options"
 119
 120config DEBUG_INFO
 121        bool "Compile the kernel with debug info"
 122        depends on DEBUG_KERNEL
 123        help
 124          If you say Y here the resulting kernel image will include
 125          debugging info resulting in a larger kernel image.
 126          This adds debug symbols to the kernel and modules (gcc -g), and
 127          is needed if you intend to use kernel crashdump or binary object
 128          tools like crash, kgdb, LKCD, gdb, etc on the kernel.
 129          Say Y here only if you plan to debug the kernel.
 130
 131          If unsure, say N.
 132
 133config DEBUG_INFO_REDUCED
 134        bool "Reduce debugging information"
 135        depends on DEBUG_INFO
 136        help
 137          If you say Y here gcc is instructed to generate less debugging
 138          information for structure types. This means that tools that
 139          need full debugging information (like kgdb or systemtap) won't
 140          be happy. But if you merely need debugging information to
 141          resolve line numbers there is no loss. Advantage is that
 142          build directory object sizes shrink dramatically over a full
 143          DEBUG_INFO build and compile times are reduced too.
 144          Only works with newer gcc versions.
 145
 146config ENABLE_WARN_DEPRECATED
 147        bool "Enable __deprecated logic"
 148        default y
 149        help
 150          Enable the __deprecated logic in the kernel build.
 151          Disable this to suppress the "warning: 'foo' is deprecated
 152          (declared at kernel/power/somefile.c:1234)" messages.
 153
 154config ENABLE_MUST_CHECK
 155        bool "Enable __must_check logic"
 156        default y
 157        help
 158          Enable the __must_check logic in the kernel build.  Disable this to
 159          suppress the "warning: ignoring return value of 'foo', declared with
 160          attribute warn_unused_result" messages.
 161
 162config FRAME_WARN
 163        int "Warn for stack frames larger than (needs gcc 4.4)"
 164        range 0 8192
 165        default 1024 if !64BIT
 166        default 2048 if 64BIT
 167        help
 168          Tell gcc to warn at build time for stack frames larger than this.
 169          Setting this too low will cause a lot of warnings.
 170          Setting it to 0 disables the warning.
 171          Requires gcc 4.4
 172
 173config STRIP_ASM_SYMS
 174        bool "Strip assembler-generated symbols during link"
 175        default n
 176        help
 177          Strip internal assembler-generated symbols during a link (symbols
 178          that look like '.Lxxx') so they don't pollute the output of
 179          get_wchan() and suchlike.
 180
 181config READABLE_ASM
 182        bool "Generate readable assembler code"
 183        depends on DEBUG_KERNEL
 184        help
 185          Disable some compiler optimizations that tend to generate human unreadable
 186          assembler output. This may make the kernel slightly slower, but it helps
 187          to keep kernel developers who have to stare a lot at assembler listings
 188          sane.
 189
 190config UNUSED_SYMBOLS
 191        bool "Enable unused/obsolete exported symbols"
 192        default y if X86
 193        help
 194          Unused but exported symbols make the kernel needlessly bigger.  For
 195          that reason most of these unused exports will soon be removed.  This
 196          option is provided temporarily to provide a transition period in case
 197          some external kernel module needs one of these symbols anyway. If you
 198          encounter such a case in your module, consider if you are actually
 199          using the right API.  (rationale: since nobody in the kernel is using
 200          this in a module, there is a pretty good chance it's actually the
 201          wrong interface to use).  If you really need the symbol, please send a
 202          mail to the linux kernel mailing list mentioning the symbol and why
 203          you really need it, and what the merge plan to the mainline kernel for
 204          your module is.
 205
 206config DEBUG_FS
 207        bool "Debug Filesystem"
 208        help
 209          debugfs is a virtual file system that kernel developers use to put
 210          debugging files into.  Enable this option to be able to read and
 211          write to these files.
 212
 213          For detailed documentation on the debugfs API, see
 214          Documentation/DocBook/filesystems.
 215
 216          If unsure, say N.
 217
 218config HEADERS_CHECK
 219        bool "Run 'make headers_check' when building vmlinux"
 220        depends on !UML
 221        help
 222          This option will extract the user-visible kernel headers whenever
 223          building the kernel, and will run basic sanity checks on them to
 224          ensure that exported files do not attempt to include files which
 225          were not exported, etc.
 226
 227          If you're making modifications to header files which are
 228          relevant for userspace, say 'Y', and check the headers
 229          exported to $(INSTALL_HDR_PATH) (usually 'usr/include' in
 230          your build tree), to make sure they're suitable.
 231
 232config DEBUG_SECTION_MISMATCH
 233        bool "Enable full Section mismatch analysis"
 234        help
 235          The section mismatch analysis checks if there are illegal
 236          references from one section to another section.
 237          During linktime or runtime, some sections are dropped;
 238          any use of code/data previously in these sections would
 239          most likely result in an oops.
 240          In the code, functions and variables are annotated with
 241          __init,, etc. (see the full list in include/linux/init.h),
 242          which results in the code/data being placed in specific sections.
 243          The section mismatch analysis is always performed after a full
 244          kernel build, and enabling this option causes the following
 245          additional steps to occur:
 246          - Add the option -fno-inline-functions-called-once to gcc commands.
 247            When inlining a function annotated with __init in a non-init
 248            function, we would lose the section information and thus
 249            the analysis would not catch the illegal reference.
 250            This option tells gcc to inline less (but it does result in
 251            a larger kernel).
 252          - Run the section mismatch analysis for each module/built-in.o file.
 253            When we run the section mismatch analysis on vmlinux.o, we
 254            lose valueble information about where the mismatch was
 255            introduced.
 256            Running the analysis for each module/built-in.o file
 257            tells where the mismatch happens much closer to the
 258            source. The drawback is that the same mismatch is
 259            reported at least twice.
 260          - Enable verbose reporting from modpost in order to help resolve
 261            the section mismatches that are reported.
 262
 263#
 264# Select this config option from the architecture Kconfig, if it
 265# is preferred to always offer frame pointers as a config
 266# option on the architecture (regardless of KERNEL_DEBUG):
 267#
 268config ARCH_WANT_FRAME_POINTERS
 269        bool
 270        help
 271
 272config FRAME_POINTER
 273        bool "Compile the kernel with frame pointers"
 274        depends on DEBUG_KERNEL && \
 275                (CRIS || M68K || FRV || UML || \
 276                 AVR32 || SUPERH || BLACKFIN || MN10300 || METAG) || \
 277                ARCH_WANT_FRAME_POINTERS
 278        default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
 279        help
 280          If you say Y here the resulting kernel image will be slightly
 281          larger and slower, but it gives very useful debugging information
 282          in case of kernel bugs. (precise oopses/stacktraces/warnings)
 283
 284config DEBUG_FORCE_WEAK_PER_CPU
 285        bool "Force weak per-cpu definitions"
 286        depends on DEBUG_KERNEL
 287        help
 288          s390 and alpha require percpu variables in modules to be
 289          defined weak to work around addressing range issue which
 290          puts the following two restrictions on percpu variable
 291          definitions.
 292
 293          1. percpu symbols must be unique whether static or not
 294          2. percpu variables can't be defined inside a function
 295
 296          To ensure that generic code follows the above rules, this
 297          option forces all percpu variables to be defined as weak.
 298
 299endmenu # "Compiler options"
 300
 301config MAGIC_SYSRQ
 302        bool "Magic SysRq key"
 303        depends on !UML
 304        help
 305          If you say Y here, you will have some control over the system even
 306          if the system crashes for example during kernel debugging (e.g., you
 307          will be able to flush the buffer cache to disk, reboot the system
 308          immediately or dump some status information). This is accomplished
 309          by pressing various keys while holding SysRq (Alt+PrintScreen). It
 310          also works on a serial console (on PC hardware at least), if you
 311          send a BREAK and then within 5 seconds a command keypress. The
 312          keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
 313          unless you really know what this hack does.
 314
 315config DEBUG_KERNEL
 316        bool "Kernel debugging"
 317        help
 318          Say Y here if you are developing drivers or trying to debug and
 319          identify kernel problems.
 320
 321menu "Memory Debugging"
 322
 323source mm/Kconfig.debug
 324
 325config DEBUG_OBJECTS
 326        bool "Debug object operations"
 327        depends on DEBUG_KERNEL
 328        help
 329          If you say Y here, additional code will be inserted into the
 330          kernel to track the life time of various objects and validate
 331          the operations on those objects.
 332
 333config DEBUG_OBJECTS_SELFTEST
 334        bool "Debug objects selftest"
 335        depends on DEBUG_OBJECTS
 336        help
 337          This enables the selftest of the object debug code.
 338
 339config DEBUG_OBJECTS_FREE
 340        bool "Debug objects in freed memory"
 341        depends on DEBUG_OBJECTS
 342        help
 343          This enables checks whether a k/v free operation frees an area
 344          which contains an object which has not been deactivated
 345          properly. This can make kmalloc/kfree-intensive workloads
 346          much slower.
 347
 348config DEBUG_OBJECTS_TIMERS
 349        bool "Debug timer objects"
 350        depends on DEBUG_OBJECTS
 351        help
 352          If you say Y here, additional code will be inserted into the
 353          timer routines to track the life time of timer objects and
 354          validate the timer operations.
 355
 356config DEBUG_OBJECTS_WORK
 357        bool "Debug work objects"
 358        depends on DEBUG_OBJECTS
 359        help
 360          If you say Y here, additional code will be inserted into the
 361          work queue routines to track the life time of work objects and
 362          validate the work operations.
 363
 364config DEBUG_OBJECTS_RCU_HEAD
 365        bool "Debug RCU callbacks objects"
 366        depends on DEBUG_OBJECTS
 367        help
 368          Enable this to turn on debugging of RCU list heads (call_rcu() usage).
 369
 370config DEBUG_OBJECTS_PERCPU_COUNTER
 371        bool "Debug percpu counter objects"
 372        depends on DEBUG_OBJECTS
 373        help
 374          If you say Y here, additional code will be inserted into the
 375          percpu counter routines to track the life time of percpu counter
 376          objects and validate the percpu counter operations.
 377
 378config DEBUG_OBJECTS_ENABLE_DEFAULT
 379        int "debug_objects bootup default value (0-1)"
 380        range 0 1
 381        default "1"
 382        depends on DEBUG_OBJECTS
 383        help
 384          Debug objects boot parameter default value
 385
 386config DEBUG_SLAB
 387        bool "Debug slab memory allocations"
 388        depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
 389        help
 390          Say Y here to have the kernel do limited verification on memory
 391          allocation as well as poisoning memory on free to catch use of freed
 392          memory. This can make kmalloc/kfree-intensive workloads much slower.
 393
 394config DEBUG_SLAB_LEAK
 395        bool "Memory leak debugging"
 396        depends on DEBUG_SLAB
 397
 398config SLUB_DEBUG_ON
 399        bool "SLUB debugging on by default"
 400        depends on SLUB && SLUB_DEBUG && !KMEMCHECK
 401        default n
 402        help
 403          Boot with debugging on by default. SLUB boots by default with
 404          the runtime debug capabilities switched off. Enabling this is
 405          equivalent to specifying the "slub_debug" parameter on boot.
 406          There is no support for more fine grained debug control like
 407          possible with slub_debug=xxx. SLUB debugging may be switched
 408          off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
 409          "slub_debug=-".
 410
 411config SLUB_STATS
 412        default n
 413        bool "Enable SLUB performance statistics"
 414        depends on SLUB && SYSFS
 415        help
 416          SLUB statistics are useful to debug SLUBs allocation behavior in
 417          order find ways to optimize the allocator. This should never be
 418          enabled for production use since keeping statistics slows down
 419          the allocator by a few percentage points. The slabinfo command
 420          supports the determination of the most active slabs to figure
 421          out which slabs are relevant to a particular load.
 422          Try running: slabinfo -DA
 423
 424config HAVE_DEBUG_KMEMLEAK
 425        bool
 426
 427config DEBUG_KMEMLEAK
 428        bool "Kernel memory leak detector"
 429        depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK
 430        select DEBUG_FS
 431        select STACKTRACE if STACKTRACE_SUPPORT
 432        select KALLSYMS
 433        select CRC32
 434        help
 435          Say Y here if you want to enable the memory leak
 436          detector. The memory allocation/freeing is traced in a way
 437          similar to the Boehm's conservative garbage collector, the
 438          difference being that the orphan objects are not freed but
 439          only shown in /sys/kernel/debug/kmemleak. Enabling this
 440          feature will introduce an overhead to memory
 441          allocations. See Documentation/kmemleak.txt for more
 442          details.
 443
 444          Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
 445          of finding leaks due to the slab objects poisoning.
 446
 447          In order to access the kmemleak file, debugfs needs to be
 448          mounted (usually at /sys/kernel/debug).
 449
 450config DEBUG_KMEMLEAK_EARLY_LOG_SIZE
 451        int "Maximum kmemleak early log entries"
 452        depends on DEBUG_KMEMLEAK
 453        range 200 40000
 454        default 400
 455        help
 456          Kmemleak must track all the memory allocations to avoid
 457          reporting false positives. Since memory may be allocated or
 458          freed before kmemleak is initialised, an early log buffer is
 459          used to store these actions. If kmemleak reports "early log
 460          buffer exceeded", please increase this value.
 461
 462config DEBUG_KMEMLEAK_TEST
 463        tristate "Simple test for the kernel memory leak detector"
 464        depends on DEBUG_KMEMLEAK && m
 465        help
 466          This option enables a module that explicitly leaks memory.
 467
 468          If unsure, say N.
 469
 470config DEBUG_KMEMLEAK_DEFAULT_OFF
 471        bool "Default kmemleak to off"
 472        depends on DEBUG_KMEMLEAK
 473        help
 474          Say Y here to disable kmemleak by default. It can then be enabled
 475          on the command line via kmemleak=on.
 476
 477config DEBUG_STACK_USAGE
 478        bool "Stack utilization instrumentation"
 479        depends on DEBUG_KERNEL && !IA64 && !PARISC && !METAG
 480        help
 481          Enables the display of the minimum amount of free stack which each
 482          task has ever had available in the sysrq-T and sysrq-P debug output.
 483
 484          This option will slow down process creation somewhat.
 485
 486config DEBUG_VM
 487        bool "Debug VM"
 488        depends on DEBUG_KERNEL
 489        help
 490          Enable this to turn on extended checks in the virtual-memory system
 491          that may impact performance.
 492
 493          If unsure, say N.
 494
 495config DEBUG_VM_RB
 496        bool "Debug VM red-black trees"
 497        depends on DEBUG_VM
 498        help
 499          Enable this to turn on more extended checks in the virtual-memory
 500          system that may impact performance.
 501
 502          If unsure, say N.
 503
 504config DEBUG_VIRTUAL
 505        bool "Debug VM translations"
 506        depends on DEBUG_KERNEL && X86
 507        help
 508          Enable some costly sanity checks in virtual to page code. This can
 509          catch mistakes with virt_to_page() and friends.
 510
 511          If unsure, say N.
 512
 513config DEBUG_NOMMU_REGIONS
 514        bool "Debug the global anon/private NOMMU mapping region tree"
 515        depends on DEBUG_KERNEL && !MMU
 516        help
 517          This option causes the global tree of anonymous and private mapping
 518          regions to be regularly checked for invalid topology.
 519
 520config DEBUG_MEMORY_INIT
 521        bool "Debug memory initialisation" if EXPERT
 522        default !EXPERT
 523        help
 524          Enable this for additional checks during memory initialisation.
 525          The sanity checks verify aspects of the VM such as the memory model
 526          and other information provided by the architecture. Verbose
 527          information will be printed at KERN_DEBUG loglevel depending
 528          on the mminit_loglevel= command-line option.
 529
 530          If unsure, say Y
 531
 532config MEMORY_NOTIFIER_ERROR_INJECT
 533        tristate "Memory hotplug notifier error injection module"
 534        depends on MEMORY_HOTPLUG_SPARSE && NOTIFIER_ERROR_INJECTION
 535        help
 536          This option provides the ability to inject artificial errors to
 537          memory hotplug notifier chain callbacks.  It is controlled through
 538          debugfs interface under /sys/kernel/debug/notifier-error-inject/memory
 539
 540          If the notifier call chain should be failed with some events
 541          notified, write the error code to "actions/<notifier event>/error".
 542
 543          Example: Inject memory hotplug offline error (-12 == -ENOMEM)
 544
 545          # cd /sys/kernel/debug/notifier-error-inject/memory
 546          # echo -12 > actions/MEM_GOING_OFFLINE/error
 547          # echo offline > /sys/devices/system/memory/memoryXXX/state
 548          bash: echo: write error: Cannot allocate memory
 549
 550          To compile this code as a module, choose M here: the module will
 551          be called memory-notifier-error-inject.
 552
 553          If unsure, say N.
 554
 555config DEBUG_PER_CPU_MAPS
 556        bool "Debug access to per_cpu maps"
 557        depends on DEBUG_KERNEL
 558        depends on SMP
 559        help
 560          Say Y to verify that the per_cpu map being accessed has
 561          been set up. This adds a fair amount of code to kernel memory
 562          and decreases performance.
 563
 564          Say N if unsure.
 565
 566config DEBUG_HIGHMEM
 567        bool "Highmem debugging"
 568        depends on DEBUG_KERNEL && HIGHMEM
 569        help
 570          This options enables addition error checking for high memory systems.
 571          Disable for production systems.
 572
 573config HAVE_DEBUG_STACKOVERFLOW
 574        bool
 575
 576config DEBUG_STACKOVERFLOW
 577        bool "Check for stack overflows"
 578        depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW
 579        ---help---
 580          Say Y here if you want to check for overflows of kernel, IRQ
 581          and exception stacks (if your archicture uses them). This
 582          option will show detailed messages if free stack space drops
 583          below a certain limit.
 584
 585          These kinds of bugs usually occur when call-chains in the
 586          kernel get too deep, especially when interrupts are
 587          involved.
 588
 589          Use this in cases where you see apparently random memory
 590          corruption, especially if it appears in 'struct thread_info'
 591
 592          If in doubt, say "N".
 593
 594source "lib/Kconfig.kmemcheck"
 595
 596endmenu # "Memory Debugging"
 597
 598config DEBUG_SHIRQ
 599        bool "Debug shared IRQ handlers"
 600        depends on DEBUG_KERNEL && GENERIC_HARDIRQS
 601        help
 602          Enable this to generate a spurious interrupt as soon as a shared
 603          interrupt handler is registered, and just before one is deregistered.
 604          Drivers ought to be able to handle interrupts coming in at those
 605          points; some don't and need to be caught.
 606
 607menu "Debug Lockups and Hangs"
 608
 609config LOCKUP_DETECTOR
 610        bool "Detect Hard and Soft Lockups"
 611        depends on DEBUG_KERNEL && !S390
 612        help
 613          Say Y here to enable the kernel to act as a watchdog to detect
 614          hard and soft lockups.
 615
 616          Softlockups are bugs that cause the kernel to loop in kernel
 617          mode for more than 20 seconds, without giving other tasks a
 618          chance to run.  The current stack trace is displayed upon
 619          detection and the system will stay locked up.
 620
 621          Hardlockups are bugs that cause the CPU to loop in kernel mode
 622          for more than 10 seconds, without letting other interrupts have a
 623          chance to run.  The current stack trace is displayed upon detection
 624          and the system will stay locked up.
 625
 626          The overhead should be minimal.  A periodic hrtimer runs to
 627          generate interrupts and kick the watchdog task every 4 seconds.
 628          An NMI is generated every 10 seconds or so to check for hardlockups.
 629
 630          The frequency of hrtimer and NMI events and the soft and hard lockup
 631          thresholds can be controlled through the sysctl watchdog_thresh.
 632
 633config HARDLOCKUP_DETECTOR
 634        def_bool y
 635        depends on LOCKUP_DETECTOR && !HAVE_NMI_WATCHDOG
 636        depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI
 637
 638config BOOTPARAM_HARDLOCKUP_PANIC
 639        bool "Panic (Reboot) On Hard Lockups"
 640        depends on HARDLOCKUP_DETECTOR
 641        help
 642          Say Y here to enable the kernel to panic on "hard lockups",
 643          which are bugs that cause the kernel to loop in kernel
 644          mode with interrupts disabled for more than 10 seconds (configurable
 645          using the watchdog_thresh sysctl).
 646
 647          Say N if unsure.
 648
 649config BOOTPARAM_HARDLOCKUP_PANIC_VALUE
 650        int
 651        depends on HARDLOCKUP_DETECTOR
 652        range 0 1
 653        default 0 if !BOOTPARAM_HARDLOCKUP_PANIC
 654        default 1 if BOOTPARAM_HARDLOCKUP_PANIC
 655
 656config BOOTPARAM_SOFTLOCKUP_PANIC
 657        bool "Panic (Reboot) On Soft Lockups"
 658        depends on LOCKUP_DETECTOR
 659        help
 660          Say Y here to enable the kernel to panic on "soft lockups",
 661          which are bugs that cause the kernel to loop in kernel
 662          mode for more than 20 seconds (configurable using the watchdog_thresh
 663          sysctl), without giving other tasks a chance to run.
 664
 665          The panic can be used in combination with panic_timeout,
 666          to cause the system to reboot automatically after a
 667          lockup has been detected. This feature is useful for
 668          high-availability systems that have uptime guarantees and
 669          where a lockup must be resolved ASAP.
 670
 671          Say N if unsure.
 672
 673config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
 674        int
 675        depends on LOCKUP_DETECTOR
 676        range 0 1
 677        default 0 if !BOOTPARAM_SOFTLOCKUP_PANIC
 678        default 1 if BOOTPARAM_SOFTLOCKUP_PANIC
 679
 680config DETECT_HUNG_TASK
 681        bool "Detect Hung Tasks"
 682        depends on DEBUG_KERNEL
 683        default LOCKUP_DETECTOR
 684        help
 685          Say Y here to enable the kernel to detect "hung tasks",
 686          which are bugs that cause the task to be stuck in
 687          uninterruptible "D" state indefinitiley.
 688
 689          When a hung task is detected, the kernel will print the
 690          current stack trace (which you should report), but the
 691          task will stay in uninterruptible state. If lockdep is
 692          enabled then all held locks will also be reported. This
 693          feature has negligible overhead.
 694
 695config DEFAULT_HUNG_TASK_TIMEOUT
 696        int "Default timeout for hung task detection (in seconds)"
 697        depends on DETECT_HUNG_TASK
 698        default 120
 699        help
 700          This option controls the default timeout (in seconds) used
 701          to determine when a task has become non-responsive and should
 702          be considered hung.
 703
 704          It can be adjusted at runtime via the kernel.hung_task_timeout_secs
 705          sysctl or by writing a value to
 706          /proc/sys/kernel/hung_task_timeout_secs.
 707
 708          A timeout of 0 disables the check.  The default is two minutes.
 709          Keeping the default should be fine in most cases.
 710
 711config BOOTPARAM_HUNG_TASK_PANIC
 712        bool "Panic (Reboot) On Hung Tasks"
 713        depends on DETECT_HUNG_TASK
 714        help
 715          Say Y here to enable the kernel to panic on "hung tasks",
 716          which are bugs that cause the kernel to leave a task stuck
 717          in uninterruptible "D" state.
 718
 719          The panic can be used in combination with panic_timeout,
 720          to cause the system to reboot automatically after a
 721          hung task has been detected. This feature is useful for
 722          high-availability systems that have uptime guarantees and
 723          where a hung tasks must be resolved ASAP.
 724
 725          Say N if unsure.
 726
 727config BOOTPARAM_HUNG_TASK_PANIC_VALUE
 728        int
 729        depends on DETECT_HUNG_TASK
 730        range 0 1
 731        default 0 if !BOOTPARAM_HUNG_TASK_PANIC
 732        default 1 if BOOTPARAM_HUNG_TASK_PANIC
 733
 734endmenu # "Debug lockups and hangs"
 735
 736config PANIC_ON_OOPS
 737        bool "Panic on Oops"
 738        help
 739          Say Y here to enable the kernel to panic when it oopses. This
 740          has the same effect as setting oops=panic on the kernel command
 741          line.
 742
 743          This feature is useful to ensure that the kernel does not do
 744          anything erroneous after an oops which could result in data
 745          corruption or other issues.
 746
 747          Say N if unsure.
 748
 749config PANIC_ON_OOPS_VALUE
 750        int
 751        range 0 1
 752        default 0 if !PANIC_ON_OOPS
 753        default 1 if PANIC_ON_OOPS
 754
 755config SCHED_DEBUG
 756        bool "Collect scheduler debugging info"
 757        depends on DEBUG_KERNEL && PROC_FS
 758        default y
 759        help
 760          If you say Y here, the /proc/sched_debug file will be provided
 761          that can help debug the scheduler. The runtime overhead of this
 762          option is minimal.
 763
 764config SCHEDSTATS
 765        bool "Collect scheduler statistics"
 766        depends on DEBUG_KERNEL && PROC_FS
 767        help
 768          If you say Y here, additional code will be inserted into the
 769          scheduler and related routines to collect statistics about
 770          scheduler behavior and provide them in /proc/schedstat.  These
 771          stats may be useful for both tuning and debugging the scheduler
 772          If you aren't debugging the scheduler or trying to tune a specific
 773          application, you can say N to avoid the very slight overhead
 774          this adds.
 775
 776config TIMER_STATS
 777        bool "Collect kernel timers statistics"
 778        depends on DEBUG_KERNEL && PROC_FS
 779        help
 780          If you say Y here, additional code will be inserted into the
 781          timer routines to collect statistics about kernel timers being
 782          reprogrammed. The statistics can be read from /proc/timer_stats.
 783          The statistics collection is started by writing 1 to /proc/timer_stats,
 784          writing 0 stops it. This feature is useful to collect information
 785          about timer usage patterns in kernel and userspace. This feature
 786          is lightweight if enabled in the kernel config but not activated
 787          (it defaults to deactivated on bootup and will only be activated
 788          if some application like powertop activates it explicitly).
 789
 790config DEBUG_PREEMPT
 791        bool "Debug preemptible kernel"
 792        depends on DEBUG_KERNEL && PREEMPT && TRACE_IRQFLAGS_SUPPORT
 793        default y
 794        help
 795          If you say Y here then the kernel will use a debug variant of the
 796          commonly used smp_processor_id() function and will print warnings
 797          if kernel code uses it in a preemption-unsafe way. Also, the kernel
 798          will detect preemption count underflows.
 799
 800menu "Lock Debugging (spinlocks, mutexes, etc...)"
 801
 802config DEBUG_RT_MUTEXES
 803        bool "RT Mutex debugging, deadlock detection"
 804        depends on DEBUG_KERNEL && RT_MUTEXES
 805        help
 806         This allows rt mutex semantics violations and rt mutex related
 807         deadlocks (lockups) to be detected and reported automatically.
 808
 809config DEBUG_PI_LIST
 810        bool
 811        default y
 812        depends on DEBUG_RT_MUTEXES
 813
 814config RT_MUTEX_TESTER
 815        bool "Built-in scriptable tester for rt-mutexes"
 816        depends on DEBUG_KERNEL && RT_MUTEXES
 817        help
 818          This option enables a rt-mutex tester.
 819
 820config DEBUG_SPINLOCK
 821        bool "Spinlock and rw-lock debugging: basic checks"
 822        depends on DEBUG_KERNEL
 823        select UNINLINE_SPIN_UNLOCK
 824        help
 825          Say Y here and build SMP to catch missing spinlock initialization
 826          and certain other kinds of spinlock errors commonly made.  This is
 827          best used in conjunction with the NMI watchdog so that spinlock
 828          deadlocks are also debuggable.
 829
 830config DEBUG_MUTEXES
 831        bool "Mutex debugging: basic checks"
 832        depends on DEBUG_KERNEL
 833        help
 834         This feature allows mutex semantics violations to be detected and
 835         reported.
 836
 837config DEBUG_WW_MUTEX_SLOWPATH
 838        bool "Wait/wound mutex debugging: Slowpath testing"
 839        depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
 840        select DEBUG_LOCK_ALLOC
 841        select DEBUG_SPINLOCK
 842        select DEBUG_MUTEXES
 843        help
 844         This feature enables slowpath testing for w/w mutex users by
 845         injecting additional -EDEADLK wound/backoff cases. Together with
 846         the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this
 847         will test all possible w/w mutex interface abuse with the
 848         exception of simply not acquiring all the required locks.
 849
 850config DEBUG_LOCK_ALLOC
 851        bool "Lock debugging: detect incorrect freeing of live locks"
 852        depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
 853        select DEBUG_SPINLOCK
 854        select DEBUG_MUTEXES
 855        select LOCKDEP
 856        help
 857         This feature will check whether any held lock (spinlock, rwlock,
 858         mutex or rwsem) is incorrectly freed by the kernel, via any of the
 859         memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
 860         vfree(), etc.), whether a live lock is incorrectly reinitialized via
 861         spin_lock_init()/mutex_init()/etc., or whether there is any lock
 862         held during task exit.
 863
 864config PROVE_LOCKING
 865        bool "Lock debugging: prove locking correctness"
 866        depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
 867        select LOCKDEP
 868        select DEBUG_SPINLOCK
 869        select DEBUG_MUTEXES
 870        select DEBUG_LOCK_ALLOC
 871        select TRACE_IRQFLAGS
 872        default n
 873        help
 874         This feature enables the kernel to prove that all locking
 875         that occurs in the kernel runtime is mathematically
 876         correct: that under no circumstance could an arbitrary (and
 877         not yet triggered) combination of observed locking
 878         sequences (on an arbitrary number of CPUs, running an
 879         arbitrary number of tasks and interrupt contexts) cause a
 880         deadlock.
 881
 882         In short, this feature enables the kernel to report locking
 883         related deadlocks before they actually occur.
 884
 885         The proof does not depend on how hard and complex a
 886         deadlock scenario would be to trigger: how many
 887         participant CPUs, tasks and irq-contexts would be needed
 888         for it to trigger. The proof also does not depend on
 889         timing: if a race and a resulting deadlock is possible
 890         theoretically (no matter how unlikely the race scenario
 891         is), it will be proven so and will immediately be
 892         reported by the kernel (once the event is observed that
 893         makes the deadlock theoretically possible).
 894
 895         If a deadlock is impossible (i.e. the locking rules, as
 896         observed by the kernel, are mathematically correct), the
 897         kernel reports nothing.
 898
 899         NOTE: this feature can also be enabled for rwlocks, mutexes
 900         and rwsems - in which case all dependencies between these
 901         different locking variants are observed and mapped too, and
 902         the proof of observed correctness is also maintained for an
 903         arbitrary combination of these separate locking variants.
 904
 905         For more details, see Documentation/lockdep-design.txt.
 906
 907config LOCKDEP
 908        bool
 909        depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
 910        select STACKTRACE
 911        select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390 && !MICROBLAZE
 912        select KALLSYMS
 913        select KALLSYMS_ALL
 914
 915config LOCK_STAT
 916        bool "Lock usage statistics"
 917        depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
 918        select LOCKDEP
 919        select DEBUG_SPINLOCK
 920        select DEBUG_MUTEXES
 921        select DEBUG_LOCK_ALLOC
 922        default n
 923        help
 924         This feature enables tracking lock contention points
 925
 926         For more details, see Documentation/lockstat.txt
 927
 928         This also enables lock events required by "perf lock",
 929         subcommand of perf.
 930         If you want to use "perf lock", you also need to turn on
 931         CONFIG_EVENT_TRACING.
 932
 933         CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
 934         (CONFIG_LOCKDEP defines "acquire" and "release" events.)
 935
 936config DEBUG_LOCKDEP
 937        bool "Lock dependency engine debugging"
 938        depends on DEBUG_KERNEL && LOCKDEP
 939        help
 940          If you say Y here, the lock dependency engine will do
 941          additional runtime checks to debug itself, at the price
 942          of more runtime overhead.
 943
 944config DEBUG_ATOMIC_SLEEP
 945        bool "Sleep inside atomic section checking"
 946        select PREEMPT_COUNT
 947        depends on DEBUG_KERNEL
 948        help
 949          If you say Y here, various routines which may sleep will become very
 950          noisy if they are called inside atomic sections: when a spinlock is
 951          held, inside an rcu read side critical section, inside preempt disabled
 952          sections, inside an interrupt, etc...
 953
 954config DEBUG_LOCKING_API_SELFTESTS
 955        bool "Locking API boot-time self-tests"
 956        depends on DEBUG_KERNEL
 957        help
 958          Say Y here if you want the kernel to run a short self-test during
 959          bootup. The self-test checks whether common types of locking bugs
 960          are detected by debugging mechanisms or not. (if you disable
 961          lock debugging then those bugs wont be detected of course.)
 962          The following locking APIs are covered: spinlocks, rwlocks,
 963          mutexes and rwsems.
 964
 965endmenu # lock debugging
 966
 967config TRACE_IRQFLAGS
 968        bool
 969        help
 970          Enables hooks to interrupt enabling and disabling for
 971          either tracing or lock debugging.
 972
 973config STACKTRACE
 974        bool
 975        depends on STACKTRACE_SUPPORT
 976
 977config DEBUG_KOBJECT
 978        bool "kobject debugging"
 979        depends on DEBUG_KERNEL
 980        help
 981          If you say Y here, some extra kobject debugging messages will be sent
 982          to the syslog. 
 983
 984config HAVE_DEBUG_BUGVERBOSE
 985        bool
 986
 987config DEBUG_BUGVERBOSE
 988        bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
 989        depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
 990        default y
 991        help
 992          Say Y here to make BUG() panics output the file name and line number
 993          of the BUG call as well as the EIP and oops trace.  This aids
 994          debugging but costs about 70-100K of memory.
 995
 996config DEBUG_WRITECOUNT
 997        bool "Debug filesystem writers count"
 998        depends on DEBUG_KERNEL
 999        help
1000          Enable this to catch wrong use of the writers count in struct
1001          vfsmount.  This will increase the size of each file struct by
1002          32 bits.
1003
1004          If unsure, say N.
1005
1006config DEBUG_LIST
1007        bool "Debug linked list manipulation"
1008        depends on DEBUG_KERNEL
1009        help
1010          Enable this to turn on extended checks in the linked-list
1011          walking routines.
1012
1013          If unsure, say N.
1014
1015config DEBUG_SG
1016        bool "Debug SG table operations"
1017        depends on DEBUG_KERNEL
1018        help
1019          Enable this to turn on checks on scatter-gather tables. This can
1020          help find problems with drivers that do not properly initialize
1021          their sg tables.
1022
1023          If unsure, say N.
1024
1025config DEBUG_NOTIFIERS
1026        bool "Debug notifier call chains"
1027        depends on DEBUG_KERNEL
1028        help
1029          Enable this to turn on sanity checking for notifier call chains.
1030          This is most useful for kernel developers to make sure that
1031          modules properly unregister themselves from notifier chains.
1032          This is a relatively cheap check but if you care about maximum
1033          performance, say N.
1034
1035config DEBUG_CREDENTIALS
1036        bool "Debug credential management"
1037        depends on DEBUG_KERNEL
1038        help
1039          Enable this to turn on some debug checking for credential
1040          management.  The additional code keeps track of the number of
1041          pointers from task_structs to any given cred struct, and checks to
1042          see that this number never exceeds the usage count of the cred
1043          struct.
1044
1045          Furthermore, if SELinux is enabled, this also checks that the
1046          security pointer in the cred struct is never seen to be invalid.
1047
1048          If unsure, say N.
1049
1050menu "RCU Debugging"
1051
1052config PROVE_RCU
1053        bool "RCU debugging: prove RCU correctness"
1054        depends on PROVE_LOCKING
1055        default n
1056        help
1057         This feature enables lockdep extensions that check for correct
1058         use of RCU APIs.  This is currently under development.  Say Y
1059         if you want to debug RCU usage or help work on the PROVE_RCU
1060         feature.
1061
1062         Say N if you are unsure.
1063
1064config PROVE_RCU_REPEATEDLY
1065        bool "RCU debugging: don't disable PROVE_RCU on first splat"
1066        depends on PROVE_RCU
1067        default n
1068        help
1069         By itself, PROVE_RCU will disable checking upon issuing the
1070         first warning (or "splat").  This feature prevents such
1071         disabling, allowing multiple RCU-lockdep warnings to be printed
1072         on a single reboot.
1073
1074         Say Y to allow multiple RCU-lockdep warnings per boot.
1075
1076         Say N if you are unsure.
1077
1078config PROVE_RCU_DELAY
1079        bool "RCU debugging: preemptible RCU race provocation"
1080        depends on DEBUG_KERNEL && PREEMPT_RCU
1081        default n
1082        help
1083         There is a class of races that involve an unlikely preemption
1084         of __rcu_read_unlock() just after ->rcu_read_lock_nesting has
1085         been set to INT_MIN.  This feature inserts a delay at that
1086         point to increase the probability of these races.
1087
1088         Say Y to increase probability of preemption of __rcu_read_unlock().
1089
1090         Say N if you are unsure.
1091
1092config SPARSE_RCU_POINTER
1093        bool "RCU debugging: sparse-based checks for pointer usage"
1094        default n
1095        help
1096         This feature enables the __rcu sparse annotation for
1097         RCU-protected pointers.  This annotation will cause sparse
1098         to flag any non-RCU used of annotated pointers.  This can be
1099         helpful when debugging RCU usage.  Please note that this feature
1100         is not intended to enforce code cleanliness; it is instead merely
1101         a debugging aid.
1102
1103         Say Y to make sparse flag questionable use of RCU-protected pointers
1104
1105         Say N if you are unsure.
1106
1107config RCU_TORTURE_TEST
1108        tristate "torture tests for RCU"
1109        depends on DEBUG_KERNEL
1110        default n
1111        help
1112          This option provides a kernel module that runs torture tests
1113          on the RCU infrastructure.  The kernel module may be built
1114          after the fact on the running kernel to be tested, if desired.
1115
1116          Say Y here if you want RCU torture tests to be built into
1117          the kernel.
1118          Say M if you want the RCU torture tests to build as a module.
1119          Say N if you are unsure.
1120
1121config RCU_TORTURE_TEST_RUNNABLE
1122        bool "torture tests for RCU runnable by default"
1123        depends on RCU_TORTURE_TEST = y
1124        default n
1125        help
1126          This option provides a way to build the RCU torture tests
1127          directly into the kernel without them starting up at boot
1128          time.  You can use /proc/sys/kernel/rcutorture_runnable
1129          to manually override this setting.  This /proc file is
1130          available only when the RCU torture tests have been built
1131          into the kernel.
1132
1133          Say Y here if you want the RCU torture tests to start during
1134          boot (you probably don't).
1135          Say N here if you want the RCU torture tests to start only
1136          after being manually enabled via /proc.
1137
1138config RCU_CPU_STALL_TIMEOUT
1139        int "RCU CPU stall timeout in seconds"
1140        depends on RCU_STALL_COMMON
1141        range 3 300
1142        default 21
1143        help
1144          If a given RCU grace period extends more than the specified
1145          number of seconds, a CPU stall warning is printed.  If the
1146          RCU grace period persists, additional CPU stall warnings are
1147          printed at more widely spaced intervals.
1148
1149config RCU_CPU_STALL_VERBOSE
1150        bool "Print additional per-task information for RCU_CPU_STALL_DETECTOR"
1151        depends on TREE_PREEMPT_RCU
1152        default y
1153        help
1154          This option causes RCU to printk detailed per-task information
1155          for any tasks that are stalling the current RCU grace period.
1156
1157          Say N if you are unsure.
1158
1159          Say Y if you want to enable such checks.
1160
1161config RCU_CPU_STALL_INFO
1162        bool "Print additional diagnostics on RCU CPU stall"
1163        depends on (TREE_RCU || TREE_PREEMPT_RCU) && DEBUG_KERNEL
1164        default n
1165        help
1166          For each stalled CPU that is aware of the current RCU grace
1167          period, print out additional per-CPU diagnostic information
1168          regarding scheduling-clock ticks, idle state, and,
1169          for RCU_FAST_NO_HZ kernels, idle-entry state.
1170
1171          Say N if you are unsure.
1172
1173          Say Y if you want to enable such diagnostics.
1174
1175config RCU_TRACE
1176        bool "Enable tracing for RCU"
1177        depends on DEBUG_KERNEL
1178        select TRACE_CLOCK
1179        help
1180          This option provides tracing in RCU which presents stats
1181          in debugfs for debugging RCU implementation.
1182
1183          Say Y here if you want to enable RCU tracing
1184          Say N if you are unsure.
1185
1186endmenu # "RCU Debugging"
1187
1188config DEBUG_BLOCK_EXT_DEVT
1189        bool "Force extended block device numbers and spread them"
1190        depends on DEBUG_KERNEL
1191        depends on BLOCK
1192        default n
1193        help
1194          BIG FAT WARNING: ENABLING THIS OPTION MIGHT BREAK BOOTING ON
1195          SOME DISTRIBUTIONS.  DO NOT ENABLE THIS UNLESS YOU KNOW WHAT
1196          YOU ARE DOING.  Distros, please enable this and fix whatever
1197          is broken.
1198
1199          Conventionally, block device numbers are allocated from
1200          predetermined contiguous area.  However, extended block area
1201          may introduce non-contiguous block device numbers.  This
1202          option forces most block device numbers to be allocated from
1203          the extended space and spreads them to discover kernel or
1204          userland code paths which assume predetermined contiguous
1205          device number allocation.
1206
1207          Note that turning on this debug option shuffles all the
1208          device numbers for all IDE and SCSI devices including libata
1209          ones, so root partition specified using device number
1210          directly (via rdev or root=MAJ:MIN) won't work anymore.
1211          Textual device names (root=/dev/sdXn) will continue to work.
1212
1213          Say N if you are unsure.
1214
1215config NOTIFIER_ERROR_INJECTION
1216        tristate "Notifier error injection"
1217        depends on DEBUG_KERNEL
1218        select DEBUG_FS
1219        help
1220          This option provides the ability to inject artificial errors to
1221          specified notifier chain callbacks. It is useful to test the error
1222          handling of notifier call chain failures.
1223
1224          Say N if unsure.
1225
1226config CPU_NOTIFIER_ERROR_INJECT
1227        tristate "CPU notifier error injection module"
1228        depends on HOTPLUG_CPU && NOTIFIER_ERROR_INJECTION
1229        help
1230          This option provides a kernel module that can be used to test
1231          the error handling of the cpu notifiers by injecting artificial
1232          errors to CPU notifier chain callbacks.  It is controlled through
1233          debugfs interface under /sys/kernel/debug/notifier-error-inject/cpu
1234
1235          If the notifier call chain should be failed with some events
1236          notified, write the error code to "actions/<notifier event>/error".
1237
1238          Example: Inject CPU offline error (-1 == -EPERM)
1239
1240          # cd /sys/kernel/debug/notifier-error-inject/cpu
1241          # echo -1 > actions/CPU_DOWN_PREPARE/error
1242          # echo 0 > /sys/devices/system/cpu/cpu1/online
1243          bash: echo: write error: Operation not permitted
1244
1245          To compile this code as a module, choose M here: the module will
1246          be called cpu-notifier-error-inject.
1247
1248          If unsure, say N.
1249
1250config PM_NOTIFIER_ERROR_INJECT
1251        tristate "PM notifier error injection module"
1252        depends on PM && NOTIFIER_ERROR_INJECTION
1253        default m if PM_DEBUG
1254        help
1255          This option provides the ability to inject artificial errors to
1256          PM notifier chain callbacks.  It is controlled through debugfs
1257          interface /sys/kernel/debug/notifier-error-inject/pm
1258
1259          If the notifier call chain should be failed with some events
1260          notified, write the error code to "actions/<notifier event>/error".
1261
1262          Example: Inject PM suspend error (-12 = -ENOMEM)
1263
1264          # cd /sys/kernel/debug/notifier-error-inject/pm/
1265          # echo -12 > actions/PM_SUSPEND_PREPARE/error
1266          # echo mem > /sys/power/state
1267          bash: echo: write error: Cannot allocate memory
1268
1269          To compile this code as a module, choose M here: the module will
1270          be called pm-notifier-error-inject.
1271
1272          If unsure, say N.
1273
1274config OF_RECONFIG_NOTIFIER_ERROR_INJECT
1275        tristate "OF reconfig notifier error injection module"
1276        depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
1277        help
1278          This option provides the ability to inject artificial errors to
1279          OF reconfig notifier chain callbacks.  It is controlled
1280          through debugfs interface under
1281          /sys/kernel/debug/notifier-error-inject/OF-reconfig/
1282
1283          If the notifier call chain should be failed with some events
1284          notified, write the error code to "actions/<notifier event>/error".
1285
1286          To compile this code as a module, choose M here: the module will
1287          be called of-reconfig-notifier-error-inject.
1288
1289          If unsure, say N.
1290
1291config FAULT_INJECTION
1292        bool "Fault-injection framework"
1293        depends on DEBUG_KERNEL
1294        help
1295          Provide fault-injection framework.
1296          For more details, see Documentation/fault-injection/.
1297
1298config FAILSLAB
1299        bool "Fault-injection capability for kmalloc"
1300        depends on FAULT_INJECTION
1301        depends on SLAB || SLUB
1302        help
1303          Provide fault-injection capability for kmalloc.
1304
1305config FAIL_PAGE_ALLOC
1306        bool "Fault-injection capabilitiy for alloc_pages()"
1307        depends on FAULT_INJECTION
1308        help
1309          Provide fault-injection capability for alloc_pages().
1310
1311config FAIL_MAKE_REQUEST
1312        bool "Fault-injection capability for disk IO"
1313        depends on FAULT_INJECTION && BLOCK
1314        help
1315          Provide fault-injection capability for disk IO.
1316
1317config FAIL_IO_TIMEOUT
1318        bool "Fault-injection capability for faking disk interrupts"
1319        depends on FAULT_INJECTION && BLOCK
1320        help
1321          Provide fault-injection capability on end IO handling. This
1322          will make the block layer "forget" an interrupt as configured,
1323          thus exercising the error handling.
1324
1325          Only works with drivers that use the generic timeout handling,
1326          for others it wont do anything.
1327
1328config FAIL_MMC_REQUEST
1329        bool "Fault-injection capability for MMC IO"
1330        select DEBUG_FS
1331        depends on FAULT_INJECTION && MMC
1332        help
1333          Provide fault-injection capability for MMC IO.
1334          This will make the mmc core return data errors. This is
1335          useful to test the error handling in the mmc block device
1336          and to test how the mmc host driver handles retries from
1337          the block device.
1338
1339config FAULT_INJECTION_DEBUG_FS
1340        bool "Debugfs entries for fault-injection capabilities"
1341        depends on FAULT_INJECTION && SYSFS && DEBUG_FS
1342        help
1343          Enable configuration of fault-injection capabilities via debugfs.
1344
1345config FAULT_INJECTION_STACKTRACE_FILTER
1346        bool "stacktrace filter for fault-injection capabilities"
1347        depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
1348        depends on !X86_64
1349        select STACKTRACE
1350        select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND
1351        help
1352          Provide stacktrace filter for fault-injection capabilities
1353
1354config LATENCYTOP
1355        bool "Latency measuring infrastructure"
1356        depends on HAVE_LATENCYTOP_SUPPORT
1357        depends on DEBUG_KERNEL
1358        depends on STACKTRACE_SUPPORT
1359        depends on PROC_FS
1360        select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND
1361        select KALLSYMS
1362        select KALLSYMS_ALL
1363        select STACKTRACE
1364        select SCHEDSTATS
1365        select SCHED_DEBUG
1366        help
1367          Enable this option if you want to use the LatencyTOP tool
1368          to find out which userspace is blocking on what kernel operations.
1369
1370config ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
1371        bool
1372
1373config DEBUG_STRICT_USER_COPY_CHECKS
1374        bool "Strict user copy size checks"
1375        depends on ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
1376        depends on DEBUG_KERNEL && !TRACE_BRANCH_PROFILING
1377        help
1378          Enabling this option turns a certain set of sanity checks for user
1379          copy operations into compile time failures.
1380
1381          The copy_from_user() etc checks are there to help test if there
1382          are sufficient security checks on the length argument of
1383          the copy operation, by having gcc prove that the argument is
1384          within bounds.
1385
1386          If unsure, say N.
1387
1388source kernel/trace/Kconfig
1389
1390menu "Runtime Testing"
1391
1392config LKDTM
1393        tristate "Linux Kernel Dump Test Tool Module"
1394        depends on DEBUG_FS
1395        depends on BLOCK
1396        default n
1397        help
1398        This module enables testing of the different dumping mechanisms by
1399        inducing system failures at predefined crash points.
1400        If you don't need it: say N
1401        Choose M here to compile this code as a module. The module will be
1402        called lkdtm.
1403
1404        Documentation on how to use the module can be found in
1405        Documentation/fault-injection/provoke-crashes.txt
1406
1407config TEST_LIST_SORT
1408        bool "Linked list sorting test"
1409        depends on DEBUG_KERNEL
1410        help
1411          Enable this to turn on 'list_sort()' function test. This test is
1412          executed only once during system boot, so affects only boot time.
1413
1414          If unsure, say N.
1415
1416config KPROBES_SANITY_TEST
1417        bool "Kprobes sanity tests"
1418        depends on DEBUG_KERNEL
1419        depends on KPROBES
1420        default n
1421        help
1422          This option provides for testing basic kprobes functionality on
1423          boot. A sample kprobe, jprobe and kretprobe are inserted and
1424          verified for functionality.
1425
1426          Say N if you are unsure.
1427
1428config BACKTRACE_SELF_TEST
1429        tristate "Self test for the backtrace code"
1430        depends on DEBUG_KERNEL
1431        default n
1432        help
1433          This option provides a kernel module that can be used to test
1434          the kernel stack backtrace code. This option is not useful
1435          for distributions or general kernels, but only for kernel
1436          developers working on architecture code.
1437
1438          Note that if you want to also test saved backtraces, you will
1439          have to enable STACKTRACE as well.
1440
1441          Say N if you are unsure.
1442
1443config RBTREE_TEST
1444        tristate "Red-Black tree test"
1445        depends on m && DEBUG_KERNEL
1446        help
1447          A benchmark measuring the performance of the rbtree library.
1448          Also includes rbtree invariant checks.
1449
1450config INTERVAL_TREE_TEST
1451        tristate "Interval tree test"
1452        depends on m && DEBUG_KERNEL
1453        help
1454          A benchmark measuring the performance of the interval tree library
1455
1456config ATOMIC64_SELFTEST
1457        bool "Perform an atomic64_t self-test at boot"
1458        help
1459          Enable this option to test the atomic64_t functions at boot.
1460
1461          If unsure, say N.
1462
1463config ASYNC_RAID6_TEST
1464        tristate "Self test for hardware accelerated raid6 recovery"
1465        depends on ASYNC_RAID6_RECOV
1466        select ASYNC_MEMCPY
1467        ---help---
1468          This is a one-shot self test that permutes through the
1469          recovery of all the possible two disk failure scenarios for a
1470          N-disk array.  Recovery is performed with the asynchronous
1471          raid6 recovery routines, and will optionally use an offload
1472          engine if one is available.
1473
1474          If unsure, say N.
1475
1476config TEST_STRING_HELPERS
1477        tristate "Test functions located in the string_helpers module at runtime"
1478
1479config TEST_KSTRTOX
1480        tristate "Test kstrto*() family of functions at runtime"
1481
1482endmenu # runtime tests
1483
1484config PROVIDE_OHCI1394_DMA_INIT
1485        bool "Remote debugging over FireWire early on boot"
1486        depends on PCI && X86
1487        help
1488          If you want to debug problems which hang or crash the kernel early
1489          on boot and the crashing machine has a FireWire port, you can use
1490          this feature to remotely access the memory of the crashed machine
1491          over FireWire. This employs remote DMA as part of the OHCI1394
1492          specification which is now the standard for FireWire controllers.
1493
1494          With remote DMA, you can monitor the printk buffer remotely using
1495          firescope and access all memory below 4GB using fireproxy from gdb.
1496          Even controlling a kernel debugger is possible using remote DMA.
1497
1498          Usage:
1499
1500          If ohci1394_dma=early is used as boot parameter, it will initialize
1501          all OHCI1394 controllers which are found in the PCI config space.
1502
1503          As all changes to the FireWire bus such as enabling and disabling
1504          devices cause a bus reset and thereby disable remote DMA for all
1505          devices, be sure to have the cable plugged and FireWire enabled on
1506          the debugging host before booting the debug target for debugging.
1507
1508          This code (~1k) is freed after boot. By then, the firewire stack
1509          in charge of the OHCI-1394 controllers should be used instead.
1510
1511          See Documentation/debugging-via-ohci1394.txt for more information.
1512
1513config FIREWIRE_OHCI_REMOTE_DMA
1514        bool "Remote debugging over FireWire with firewire-ohci"
1515        depends on FIREWIRE_OHCI
1516        help
1517          This option lets you use the FireWire bus for remote debugging
1518          with help of the firewire-ohci driver. It enables unfiltered
1519          remote DMA in firewire-ohci.
1520          See Documentation/debugging-via-ohci1394.txt for more information.
1521
1522          If unsure, say N.
1523
1524config BUILD_DOCSRC
1525        bool "Build targets in Documentation/ tree"
1526        depends on HEADERS_CHECK
1527        help
1528          This option attempts to build objects from the source files in the
1529          kernel Documentation/ tree.
1530
1531          Say N if you are unsure.
1532
1533config DMA_API_DEBUG
1534        bool "Enable debugging of DMA-API usage"
1535        depends on HAVE_DMA_API_DEBUG
1536        help
1537          Enable this option to debug the use of the DMA API by device drivers.
1538          With this option you will be able to detect common bugs in device
1539          drivers like double-freeing of DMA mappings or freeing mappings that
1540          were never allocated.
1541          This option causes a performance degredation.  Use only if you want
1542          to debug device drivers. If unsure, say N.
1543
1544source "samples/Kconfig"
1545
1546source "lib/Kconfig.kgdb"
1547
1548
lxr.linux.no kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.