2config PRINTK_TIME
   3        bool "Show timing information on printks"
   4        depends on PRINTK
   5        help
   6          Selecting this option causes timing information to be
   7          included in printk output.  This allows you to measure
   8          the interval between kernel operations, including bootup
   9          operations.  This is useful for identifying long delays
  10          in kernel startup.
  13        bool "Enable __deprecated logic"
  14        default y
  15        help
  16          Enable the __deprecated logic in the kernel build.
  17          Disable this to suppress the "warning: 'foo' is deprecated
  18          (declared at kernel/power/somefile.c:1234)" messages.
  21        bool "Enable __must_check logic"
  22        default y
  23        help
  24          Enable the __must_check logic in the kernel build.  Disable this to
  25          suppress the "warning: ignoring return value of 'foo', declared with
  26          attribute warn_unused_result" messages.
  28config FRAME_WARN
  29        int "Warn for stack frames larger than (needs gcc 4.4)"
  30        range 0 8192
  31        default 1024 if !64BIT
  32        default 2048 if 64BIT
  33        help
  34          Tell gcc to warn at build time for stack frames larger than this.
  35          Setting this too low will cause a lot of warnings.
  36          Setting it to 0 disables the warning.
  37          Requires gcc 4.4
  39config MAGIC_SYSRQ
  40        bool "Magic SysRq key"
  41        depends on !UML
  42        help
  43          If you say Y here, you will have some control over the system even
  44          if the system crashes for example during kernel debugging (e.g., you
  45          will be able to flush the buffer cache to disk, reboot the system
  46          immediately or dump some status information). This is accomplished
  47          by pressing various keys while holding SysRq (Alt+PrintScreen). It
  48          also works on a serial console (on PC hardware at least), if you
  49          send a BREAK and then within 5 seconds a command keypress. The
  50          keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
  51          unless you really know what this hack does.
  54        bool "Enable unused/obsolete exported symbols"
  55        default y if X86
  56        help
  57          Unused but exported symbols make the kernel needlessly bigger.  For
  58          that reason most of these unused exports will soon be removed.  This
  59          option is provided temporarily to provide a transition period in case
  60          some external kernel module needs one of these symbols anyway. If you
  61          encounter such a case in your module, consider if you are actually
  62          using the right API.  (rationale: since nobody in the kernel is using
  63          this in a module, there is a pretty good chance it's actually the
  64          wrong interface to use).  If you really need the symbol, please send a
  65          mail to the linux kernel mailing list mentioning the symbol and why
  66          you really need it, and what the merge plan to the mainline kernel for
  67          your module is.
  69config DEBUG_FS
  70        bool "Debug Filesystem"
  71        depends on SYSFS
  72        help
  73          debugfs is a virtual file system that kernel developers use to put
  74          debugging files into.  Enable this option to be able to read and
  75          write to these files.
  77          If unsure, say N.
  79config HEADERS_CHECK
  80        bool "Run 'make headers_check' when building vmlinux"
  81        depends on !UML
  82        help
  83          This option will extract the user-visible kernel headers whenever
  84          building the kernel, and will run basic sanity checks on them to
  85          ensure that exported files do not attempt to include files which
  86          were not exported, etc.
  88          If you're making modifications to header files which are
  89          relevant for userspace, say 'Y', and check the headers
  90          exported to $(INSTALL_HDR_PATH) (usually 'usr/include' in
  91          your build tree), to make sure they're suitable.
  94        bool "Enable full Section mismatch analysis"
  95        depends on UNDEFINED
  96        # This option is on purpose disabled for now.
  97        # It will be enabled when we are down to a resonable number
  98        # of section mismatch warnings (< 10 for an allyesconfig build)
  99        help
 100          The section mismatch analysis checks if there are illegal
 101          references from one section to another section.
 102          Linux will during link or during runtime drop some sections
 103          and any use of code/data previously in these sections will
 104          most likely result in an oops.
 105          In the code functions and variables are annotated with
 106          __init, __devinit etc. (see full list in include/linux/init.h)
 107          which results in the code/data being placed in specific sections.
 108          The section mismatch analysis is always done after a full
 109          kernel build but enabling this option will in addition
 110          do the following:
 111          - Add the option -fno-inline-functions-called-once to gcc
 112            When inlining a function annotated __init in a non-init
 113            function we would lose the section information and thus
 114            the analysis would not catch the illegal reference.
 115            This option tells gcc to inline less but will also
 116            result in a larger kernel.
 117          - Run the section mismatch analysis for each module/built-in.o
 118            When we run the section mismatch analysis on vmlinux.o we
 119            lose valueble information about where the mismatch was
 120            introduced.
 121            Running the analysis for each module/built-in.o file
 122            will tell where the mismatch happens much closer to the
 123            source. The drawback is that we will report the same
 124            mismatch at least twice.
 125          - Enable verbose reporting from modpost to help solving
 126            the section mismatches reported.
 128config DEBUG_KERNEL
 129        bool "Kernel debugging"
 130        help
 131          Say Y here if you are developing drivers or trying to debug and
 132          identify kernel problems.
 134config DEBUG_SHIRQ
 135        bool "Debug shared IRQ handlers"
 136        depends on DEBUG_KERNEL && GENERIC_HARDIRQS
 137        help
 138          Enable this to generate a spurious interrupt as soon as a shared
 139          interrupt handler is registered, and just before one is deregistered.
 140          Drivers ought to be able to handle interrupts coming in at those
 141          points; some don't and need to be caught.
 144        bool "Detect Soft Lockups"
 145        depends on DEBUG_KERNEL && !S390
 146        default y
 147        help
 148          Say Y here to enable the kernel to detect "soft lockups",
 149          which are bugs that cause the kernel to loop in kernel
 150          mode for more than 10 seconds, without giving other tasks a
 151          chance to run.
 153          When a soft-lockup is detected, the kernel will print the
 154          current stack trace (which you should report), but the
 155          system will stay locked up. This feature has negligible
 156          overhead.
 158          (Note that "hard lockups" are separate type of bugs that
 159           can be detected via the NMI-watchdog, on platforms that
 160           support it.)
 162config SCHED_DEBUG
 163        bool "Collect scheduler debugging info"
 164        depends on DEBUG_KERNEL && PROC_FS
 165        default y
 166        help
 167          If you say Y here, the /proc/sched_debug file will be provided
 168          that can help debug the scheduler. The runtime overhead of this
 169          option is minimal.
 171config SCHEDSTATS
 172        bool "Collect scheduler statistics"
 173        depends on DEBUG_KERNEL && PROC_FS
 174        help
 175          If you say Y here, additional code will be inserted into the
 176          scheduler and related routines to collect statistics about
 177          scheduler behavior and provide them in /proc/schedstat.  These
 178          stats may be useful for both tuning and debugging the scheduler
 179          If you aren't debugging the scheduler or trying to tune a specific
 180          application, you can say N to avoid the very slight overhead
 181          this adds.
 183config TIMER_STATS
 184        bool "Collect kernel timers statistics"
 185        depends on DEBUG_KERNEL && PROC_FS
 186        help
 187          If you say Y here, additional code will be inserted into the
 188          timer routines to collect statistics about kernel timers being
 189          reprogrammed. The statistics can be read from /proc/timer_stats.
 190          The statistics collection is started by writing 1 to /proc/timer_stats,
 191          writing 0 stops it. This feature is useful to collect information
 192          about timer usage patterns in kernel and userspace. This feature
 193          is lightweight if enabled in the kernel config but not activated
 194          (it defaults to deactivated on bootup and will only be activated
 195          if some application like powertop activates it explicitly).
 197config DEBUG_OBJECTS
 198        bool "Debug object operations"
 199        depends on DEBUG_KERNEL
 200        help
 201          If you say Y here, additional code will be inserted into the
 202          kernel to track the life time of various objects and validate
 203          the operations on those objects.
 206        bool "Debug objects selftest"
 207        depends on DEBUG_OBJECTS
 208        help
 209          This enables the selftest of the object debug code.
 212        bool "Debug objects in freed memory"
 213        depends on DEBUG_OBJECTS
 214        help
 215          This enables checks whether a k/v free operation frees an area
 216          which contains an object which has not been deactivated
 217          properly. This can make kmalloc/kfree-intensive workloads
 218          much slower.
 221        bool "Debug timer objects"
 222        depends on DEBUG_OBJECTS
 223        help
 224          If you say Y here, additional code will be inserted into the
 225          timer routines to track the life time of timer objects and
 226          validate the timer operations.
 228config DEBUG_SLAB
 229        bool "Debug slab memory allocations"
 230        depends on DEBUG_KERNEL && SLAB
 231        help
 232          Say Y here to have the kernel do limited verification on memory
 233          allocation as well as poisoning memory on free to catch use of freed
 234          memory. This can make kmalloc/kfree-intensive workloads much slower.
 236config DEBUG_SLAB_LEAK
 237        bool "Memory leak debugging"
 238        depends on DEBUG_SLAB
 240config SLUB_DEBUG_ON
 241        bool "SLUB debugging on by default"
 242        depends on SLUB && SLUB_DEBUG
 243        default n
 244        help
 245          Boot with debugging on by default. SLUB boots by default with
 246          the runtime debug capabilities switched off. Enabling this is
 247          equivalent to specifying the "slub_debug" parameter on boot.
 248          There is no support for more fine grained debug control like
 249          possible with slub_debug=xxx. SLUB debugging may be switched
 250          off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
 251          "slub_debug=-".
 253config SLUB_STATS
 254        default n
 255        bool "Enable SLUB performance statistics"
 256        depends on SLUB && SLUB_DEBUG && SYSFS
 257        help
 258          SLUB statistics are useful to debug SLUBs allocation behavior in
 259          order find ways to optimize the allocator. This should never be
 260          enabled for production use since keeping statistics slows down
 261          the allocator by a few percentage points. The slabinfo command
 262          supports the determination of the most active slabs to figure
 263          out which slabs are relevant to a particular load.
 264          Try running: slabinfo -DA
 266config DEBUG_PREEMPT
 267        bool "Debug preemptible kernel"
 268        depends on DEBUG_KERNEL && PREEMPT && (TRACE_IRQFLAGS_SUPPORT || PPC64)
 269        default y
 270        help
 271          If you say Y here then the kernel will use a debug variant of the
 272          commonly used smp_processor_id() function and will print warnings
 273          if kernel code uses it in a preemption-unsafe way. Also, the kernel
 274          will detect preemption count underflows.
 277        bool "RT Mutex debugging, deadlock detection"
 278        depends on DEBUG_KERNEL && RT_MUTEXES
 279        help
 280         This allows rt mutex semantics violations and rt mutex related
 281         deadlocks (lockups) to be detected and reported automatically.
 283config DEBUG_PI_LIST
 284        bool
 285        default y
 286        depends on DEBUG_RT_MUTEXES
 288config RT_MUTEX_TESTER
 289        bool "Built-in scriptable tester for rt-mutexes"
 290        depends on DEBUG_KERNEL && RT_MUTEXES
 291        help
 292          This option enables a rt-mutex tester.
 295        bool "Spinlock and rw-lock debugging: basic checks"
 296        depends on DEBUG_KERNEL
 297        help
 298          Say Y here and build SMP to catch missing spinlock initialization
 299          and certain other kinds of spinlock errors commonly made.  This is
 300          best used in conjunction with the NMI watchdog so that spinlock
 301          deadlocks are also debuggable.
 303config DEBUG_MUTEXES
 304        bool "Mutex debugging: basic checks"
 305        depends on DEBUG_KERNEL
 306        help
 307         This feature allows mutex semantics violations to be detected and
 308         reported.
 311        bool "Lock debugging: detect incorrect freeing of live locks"
 313        select DEBUG_SPINLOCK
 314        select DEBUG_MUTEXES
 315        select LOCKDEP
 316        help
 317         This feature will check whether any held lock (spinlock, rwlock,
 318         mutex or rwsem) is incorrectly freed by the kernel, via any of the
 319         memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
 320         vfree(), etc.), whether a live lock is incorrectly reinitialized via
 321         spin_lock_init()/mutex_init()/etc., or whether there is any lock
 322         held during task exit.
 324config PROVE_LOCKING
 325        bool "Lock debugging: prove locking correctness"
 327        select LOCKDEP
 328        select DEBUG_SPINLOCK
 329        select DEBUG_MUTEXES
 330        select DEBUG_LOCK_ALLOC
 331        default n
 332        help
 333         This feature enables the kernel to prove that all locking
 334         that occurs in the kernel runtime is mathematically
 335         correct: that under no circumstance could an arbitrary (and
 336         not yet triggered) combination of observed locking
 337         sequences (on an arbitrary number of CPUs, running an
 338         arbitrary number of tasks and interrupt contexts) cause a
 339         deadlock.
 341         In short, this feature enables the kernel to report locking
 342         related deadlocks before they actually occur.
 344         The proof does not depend on how hard and complex a
 345         deadlock scenario would be to trigger: how many
 346         participant CPUs, tasks and irq-contexts would be needed
 347         for it to trigger. The proof also does not depend on
 348         timing: if a race and a resulting deadlock is possible
 349         theoretically (no matter how unlikely the race scenario
 350         is), it will be proven so and will immediately be
 351         reported by the kernel (once the event is observed that
 352         makes the deadlock theoretically possible).
 354         If a deadlock is impossible (i.e. the locking rules, as
 355         observed by the kernel, are mathematically correct), the
 356         kernel reports nothing.
 358         NOTE: this feature can also be enabled for rwlocks, mutexes
 359         and rwsems - in which case all dependencies between these
 360         different locking variants are observed and mapped too, and
 361         the proof of observed correctness is also maintained for an
 362         arbitrary combination of these separate locking variants.
 364         For more details, see Documentation/lockdep-design.txt.
 366config LOCKDEP
 367        bool
 369        select STACKTRACE
 370        select FRAME_POINTER if !X86 && !MIPS
 371        select KALLSYMS
 372        select KALLSYMS_ALL
 374config LOCK_STAT
 375        bool "Lock usage statistics"
 377        select LOCKDEP
 378        select DEBUG_SPINLOCK
 379        select DEBUG_MUTEXES
 380        select DEBUG_LOCK_ALLOC
 381        default n
 382        help
 383         This feature enables tracking lock contention points
 385         For more details, see Documentation/lockstat.txt
 387config DEBUG_LOCKDEP
 388        bool "Lock dependency engine debugging"
 389        depends on DEBUG_KERNEL && LOCKDEP
 390        help
 391          If you say Y here, the lock dependency engine will do
 392          additional runtime checks to debug itself, at the price
 393          of more runtime overhead.
 396        depends on DEBUG_KERNEL
 397        bool
 398        default y
 399        depends on TRACE_IRQFLAGS_SUPPORT
 400        depends on PROVE_LOCKING
 403        bool "Spinlock debugging: sleep-inside-spinlock checking"
 404        depends on DEBUG_KERNEL
 405        help
 406          If you say Y here, various routines which may sleep will become very
 407          noisy if they are called with a spinlock held.
 410        bool "Locking API boot-time self-tests"
 411        depends on DEBUG_KERNEL
 412        help
 413          Say Y here if you want the kernel to run a short self-test during
 414          bootup. The self-test checks whether common types of locking bugs
 415          are detected by debugging mechanisms or not. (if you disable
 416          lock debugging then those bugs wont be detected of course.)
 417          The following locking APIs are covered: spinlocks, rwlocks,
 418          mutexes and rwsems.
 420config STACKTRACE
 421        bool
 422        depends on DEBUG_KERNEL
 423        depends on STACKTRACE_SUPPORT
 425config DEBUG_KOBJECT
 426        bool "kobject debugging"
 427        depends on DEBUG_KERNEL
 428        help
 429          If you say Y here, some extra kobject debugging messages will be sent
 430          to the syslog. 
 432config DEBUG_HIGHMEM
 433        bool "Highmem debugging"
 434        depends on DEBUG_KERNEL && HIGHMEM
 435        help
 436          This options enables addition error checking for high memory systems.
 437          Disable for production systems.
 440        bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EMBEDDED
 441        depends on BUG
 442        depends on ARM || AVR32 || M32R || M68K || SPARC32 || SPARC64 || \
 443                   FRV || SUPERH || GENERIC_BUG || BLACKFIN || MN10300
 444        default !EMBEDDED
 445        help
 446          Say Y here to make BUG() panics output the file name and line number
 447          of the BUG call as well as the EIP and oops trace.  This aids
 448          debugging but costs about 70-100K of memory.
 450config DEBUG_INFO
 451        bool "Compile the kernel with debug info"
 452        depends on DEBUG_KERNEL
 453        help
 454          If you say Y here the resulting kernel image will include
 455          debugging info resulting in a larger kernel image.
 456          This adds debug symbols to the kernel and modules (gcc -g), and
 457          is needed if you intend to use kernel crashdump or binary object
 458          tools like crash, kgdb, LKCD, gdb, etc on the kernel.
 459          Say Y here only if you plan to debug the kernel.
 461          If unsure, say N.
 463config DEBUG_VM
 464        bool "Debug VM"
 465        depends on DEBUG_KERNEL
 466        help
 467          Enable this to turn on extended checks in the virtual-memory system
 468          that may impact performance.
 470          If unsure, say N.
 473        bool "Debug filesystem writers count"
 474        depends on DEBUG_KERNEL
 475        help
 476          Enable this to catch wrong use of the writers count in struct
 477          vfsmount.  This will increase the size of each file struct by
 478          32 bits.
 480          If unsure, say N.
 482config DEBUG_LIST
 483        bool "Debug linked list manipulation"
 484        depends on DEBUG_KERNEL
 485        help
 486          Enable this to turn on extended checks in the linked-list
 487          walking routines.
 489          If unsure, say N.
 491config DEBUG_SG
 492        bool "Debug SG table operations"
 493        depends on DEBUG_KERNEL
 494        help
 495          Enable this to turn on checks on scatter-gather tables. This can
 496          help find problems with drivers that do not properly initialize
 497          their sg tables.
 499          If unsure, say N.
 501config FRAME_POINTER
 502        bool "Compile the kernel with frame pointers"
 503        depends on DEBUG_KERNEL && \
 504                (X86 || CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \
 505                 AVR32 || SUPERH || BLACKFIN || MN10300)
 506        default y if DEBUG_INFO && UML
 507        help
 508          If you say Y here the resulting kernel image will be slightly larger
 509          and slower, but it might give very useful debugging information on
 510          some architectures or if you use external debuggers.
 511          If you don't debug the kernel, you can say N.
 514        bool "Delay each boot printk message by N milliseconds"
 516        help
 517          This build option allows you to read kernel boot messages
 518          by inserting a short delay after each one.  The delay is
 519          specified in milliseconds on the kernel command line,
 520          using "boot_delay=N".
 522          It is likely that you would also need to use "lpj=M" to preset
 523          the "loops per jiffie" value.
 524          See a previous boot log for the "lpj" value to use for your
 525          system, and then set "lpj=M" before setting "boot_delay=N".
 526          NOTE:  Using this option may adversely affect SMP systems.
 527          I.e., processors other than the first one may not boot up.
 528          BOOT_PRINTK_DELAY also may cause DETECT_SOFTLOCKUP to detect
 529          what it believes to be lockup conditions.
 532        tristate "torture tests for RCU"
 533        depends on DEBUG_KERNEL
 534        depends on m
 535        default n
 536        help
 537          This option provides a kernel module that runs torture tests
 538          on the RCU infrastructure.  The kernel module may be built
 539          after the fact on the running kernel to be tested, if desired.
 541          Say M if you want the RCU torture tests to build as a module.
 542          Say N if you are unsure.
 545        bool "Kprobes sanity tests"
 546        depends on DEBUG_KERNEL
 547        depends on KPROBES
 548        default n
 549        help
 550          This option provides for testing basic kprobes functionality on
 551          boot. A sample kprobe, jprobe and kretprobe are inserted and
 552          verified for functionality.
 554          Say N if you are unsure.
 557        tristate "Self test for the backtrace code"
 558        depends on DEBUG_KERNEL
 559        default n
 560        help
 561          This option provides a kernel module that can be used to test
 562          the kernel stack backtrace code. This option is not useful
 563          for distributions or general kernels, but only for kernel
 564          developers working on architecture code.
 566          Say N if you are unsure.
 568config LKDTM
 569        tristate "Linux Kernel Dump Test Tool Module"
 570        depends on DEBUG_KERNEL
 571        depends on KPROBES
 572        depends on BLOCK
 573        default n
 574        help
 575        This module enables testing of the different dumping mechanisms by
 576        inducing system failures at predefined crash points.
 577        If you don't need it: say N
 578        Choose M here to compile this code as a module. The module will be
 579        called lkdtm.
 581        Documentation on how to use the module can be found in
 582        drivers/misc/lkdtm.c
 585        bool "Fault-injection framework"
 586        depends on DEBUG_KERNEL
 587        help
 588          Provide fault-injection framework.
 589          For more details, see Documentation/fault-injection/.
 591config FAILSLAB
 592        bool "Fault-injection capability for kmalloc"
 593        depends on FAULT_INJECTION
 594        help
 595          Provide fault-injection capability for kmalloc.
 597config FAIL_PAGE_ALLOC
 598        bool "Fault-injection capabilitiy for alloc_pages()"
 599        depends on FAULT_INJECTION
 600        help
 601          Provide fault-injection capability for alloc_pages().
 604        bool "Fault-injection capability for disk IO"
 605        depends on FAULT_INJECTION
 606        help
 607          Provide fault-injection capability for disk IO.
 610        bool "Debugfs entries for fault-injection capabilities"
 611        depends on FAULT_INJECTION && SYSFS && DEBUG_FS
 612        help
 613          Enable configuration of fault-injection capabilities via debugfs.
 616        bool "stacktrace filter for fault-injection capabilities"
 618        depends on !X86_64
 619        select STACKTRACE
 620        select FRAME_POINTER
 621        help
 622          Provide stacktrace filter for fault-injection capabilities
 624config LATENCYTOP
 625        bool "Latency measuring infrastructure"
 626        select FRAME_POINTER if !MIPS
 627        select KALLSYMS
 628        select KALLSYMS_ALL
 629        select STACKTRACE
 630        select SCHEDSTATS
 631        select SCHED_DEBUG
 632        depends on HAVE_LATENCYTOP_SUPPORT
 633        help
 634          Enable this option if you want to use the LatencyTOP tool
 635          to find out which userspace is blocking on what kernel operations.
 637config PROVIDE_OHCI1394_DMA_INIT
 638        bool "Remote debugging over FireWire early on boot"
 639        depends on PCI && X86
 640        help
 641          If you want to debug problems which hang or crash the kernel early
 642          on boot and the crashing machine has a FireWire port, you can use
 643          this feature to remotely access the memory of the crashed machine
 644          over FireWire. This employs remote DMA as part of the OHCI1394
 645          specification which is now the standard for FireWire controllers.
 647          With remote DMA, you can monitor the printk buffer remotely using
 648          firescope and access all memory below 4GB using fireproxy from gdb.
 649          Even controlling a kernel debugger is possible using remote DMA.
 651          Usage:
 653          If ohci1394_dma=early is used as boot parameter, it will initialize
 654          all OHCI1394 controllers which are found in the PCI config space.
 656          As all changes to the FireWire bus such as enabling and disabling
 657          devices cause a bus reset and thereby disable remote DMA for all
 658          devices, be sure to have the cable plugged and FireWire enabled on
 659          the debugging host before booting the debug target for debugging.
 661          This code (~1k) is freed after boot. By then, the firewire stack
 662          in charge of the OHCI-1394 controllers should be used instead.
 664          See Documentation/debugging-via-ohci1394.txt for more information.
 667        bool "Remote debugging over FireWire with firewire-ohci"
 668        depends on FIREWIRE_OHCI
 669        help
 670          This option lets you use the FireWire bus for remote debugging
 671          with help of the firewire-ohci driver. It enables unfiltered
 672          remote DMA in firewire-ohci.
 673          See Documentation/debugging-via-ohci1394.txt for more information.
 675          If unsure, say N.
 677source "samples/Kconfig"
 679source "lib/Kconfig.kgdb"
 680 kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.