xref: /openbmc/linux/lib/Kconfig.debug (revision ee8a99bd)
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