xref: /openbmc/linux/lib/Kconfig.debug (revision e8e0929d)
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 resonable 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_ENABLE_DEFAULT
302	int "debug_objects bootup default value (0-1)"
303        range 0 1
304        default "1"
305        depends on DEBUG_OBJECTS
306        help
307          Debug objects boot parameter default value
308
309config DEBUG_SLAB
310	bool "Debug slab memory allocations"
311	depends on DEBUG_KERNEL && SLAB && !KMEMCHECK
312	help
313	  Say Y here to have the kernel do limited verification on memory
314	  allocation as well as poisoning memory on free to catch use of freed
315	  memory. This can make kmalloc/kfree-intensive workloads much slower.
316
317config DEBUG_SLAB_LEAK
318	bool "Memory leak debugging"
319	depends on DEBUG_SLAB
320
321config SLUB_DEBUG_ON
322	bool "SLUB debugging on by default"
323	depends on SLUB && SLUB_DEBUG && !KMEMCHECK
324	default n
325	help
326	  Boot with debugging on by default. SLUB boots by default with
327	  the runtime debug capabilities switched off. Enabling this is
328	  equivalent to specifying the "slub_debug" parameter on boot.
329	  There is no support for more fine grained debug control like
330	  possible with slub_debug=xxx. SLUB debugging may be switched
331	  off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
332	  "slub_debug=-".
333
334config SLUB_STATS
335	default n
336	bool "Enable SLUB performance statistics"
337	depends on SLUB && SLUB_DEBUG && SYSFS
338	help
339	  SLUB statistics are useful to debug SLUBs allocation behavior in
340	  order find ways to optimize the allocator. This should never be
341	  enabled for production use since keeping statistics slows down
342	  the allocator by a few percentage points. The slabinfo command
343	  supports the determination of the most active slabs to figure
344	  out which slabs are relevant to a particular load.
345	  Try running: slabinfo -DA
346
347config DEBUG_KMEMLEAK
348	bool "Kernel memory leak detector"
349	depends on DEBUG_KERNEL && EXPERIMENTAL && (X86 || ARM || PPC) && \
350		!MEMORY_HOTPLUG
351	select DEBUG_FS if SYSFS
352	select STACKTRACE if STACKTRACE_SUPPORT
353	select KALLSYMS
354	help
355	  Say Y here if you want to enable the memory leak
356	  detector. The memory allocation/freeing is traced in a way
357	  similar to the Boehm's conservative garbage collector, the
358	  difference being that the orphan objects are not freed but
359	  only shown in /sys/kernel/debug/kmemleak. Enabling this
360	  feature will introduce an overhead to memory
361	  allocations. See Documentation/kmemleak.txt for more
362	  details.
363
364	  Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
365	  of finding leaks due to the slab objects poisoning.
366
367	  In order to access the kmemleak file, debugfs needs to be
368	  mounted (usually at /sys/kernel/debug).
369
370config DEBUG_KMEMLEAK_EARLY_LOG_SIZE
371	int "Maximum kmemleak early log entries"
372	depends on DEBUG_KMEMLEAK
373	range 200 2000
374	default 400
375	help
376	  Kmemleak must track all the memory allocations to avoid
377	  reporting false positives. Since memory may be allocated or
378	  freed before kmemleak is initialised, an early log buffer is
379	  used to store these actions. If kmemleak reports "early log
380	  buffer exceeded", please increase this value.
381
382config DEBUG_KMEMLEAK_TEST
383	tristate "Simple test for the kernel memory leak detector"
384	depends on DEBUG_KMEMLEAK
385	help
386	  Say Y or M here to build a test for the kernel memory leak
387	  detector. This option enables a module that explicitly leaks
388	  memory.
389
390	  If unsure, say N.
391
392config DEBUG_PREEMPT
393	bool "Debug preemptible kernel"
394	depends on DEBUG_KERNEL && PREEMPT && (TRACE_IRQFLAGS_SUPPORT || PPC64)
395	default y
396	help
397	  If you say Y here then the kernel will use a debug variant of the
398	  commonly used smp_processor_id() function and will print warnings
399	  if kernel code uses it in a preemption-unsafe way. Also, the kernel
400	  will detect preemption count underflows.
401
402config DEBUG_RT_MUTEXES
403	bool "RT Mutex debugging, deadlock detection"
404	depends on DEBUG_KERNEL && RT_MUTEXES
405	help
406	 This allows rt mutex semantics violations and rt mutex related
407	 deadlocks (lockups) to be detected and reported automatically.
408
409config DEBUG_PI_LIST
410	bool
411	default y
412	depends on DEBUG_RT_MUTEXES
413
414config RT_MUTEX_TESTER
415	bool "Built-in scriptable tester for rt-mutexes"
416	depends on DEBUG_KERNEL && RT_MUTEXES
417	help
418	  This option enables a rt-mutex tester.
419
420config DEBUG_SPINLOCK
421	bool "Spinlock and rw-lock debugging: basic checks"
422	depends on DEBUG_KERNEL
423	help
424	  Say Y here and build SMP to catch missing spinlock initialization
425	  and certain other kinds of spinlock errors commonly made.  This is
426	  best used in conjunction with the NMI watchdog so that spinlock
427	  deadlocks are also debuggable.
428
429config DEBUG_MUTEXES
430	bool "Mutex debugging: basic checks"
431	depends on DEBUG_KERNEL
432	help
433	 This feature allows mutex semantics violations to be detected and
434	 reported.
435
436config DEBUG_LOCK_ALLOC
437	bool "Lock debugging: detect incorrect freeing of live locks"
438	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
439	select DEBUG_SPINLOCK
440	select DEBUG_MUTEXES
441	select LOCKDEP
442	help
443	 This feature will check whether any held lock (spinlock, rwlock,
444	 mutex or rwsem) is incorrectly freed by the kernel, via any of the
445	 memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
446	 vfree(), etc.), whether a live lock is incorrectly reinitialized via
447	 spin_lock_init()/mutex_init()/etc., or whether there is any lock
448	 held during task exit.
449
450config PROVE_LOCKING
451	bool "Lock debugging: prove locking correctness"
452	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
453	select LOCKDEP
454	select DEBUG_SPINLOCK
455	select DEBUG_MUTEXES
456	select DEBUG_LOCK_ALLOC
457	default n
458	help
459	 This feature enables the kernel to prove that all locking
460	 that occurs in the kernel runtime is mathematically
461	 correct: that under no circumstance could an arbitrary (and
462	 not yet triggered) combination of observed locking
463	 sequences (on an arbitrary number of CPUs, running an
464	 arbitrary number of tasks and interrupt contexts) cause a
465	 deadlock.
466
467	 In short, this feature enables the kernel to report locking
468	 related deadlocks before they actually occur.
469
470	 The proof does not depend on how hard and complex a
471	 deadlock scenario would be to trigger: how many
472	 participant CPUs, tasks and irq-contexts would be needed
473	 for it to trigger. The proof also does not depend on
474	 timing: if a race and a resulting deadlock is possible
475	 theoretically (no matter how unlikely the race scenario
476	 is), it will be proven so and will immediately be
477	 reported by the kernel (once the event is observed that
478	 makes the deadlock theoretically possible).
479
480	 If a deadlock is impossible (i.e. the locking rules, as
481	 observed by the kernel, are mathematically correct), the
482	 kernel reports nothing.
483
484	 NOTE: this feature can also be enabled for rwlocks, mutexes
485	 and rwsems - in which case all dependencies between these
486	 different locking variants are observed and mapped too, and
487	 the proof of observed correctness is also maintained for an
488	 arbitrary combination of these separate locking variants.
489
490	 For more details, see Documentation/lockdep-design.txt.
491
492config LOCKDEP
493	bool
494	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
495	select STACKTRACE
496	select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390
497	select KALLSYMS
498	select KALLSYMS_ALL
499
500config LOCK_STAT
501	bool "Lock usage statistics"
502	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
503	select LOCKDEP
504	select DEBUG_SPINLOCK
505	select DEBUG_MUTEXES
506	select DEBUG_LOCK_ALLOC
507	default n
508	help
509	 This feature enables tracking lock contention points
510
511	 For more details, see Documentation/lockstat.txt
512
513config DEBUG_LOCKDEP
514	bool "Lock dependency engine debugging"
515	depends on DEBUG_KERNEL && LOCKDEP
516	help
517	  If you say Y here, the lock dependency engine will do
518	  additional runtime checks to debug itself, at the price
519	  of more runtime overhead.
520
521config TRACE_IRQFLAGS
522	depends on DEBUG_KERNEL
523	bool
524	default y
525	depends on TRACE_IRQFLAGS_SUPPORT
526	depends on PROVE_LOCKING
527
528config DEBUG_SPINLOCK_SLEEP
529	bool "Spinlock debugging: sleep-inside-spinlock checking"
530	depends on DEBUG_KERNEL
531	help
532	  If you say Y here, various routines which may sleep will become very
533	  noisy if they are called with a spinlock held.
534
535config DEBUG_LOCKING_API_SELFTESTS
536	bool "Locking API boot-time self-tests"
537	depends on DEBUG_KERNEL
538	help
539	  Say Y here if you want the kernel to run a short self-test during
540	  bootup. The self-test checks whether common types of locking bugs
541	  are detected by debugging mechanisms or not. (if you disable
542	  lock debugging then those bugs wont be detected of course.)
543	  The following locking APIs are covered: spinlocks, rwlocks,
544	  mutexes and rwsems.
545
546config STACKTRACE
547	bool
548	depends on STACKTRACE_SUPPORT
549
550config DEBUG_KOBJECT
551	bool "kobject debugging"
552	depends on DEBUG_KERNEL
553	help
554	  If you say Y here, some extra kobject debugging messages will be sent
555	  to the syslog.
556
557config DEBUG_HIGHMEM
558	bool "Highmem debugging"
559	depends on DEBUG_KERNEL && HIGHMEM
560	help
561	  This options enables addition error checking for high memory systems.
562	  Disable for production systems.
563
564config DEBUG_BUGVERBOSE
565	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EMBEDDED
566	depends on BUG
567	depends on ARM || AVR32 || M32R || M68K || SPARC32 || SPARC64 || \
568		   FRV || SUPERH || GENERIC_BUG || BLACKFIN || MN10300
569	default !EMBEDDED
570	help
571	  Say Y here to make BUG() panics output the file name and line number
572	  of the BUG call as well as the EIP and oops trace.  This aids
573	  debugging but costs about 70-100K of memory.
574
575config DEBUG_INFO
576	bool "Compile the kernel with debug info"
577	depends on DEBUG_KERNEL
578	help
579          If you say Y here the resulting kernel image will include
580	  debugging info resulting in a larger kernel image.
581	  This adds debug symbols to the kernel and modules (gcc -g), and
582	  is needed if you intend to use kernel crashdump or binary object
583	  tools like crash, kgdb, LKCD, gdb, etc on the kernel.
584	  Say Y here only if you plan to debug the kernel.
585
586	  If unsure, say N.
587
588config DEBUG_VM
589	bool "Debug VM"
590	depends on DEBUG_KERNEL
591	help
592	  Enable this to turn on extended checks in the virtual-memory system
593          that may impact performance.
594
595	  If unsure, say N.
596
597config DEBUG_VIRTUAL
598	bool "Debug VM translations"
599	depends on DEBUG_KERNEL && X86
600	help
601	  Enable some costly sanity checks in virtual to page code. This can
602	  catch mistakes with virt_to_page() and friends.
603
604	  If unsure, say N.
605
606config DEBUG_NOMMU_REGIONS
607	bool "Debug the global anon/private NOMMU mapping region tree"
608	depends on DEBUG_KERNEL && !MMU
609	help
610	  This option causes the global tree of anonymous and private mapping
611	  regions to be regularly checked for invalid topology.
612
613config DEBUG_WRITECOUNT
614	bool "Debug filesystem writers count"
615	depends on DEBUG_KERNEL
616	help
617	  Enable this to catch wrong use of the writers count in struct
618	  vfsmount.  This will increase the size of each file struct by
619	  32 bits.
620
621	  If unsure, say N.
622
623config DEBUG_MEMORY_INIT
624	bool "Debug memory initialisation" if EMBEDDED
625	default !EMBEDDED
626	help
627	  Enable this for additional checks during memory initialisation.
628	  The sanity checks verify aspects of the VM such as the memory model
629	  and other information provided by the architecture. Verbose
630	  information will be printed at KERN_DEBUG loglevel depending
631	  on the mminit_loglevel= command-line option.
632
633	  If unsure, say Y
634
635config DEBUG_LIST
636	bool "Debug linked list manipulation"
637	depends on DEBUG_KERNEL
638	help
639	  Enable this to turn on extended checks in the linked-list
640	  walking routines.
641
642	  If unsure, say N.
643
644config DEBUG_SG
645	bool "Debug SG table operations"
646	depends on DEBUG_KERNEL
647	help
648	  Enable this to turn on checks on scatter-gather tables. This can
649	  help find problems with drivers that do not properly initialize
650	  their sg tables.
651
652	  If unsure, say N.
653
654config DEBUG_NOTIFIERS
655	bool "Debug notifier call chains"
656	depends on DEBUG_KERNEL
657	help
658	  Enable this to turn on sanity checking for notifier call chains.
659	  This is most useful for kernel developers to make sure that
660	  modules properly unregister themselves from notifier chains.
661	  This is a relatively cheap check but if you care about maximum
662	  performance, say N.
663
664config DEBUG_CREDENTIALS
665	bool "Debug credential management"
666	depends on DEBUG_KERNEL
667	help
668	  Enable this to turn on some debug checking for credential
669	  management.  The additional code keeps track of the number of
670	  pointers from task_structs to any given cred struct, and checks to
671	  see that this number never exceeds the usage count of the cred
672	  struct.
673
674	  Furthermore, if SELinux is enabled, this also checks that the
675	  security pointer in the cred struct is never seen to be invalid.
676
677	  If unsure, say N.
678
679#
680# Select this config option from the architecture Kconfig, if it
681# it is preferred to always offer frame pointers as a config
682# option on the architecture (regardless of KERNEL_DEBUG):
683#
684config ARCH_WANT_FRAME_POINTERS
685	bool
686	help
687
688config FRAME_POINTER
689	bool "Compile the kernel with frame pointers"
690	depends on DEBUG_KERNEL && \
691		(CRIS || M68K || M68KNOMMU || FRV || UML || \
692		 AVR32 || SUPERH || BLACKFIN || MN10300) || \
693		ARCH_WANT_FRAME_POINTERS
694	default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
695	help
696	  If you say Y here the resulting kernel image will be slightly
697	  larger and slower, but it gives very useful debugging information
698	  in case of kernel bugs. (precise oopses/stacktraces/warnings)
699
700config BOOT_PRINTK_DELAY
701	bool "Delay each boot printk message by N milliseconds"
702	depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY
703	help
704	  This build option allows you to read kernel boot messages
705	  by inserting a short delay after each one.  The delay is
706	  specified in milliseconds on the kernel command line,
707	  using "boot_delay=N".
708
709	  It is likely that you would also need to use "lpj=M" to preset
710	  the "loops per jiffie" value.
711	  See a previous boot log for the "lpj" value to use for your
712	  system, and then set "lpj=M" before setting "boot_delay=N".
713	  NOTE:  Using this option may adversely affect SMP systems.
714	  I.e., processors other than the first one may not boot up.
715	  BOOT_PRINTK_DELAY also may cause DETECT_SOFTLOCKUP to detect
716	  what it believes to be lockup conditions.
717
718config RCU_TORTURE_TEST
719	tristate "torture tests for RCU"
720	depends on DEBUG_KERNEL
721	default n
722	help
723	  This option provides a kernel module that runs torture tests
724	  on the RCU infrastructure.  The kernel module may be built
725	  after the fact on the running kernel to be tested, if desired.
726
727	  Say Y here if you want RCU torture tests to be built into
728	  the kernel.
729	  Say M if you want the RCU torture tests to build as a module.
730	  Say N if you are unsure.
731
732config RCU_TORTURE_TEST_RUNNABLE
733	bool "torture tests for RCU runnable by default"
734	depends on RCU_TORTURE_TEST = y
735	default n
736	help
737	  This option provides a way to build the RCU torture tests
738	  directly into the kernel without them starting up at boot
739	  time.  You can use /proc/sys/kernel/rcutorture_runnable
740	  to manually override this setting.  This /proc file is
741	  available only when the RCU torture tests have been built
742	  into the kernel.
743
744	  Say Y here if you want the RCU torture tests to start during
745	  boot (you probably don't).
746	  Say N here if you want the RCU torture tests to start only
747	  after being manually enabled via /proc.
748
749config RCU_CPU_STALL_DETECTOR
750	bool "Check for stalled CPUs delaying RCU grace periods"
751	depends on TREE_RCU || TREE_PREEMPT_RCU
752	default n
753	help
754	  This option causes RCU to printk information on which
755	  CPUs are delaying the current grace period, but only when
756	  the grace period extends for excessive time periods.
757
758	  Say Y if you want RCU to perform such checks.
759
760	  Say N if you are unsure.
761
762config KPROBES_SANITY_TEST
763	bool "Kprobes sanity tests"
764	depends on DEBUG_KERNEL
765	depends on KPROBES
766	default n
767	help
768	  This option provides for testing basic kprobes functionality on
769	  boot. A sample kprobe, jprobe and kretprobe are inserted and
770	  verified for functionality.
771
772	  Say N if you are unsure.
773
774config BACKTRACE_SELF_TEST
775	tristate "Self test for the backtrace code"
776	depends on DEBUG_KERNEL
777	default n
778	help
779	  This option provides a kernel module that can be used to test
780	  the kernel stack backtrace code. This option is not useful
781	  for distributions or general kernels, but only for kernel
782	  developers working on architecture code.
783
784	  Note that if you want to also test saved backtraces, you will
785	  have to enable STACKTRACE as well.
786
787	  Say N if you are unsure.
788
789config DEBUG_BLOCK_EXT_DEVT
790        bool "Force extended block device numbers and spread them"
791	depends on DEBUG_KERNEL
792	depends on BLOCK
793	default n
794	help
795	  BIG FAT WARNING: ENABLING THIS OPTION MIGHT BREAK BOOTING ON
796	  SOME DISTRIBUTIONS.  DO NOT ENABLE THIS UNLESS YOU KNOW WHAT
797	  YOU ARE DOING.  Distros, please enable this and fix whatever
798	  is broken.
799
800	  Conventionally, block device numbers are allocated from
801	  predetermined contiguous area.  However, extended block area
802	  may introduce non-contiguous block device numbers.  This
803	  option forces most block device numbers to be allocated from
804	  the extended space and spreads them to discover kernel or
805	  userland code paths which assume predetermined contiguous
806	  device number allocation.
807
808	  Note that turning on this debug option shuffles all the
809	  device numbers for all IDE and SCSI devices including libata
810	  ones, so root partition specified using device number
811	  directly (via rdev or root=MAJ:MIN) won't work anymore.
812	  Textual device names (root=/dev/sdXn) will continue to work.
813
814	  Say N if you are unsure.
815
816config DEBUG_FORCE_WEAK_PER_CPU
817	bool "Force weak per-cpu definitions"
818	depends on DEBUG_KERNEL
819	help
820	  s390 and alpha require percpu variables in modules to be
821	  defined weak to work around addressing range issue which
822	  puts the following two restrictions on percpu variable
823	  definitions.
824
825	  1. percpu symbols must be unique whether static or not
826	  2. percpu variables can't be defined inside a function
827
828	  To ensure that generic code follows the above rules, this
829	  option forces all percpu variables to be defined as weak.
830
831config LKDTM
832	tristate "Linux Kernel Dump Test Tool Module"
833	depends on DEBUG_KERNEL
834	depends on KPROBES
835	depends on BLOCK
836	default n
837	help
838	This module enables testing of the different dumping mechanisms by
839	inducing system failures at predefined crash points.
840	If you don't need it: say N
841	Choose M here to compile this code as a module. The module will be
842	called lkdtm.
843
844	Documentation on how to use the module can be found in
845	drivers/misc/lkdtm.c
846
847config FAULT_INJECTION
848	bool "Fault-injection framework"
849	depends on DEBUG_KERNEL
850	help
851	  Provide fault-injection framework.
852	  For more details, see Documentation/fault-injection/.
853
854config FAILSLAB
855	bool "Fault-injection capability for kmalloc"
856	depends on FAULT_INJECTION
857	depends on SLAB || SLUB
858	help
859	  Provide fault-injection capability for kmalloc.
860
861config FAIL_PAGE_ALLOC
862	bool "Fault-injection capabilitiy for alloc_pages()"
863	depends on FAULT_INJECTION
864	help
865	  Provide fault-injection capability for alloc_pages().
866
867config FAIL_MAKE_REQUEST
868	bool "Fault-injection capability for disk IO"
869	depends on FAULT_INJECTION && BLOCK
870	help
871	  Provide fault-injection capability for disk IO.
872
873config FAIL_IO_TIMEOUT
874	bool "Faul-injection capability for faking disk interrupts"
875	depends on FAULT_INJECTION && BLOCK
876	help
877	  Provide fault-injection capability on end IO handling. This
878	  will make the block layer "forget" an interrupt as configured,
879	  thus exercising the error handling.
880
881	  Only works with drivers that use the generic timeout handling,
882	  for others it wont do anything.
883
884config FAULT_INJECTION_DEBUG_FS
885	bool "Debugfs entries for fault-injection capabilities"
886	depends on FAULT_INJECTION && SYSFS && DEBUG_FS
887	help
888	  Enable configuration of fault-injection capabilities via debugfs.
889
890config FAULT_INJECTION_STACKTRACE_FILTER
891	bool "stacktrace filter for fault-injection capabilities"
892	depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
893	depends on !X86_64
894	select STACKTRACE
895	select FRAME_POINTER if !PPC && !S390
896	help
897	  Provide stacktrace filter for fault-injection capabilities
898
899config LATENCYTOP
900	bool "Latency measuring infrastructure"
901	select FRAME_POINTER if !MIPS && !PPC && !S390
902	select KALLSYMS
903	select KALLSYMS_ALL
904	select STACKTRACE
905	select SCHEDSTATS
906	select SCHED_DEBUG
907	depends on HAVE_LATENCYTOP_SUPPORT
908	help
909	  Enable this option if you want to use the LatencyTOP tool
910	  to find out which userspace is blocking on what kernel operations.
911
912config SYSCTL_SYSCALL_CHECK
913	bool "Sysctl checks"
914	depends on SYSCTL_SYSCALL
915	---help---
916	  sys_sysctl uses binary paths that have been found challenging
917	  to properly maintain and use. This enables checks that help
918	  you to keep things correct.
919
920source mm/Kconfig.debug
921source kernel/trace/Kconfig
922
923config PROVIDE_OHCI1394_DMA_INIT
924	bool "Remote debugging over FireWire early on boot"
925	depends on PCI && X86
926	help
927	  If you want to debug problems which hang or crash the kernel early
928	  on boot and the crashing machine has a FireWire port, you can use
929	  this feature to remotely access the memory of the crashed machine
930	  over FireWire. This employs remote DMA as part of the OHCI1394
931	  specification which is now the standard for FireWire controllers.
932
933	  With remote DMA, you can monitor the printk buffer remotely using
934	  firescope and access all memory below 4GB using fireproxy from gdb.
935	  Even controlling a kernel debugger is possible using remote DMA.
936
937	  Usage:
938
939	  If ohci1394_dma=early is used as boot parameter, it will initialize
940	  all OHCI1394 controllers which are found in the PCI config space.
941
942	  As all changes to the FireWire bus such as enabling and disabling
943	  devices cause a bus reset and thereby disable remote DMA for all
944	  devices, be sure to have the cable plugged and FireWire enabled on
945	  the debugging host before booting the debug target for debugging.
946
947	  This code (~1k) is freed after boot. By then, the firewire stack
948	  in charge of the OHCI-1394 controllers should be used instead.
949
950	  See Documentation/debugging-via-ohci1394.txt for more information.
951
952config FIREWIRE_OHCI_REMOTE_DMA
953	bool "Remote debugging over FireWire with firewire-ohci"
954	depends on FIREWIRE_OHCI
955	help
956	  This option lets you use the FireWire bus for remote debugging
957	  with help of the firewire-ohci driver. It enables unfiltered
958	  remote DMA in firewire-ohci.
959	  See Documentation/debugging-via-ohci1394.txt for more information.
960
961	  If unsure, say N.
962
963config BUILD_DOCSRC
964	bool "Build targets in Documentation/ tree"
965	depends on HEADERS_CHECK
966	help
967	  This option attempts to build objects from the source files in the
968	  kernel Documentation/ tree.
969
970	  Say N if you are unsure.
971
972config DYNAMIC_DEBUG
973	bool "Enable dynamic printk() support"
974	default n
975	depends on PRINTK
976	depends on DEBUG_FS
977	help
978
979	  Compiles debug level messages into the kernel, which would not
980	  otherwise be available at runtime. These messages can then be
981	  enabled/disabled based on various levels of scope - per source file,
982	  function, module, format string, and line number. This mechanism
983	  implicitly enables all pr_debug() and dev_dbg() calls. The impact of
984	  this compile option is a larger kernel text size of about 2%.
985
986	  Usage:
987
988	  Dynamic debugging is controlled via the 'dynamic_debug/ddebug' file,
989	  which is contained in the 'debugfs' filesystem. Thus, the debugfs
990	  filesystem must first be mounted before making use of this feature.
991	  We refer the control file as: <debugfs>/dynamic_debug/ddebug. This
992	  file contains a list of the debug statements that can be enabled. The
993	  format for each line of the file is:
994
995		filename:lineno [module]function flags format
996
997	  filename : source file of the debug statement
998	  lineno : line number of the debug statement
999	  module : module that contains the debug statement
1000	  function : function that contains the debug statement
1001          flags : 'p' means the line is turned 'on' for printing
1002          format : the format used for the debug statement
1003
1004	  From a live system:
1005
1006		nullarbor:~ # cat <debugfs>/dynamic_debug/ddebug
1007		# filename:lineno [module]function flags format
1008		fs/aio.c:222 [aio]__put_ioctx - "__put_ioctx:\040freeing\040%p\012"
1009		fs/aio.c:248 [aio]ioctx_alloc - "ENOMEM:\040nr_events\040too\040high\012"
1010		fs/aio.c:1770 [aio]sys_io_cancel - "calling\040cancel\012"
1011
1012	  Example usage:
1013
1014		// enable the message at line 1603 of file svcsock.c
1015		nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
1016						<debugfs>/dynamic_debug/ddebug
1017
1018		// enable all the messages in file svcsock.c
1019		nullarbor:~ # echo -n 'file svcsock.c +p' >
1020						<debugfs>/dynamic_debug/ddebug
1021
1022		// enable all the messages in the NFS server module
1023		nullarbor:~ # echo -n 'module nfsd +p' >
1024						<debugfs>/dynamic_debug/ddebug
1025
1026		// enable all 12 messages in the function svc_process()
1027		nullarbor:~ # echo -n 'func svc_process +p' >
1028						<debugfs>/dynamic_debug/ddebug
1029
1030		// disable all 12 messages in the function svc_process()
1031		nullarbor:~ # echo -n 'func svc_process -p' >
1032						<debugfs>/dynamic_debug/ddebug
1033
1034	  See Documentation/dynamic-debug-howto.txt for additional information.
1035
1036config DMA_API_DEBUG
1037	bool "Enable debugging of DMA-API usage"
1038	depends on HAVE_DMA_API_DEBUG
1039	help
1040	  Enable this option to debug the use of the DMA API by device drivers.
1041	  With this option you will be able to detect common bugs in device
1042	  drivers like double-freeing of DMA mappings or freeing mappings that
1043	  were never allocated.
1044	  This option causes a performance degredation.  Use only if you want
1045	  to debug device drivers. If unsure, say N.
1046
1047source "samples/Kconfig"
1048
1049source "lib/Kconfig.kgdb"
1050
1051source "lib/Kconfig.kmemcheck"
1052