📄 kconfig.debug
字号:
If a deadlock is impossible (i.e. the locking rules, as observed by the kernel, are mathematically correct), the kernel reports nothing. NOTE: this feature can also be enabled for rwlocks, mutexes and rwsems - in which case all dependencies between these different locking variants are observed and mapped too, and the proof of observed correctness is also maintained for an arbitrary combination of these separate locking variants. For more details, see Documentation/lockdep-design.txt.config LOCKDEP bool depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT select STACKTRACE select FRAME_POINTER if !X86 && !MIPS && !PPC select KALLSYMS select KALLSYMS_ALLconfig LOCK_STAT bool "Lock usage statistics" depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT select LOCKDEP select DEBUG_SPINLOCK select DEBUG_MUTEXES select DEBUG_LOCK_ALLOC default n help This feature enables tracking lock contention points For more details, see Documentation/lockstat.txtconfig DEBUG_LOCKDEP bool "Lock dependency engine debugging" depends on DEBUG_KERNEL && LOCKDEP help If you say Y here, the lock dependency engine will do additional runtime checks to debug itself, at the price of more runtime overhead.config TRACE_IRQFLAGS depends on DEBUG_KERNEL bool default y depends on TRACE_IRQFLAGS_SUPPORT depends on PROVE_LOCKINGconfig DEBUG_SPINLOCK_SLEEP bool "Spinlock debugging: sleep-inside-spinlock checking" depends on DEBUG_KERNEL help If you say Y here, various routines which may sleep will become very noisy if they are called with a spinlock held.config DEBUG_LOCKING_API_SELFTESTS bool "Locking API boot-time self-tests" depends on DEBUG_KERNEL help Say Y here if you want the kernel to run a short self-test during bootup. The self-test checks whether common types of locking bugs are detected by debugging mechanisms or not. (if you disable lock debugging then those bugs wont be detected of course.) The following locking APIs are covered: spinlocks, rwlocks, mutexes and rwsems.config STACKTRACE bool depends on STACKTRACE_SUPPORTconfig DEBUG_KOBJECT bool "kobject debugging" depends on DEBUG_KERNEL help If you say Y here, some extra kobject debugging messages will be sent to the syslog. config DEBUG_HIGHMEM bool "Highmem debugging" depends on DEBUG_KERNEL && HIGHMEM help This options enables addition error checking for high memory systems. Disable for production systems.config DEBUG_BUGVERBOSE bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EMBEDDED depends on BUG depends on ARM || AVR32 || M32R || M68K || SPARC32 || SPARC64 || \ FRV || SUPERH || GENERIC_BUG || BLACKFIN || MN10300 default !EMBEDDED help Say Y here to make BUG() panics output the file name and line number of the BUG call as well as the EIP and oops trace. This aids debugging but costs about 70-100K of memory.config DEBUG_INFO bool "Compile the kernel with debug info" depends on DEBUG_KERNEL help If you say Y here the resulting kernel image will include debugging info resulting in a larger kernel image. This adds debug symbols to the kernel and modules (gcc -g), and is needed if you intend to use kernel crashdump or binary object tools like crash, kgdb, LKCD, gdb, etc on the kernel. Say Y here only if you plan to debug the kernel. If unsure, say N.config DEBUG_VM bool "Debug VM" depends on DEBUG_KERNEL help Enable this to turn on extended checks in the virtual-memory system that may impact performance. If unsure, say N.config DEBUG_WRITECOUNT bool "Debug filesystem writers count" depends on DEBUG_KERNEL help Enable this to catch wrong use of the writers count in struct vfsmount. This will increase the size of each file struct by 32 bits. If unsure, say N.config DEBUG_MEMORY_INIT bool "Debug memory initialisation" if EMBEDDED default !EMBEDDED help Enable this for additional checks during memory initialisation. The sanity checks verify aspects of the VM such as the memory model and other information provided by the architecture. Verbose information will be printed at KERN_DEBUG loglevel depending on the mminit_loglevel= command-line option. If unsure, say Yconfig DEBUG_LIST bool "Debug linked list manipulation" depends on DEBUG_KERNEL help Enable this to turn on extended checks in the linked-list walking routines. If unsure, say N.config DEBUG_SG bool "Debug SG table operations" depends on DEBUG_KERNEL help Enable this to turn on checks on scatter-gather tables. This can help find problems with drivers that do not properly initialize their sg tables. If unsure, say N.config FRAME_POINTER bool "Compile the kernel with frame pointers" depends on DEBUG_KERNEL && \ (X86 || CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \ AVR32 || SUPERH || BLACKFIN || MN10300) default y if DEBUG_INFO && UML help If you say Y here the resulting kernel image will be slightly larger and slower, but it might give very useful debugging information on some architectures or if you use external debuggers. If you don't debug the kernel, you can say N.config BOOT_PRINTK_DELAY bool "Delay each boot printk message by N milliseconds" depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY help This build option allows you to read kernel boot messages by inserting a short delay after each one. The delay is specified in milliseconds on the kernel command line, using "boot_delay=N". It is likely that you would also need to use "lpj=M" to preset the "loops per jiffie" value. See a previous boot log for the "lpj" value to use for your system, and then set "lpj=M" before setting "boot_delay=N". NOTE: Using this option may adversely affect SMP systems. I.e., processors other than the first one may not boot up. BOOT_PRINTK_DELAY also may cause DETECT_SOFTLOCKUP to detect what it believes to be lockup conditions.config RCU_TORTURE_TEST tristate "torture tests for RCU" depends on DEBUG_KERNEL default n help This option provides a kernel module that runs torture tests on the RCU infrastructure. The kernel module may be built after the fact on the running kernel to be tested, if desired. Say Y here if you want RCU torture tests to be built into the kernel. Say M if you want the RCU torture tests to build as a module. Say N if you are unsure.config RCU_TORTURE_TEST_RUNNABLE bool "torture tests for RCU runnable by default" depends on RCU_TORTURE_TEST = y default n help This option provides a way to build the RCU torture tests directly into the kernel without them starting up at boot time. You can use /proc/sys/kernel/rcutorture_runnable to manually override this setting. This /proc file is available only when the RCU torture tests have been built into the kernel. Say Y here if you want the RCU torture tests to start during boot (you probably don't). Say N here if you want the RCU torture tests to start only after being manually enabled via /proc.config KPROBES_SANITY_TEST bool "Kprobes sanity tests" depends on DEBUG_KERNEL depends on KPROBES default n help This option provides for testing basic kprobes functionality on boot. A sample kprobe, jprobe and kretprobe are inserted and verified for functionality. Say N if you are unsure.config BACKTRACE_SELF_TEST tristate "Self test for the backtrace code" depends on DEBUG_KERNEL default n help This option provides a kernel module that can be used to test the kernel stack backtrace code. This option is not useful for distributions or general kernels, but only for kernel developers working on architecture code. Note that if you want to also test saved backtraces, you will have to enable STACKTRACE as well. Say N if you are unsure.config LKDTM tristate "Linux Kernel Dump Test Tool Module" depends on DEBUG_KERNEL depends on KPROBES depends on BLOCK default n help This module enables testing of the different dumping mechanisms by inducing system failures at predefined crash points. If you don't need it: say N Choose M here to compile this code as a module. The module will be called lkdtm. Documentation on how to use the module can be found in drivers/misc/lkdtm.cconfig FAULT_INJECTION bool "Fault-injection framework" depends on DEBUG_KERNEL help Provide fault-injection framework. For more details, see Documentation/fault-injection/.config FAILSLAB bool "Fault-injection capability for kmalloc" depends on FAULT_INJECTION help Provide fault-injection capability for kmalloc.config FAIL_PAGE_ALLOC bool "Fault-injection capabilitiy for alloc_pages()" depends on FAULT_INJECTION help Provide fault-injection capability for alloc_pages().config FAIL_MAKE_REQUEST bool "Fault-injection capability for disk IO" depends on FAULT_INJECTION help Provide fault-injection capability for disk IO.config FAULT_INJECTION_DEBUG_FS bool "Debugfs entries for fault-injection capabilities" depends on FAULT_INJECTION && SYSFS && DEBUG_FS help Enable configuration of fault-injection capabilities via debugfs.config FAULT_INJECTION_STACKTRACE_FILTER bool "stacktrace filter for fault-injection capabilities" depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT depends on !X86_64 select STACKTRACE select FRAME_POINTER if !PPC help Provide stacktrace filter for fault-injection capabilitiesconfig LATENCYTOP bool "Latency measuring infrastructure" select FRAME_POINTER if !MIPS && !PPC select KALLSYMS select KALLSYMS_ALL select STACKTRACE select SCHEDSTATS select SCHED_DEBUG depends on HAVE_LATENCYTOP_SUPPORT help Enable this option if you want to use the LatencyTOP tool to find out which userspace is blocking on what kernel operations.config SYSCTL_SYSCALL_CHECK bool "Sysctl checks" depends on SYSCTL_SYSCALL ---help--- sys_sysctl uses binary paths that have been found challenging to properly maintain and use. This enables checks that help you to keep things correct.source kernel/trace/Kconfigconfig PROVIDE_OHCI1394_DMA_INIT bool "Remote debugging over FireWire early on boot" depends on PCI && X86 help If you want to debug problems which hang or crash the kernel early on boot and the crashing machine has a FireWire port, you can use this feature to remotely access the memory of the crashed machine over FireWire. This employs remote DMA as part of the OHCI1394 specification which is now the standard for FireWire controllers. With remote DMA, you can monitor the printk buffer remotely using firescope and access all memory below 4GB using fireproxy from gdb. Even controlling a kernel debugger is possible using remote DMA. Usage: If ohci1394_dma=early is used as boot parameter, it will initialize all OHCI1394 controllers which are found in the PCI config space. As all changes to the FireWire bus such as enabling and disabling devices cause a bus reset and thereby disable remote DMA for all devices, be sure to have the cable plugged and FireWire enabled on the debugging host before booting the debug target for debugging. This code (~1k) is freed after boot. By then, the firewire stack in charge of the OHCI-1394 controllers should be used instead. See Documentation/debugging-via-ohci1394.txt for more information.config FIREWIRE_OHCI_REMOTE_DMA bool "Remote debugging over FireWire with firewire-ohci" depends on FIREWIRE_OHCI help This option lets you use the FireWire bus for remote debugging with help of the firewire-ohci driver. It enables unfiltered remote DMA in firewire-ohci. See Documentation/debugging-via-ohci1394.txt for more information. If unsure, say N.menuconfig BUILD_DOCSRC bool "Build targets in Documentation/ tree" depends on HEADERS_CHECK help This option attempts to build objects from the source files in the kernel Documentation/ tree. Say N if you are unsure.source "samples/Kconfig"source "lib/Kconfig.kgdb"
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -