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