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