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