Version:  2.0.40 2.2.26 2.4.37 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 4.0 4.1 4.2

Linux/arch/x86/Kconfig.debug

  1 menu "Kernel hacking"
  2 
  3 config TRACE_IRQFLAGS_SUPPORT
  4         def_bool y
  5 
  6 source "lib/Kconfig.debug"
  7 
  8 config STRICT_DEVMEM
  9         bool "Filter access to /dev/mem"
 10         ---help---
 11           If this option is disabled, you allow userspace (root) access to all
 12           of memory, including kernel and userspace memory. Accidental
 13           access to this is obviously disastrous, but specific access can
 14           be used by people debugging the kernel. Note that with PAT support
 15           enabled, even in this case there are restrictions on /dev/mem
 16           use due to the cache aliasing requirements.
 17 
 18           If this option is switched on, the /dev/mem file only allows
 19           userspace access to PCI space and the BIOS code and data regions.
 20           This is sufficient for dosemu and X and all common users of
 21           /dev/mem.
 22 
 23           If in doubt, say Y.
 24 
 25 config X86_VERBOSE_BOOTUP
 26         bool "Enable verbose x86 bootup info messages"
 27         default y
 28         ---help---
 29           Enables the informational output from the decompression stage
 30           (e.g. bzImage) of the boot. If you disable this you will still
 31           see errors. Disable this if you want silent bootup.
 32 
 33 config EARLY_PRINTK
 34         bool "Early printk" if EXPERT
 35         default y
 36         ---help---
 37           Write kernel log output directly into the VGA buffer or to a serial
 38           port.
 39 
 40           This is useful for kernel debugging when your machine crashes very
 41           early before the console code is initialized. For normal operation
 42           it is not recommended because it looks ugly and doesn't cooperate
 43           with klogd/syslogd or the X server. You should normally N here,
 44           unless you want to debug such a crash.
 45 
 46 config EARLY_PRINTK_DBGP
 47         bool "Early printk via EHCI debug port"
 48         depends on EARLY_PRINTK && PCI
 49         ---help---
 50           Write kernel log output directly into the EHCI debug port.
 51 
 52           This is useful for kernel debugging when your machine crashes very
 53           early before the console code is initialized. For normal operation
 54           it is not recommended because it looks ugly and doesn't cooperate
 55           with klogd/syslogd or the X server. You should normally N here,
 56           unless you want to debug such a crash. You need usb debug device.
 57 
 58 config EARLY_PRINTK_EFI
 59         bool "Early printk via the EFI framebuffer"
 60         depends on EFI && EARLY_PRINTK
 61         select FONT_SUPPORT
 62         ---help---
 63           Write kernel log output directly into the EFI framebuffer.
 64 
 65           This is useful for kernel debugging when your machine crashes very
 66           early before the console code is initialized.
 67 
 68 config X86_PTDUMP
 69         bool "Export kernel pagetable layout to userspace via debugfs"
 70         depends on DEBUG_KERNEL
 71         select DEBUG_FS
 72         ---help---
 73           Say Y here if you want to show the kernel pagetable layout in a
 74           debugfs file. This information is only useful for kernel developers
 75           who are working in architecture specific areas of the kernel.
 76           It is probably not a good idea to enable this feature in a production
 77           kernel.
 78           If in doubt, say "N"
 79 
 80 config EFI_PGT_DUMP
 81         bool "Dump the EFI pagetable"
 82         depends on EFI && X86_PTDUMP
 83         ---help---
 84           Enable this if you want to dump the EFI page table before
 85           enabling virtual mode. This can be used to debug miscellaneous
 86           issues with the mapping of the EFI runtime regions into that
 87           table.
 88 
 89 config DEBUG_RODATA
 90         bool "Write protect kernel read-only data structures"
 91         default y
 92         depends on DEBUG_KERNEL
 93         ---help---
 94           Mark the kernel read-only data as write-protected in the pagetables,
 95           in order to catch accidental (and incorrect) writes to such const
 96           data. This is recommended so that we can catch kernel bugs sooner.
 97           If in doubt, say "Y".
 98 
 99 config DEBUG_RODATA_TEST
100         bool "Testcase for the DEBUG_RODATA feature"
101         depends on DEBUG_RODATA
102         default y
103         ---help---
104           This option enables a testcase for the DEBUG_RODATA
105           feature as well as for the change_page_attr() infrastructure.
106           If in doubt, say "N"
107 
108 config DEBUG_SET_MODULE_RONX
109         bool "Set loadable kernel module data as NX and text as RO"
110         depends on MODULES
111         ---help---
112           This option helps catch unintended modifications to loadable
113           kernel module's text and read-only data. It also prevents execution
114           of module data. Such protection may interfere with run-time code
115           patching and dynamic kernel tracing - and they might also protect
116           against certain classes of kernel exploits.
117           If in doubt, say "N".
118 
119 config DEBUG_NX_TEST
120         tristate "Testcase for the NX non-executable stack feature"
121         depends on DEBUG_KERNEL && m
122         ---help---
123           This option enables a testcase for the CPU NX capability
124           and the software setup of this feature.
125           If in doubt, say "N"
126 
127 config DOUBLEFAULT
128         default y
129         bool "Enable doublefault exception handler" if EXPERT
130         ---help---
131           This option allows trapping of rare doublefault exceptions that
132           would otherwise cause a system to silently reboot. Disabling this
133           option saves about 4k and might cause you much additional grey
134           hair.
135 
136 config DEBUG_TLBFLUSH
137         bool "Set upper limit of TLB entries to flush one-by-one"
138         depends on DEBUG_KERNEL
139         ---help---
140 
141         X86-only for now.
142 
143         This option allows the user to tune the amount of TLB entries the
144         kernel flushes one-by-one instead of doing a full TLB flush. In
145         certain situations, the former is cheaper. This is controlled by the
146         tlb_flushall_shift knob under /sys/kernel/debug/x86. If you set it
147         to -1, the code flushes the whole TLB unconditionally. Otherwise,
148         for positive values of it, the kernel will use single TLB entry
149         invalidating instructions according to the following formula:
150 
151         flush_entries <= active_tlb_entries / 2^tlb_flushall_shift
152 
153         If in doubt, say "N".
154 
155 config IOMMU_DEBUG
156         bool "Enable IOMMU debugging"
157         depends on GART_IOMMU && DEBUG_KERNEL
158         depends on X86_64
159         ---help---
160           Force the IOMMU to on even when you have less than 4GB of
161           memory and add debugging code. On overflow always panic. And
162           allow to enable IOMMU leak tracing. Can be disabled at boot
163           time with iommu=noforce. This will also enable scatter gather
164           list merging.  Currently not recommended for production
165           code. When you use it make sure you have a big enough
166           IOMMU/AGP aperture.  Most of the options enabled by this can
167           be set more finegrained using the iommu= command line
168           options. See Documentation/x86/x86_64/boot-options.txt for more
169           details.
170 
171 config IOMMU_STRESS
172         bool "Enable IOMMU stress-test mode"
173         ---help---
174           This option disables various optimizations in IOMMU related
175           code to do real stress testing of the IOMMU code. This option
176           will cause a performance drop and should only be enabled for
177           testing.
178 
179 config IOMMU_LEAK
180         bool "IOMMU leak tracing"
181         depends on IOMMU_DEBUG && DMA_API_DEBUG
182         ---help---
183           Add a simple leak tracer to the IOMMU code. This is useful when you
184           are debugging a buggy device driver that leaks IOMMU mappings.
185 
186 config HAVE_MMIOTRACE_SUPPORT
187         def_bool y
188 
189 config X86_DECODER_SELFTEST
190         bool "x86 instruction decoder selftest"
191         depends on DEBUG_KERNEL && KPROBES
192         depends on !COMPILE_TEST
193         ---help---
194          Perform x86 instruction decoder selftests at build time.
195          This option is useful for checking the sanity of x86 instruction
196          decoder code.
197          If unsure, say "N".
198 
199 #
200 # IO delay types:
201 #
202 
203 config IO_DELAY_TYPE_0X80
204         int
205         default "0"
206 
207 config IO_DELAY_TYPE_0XED
208         int
209         default "1"
210 
211 config IO_DELAY_TYPE_UDELAY
212         int
213         default "2"
214 
215 config IO_DELAY_TYPE_NONE
216         int
217         default "3"
218 
219 choice
220         prompt "IO delay type"
221         default IO_DELAY_0X80
222 
223 config IO_DELAY_0X80
224         bool "port 0x80 based port-IO delay [recommended]"
225         ---help---
226           This is the traditional Linux IO delay used for in/out_p.
227           It is the most tested hence safest selection here.
228 
229 config IO_DELAY_0XED
230         bool "port 0xed based port-IO delay"
231         ---help---
232           Use port 0xed as the IO delay. This frees up port 0x80 which is
233           often used as a hardware-debug port.
234 
235 config IO_DELAY_UDELAY
236         bool "udelay based port-IO delay"
237         ---help---
238           Use udelay(2) as the IO delay method. This provides the delay
239           while not having any side-effect on the IO port space.
240 
241 config IO_DELAY_NONE
242         bool "no port-IO delay"
243         ---help---
244           No port-IO delay. Will break on old boxes that require port-IO
245           delay for certain operations. Should work on most new machines.
246 
247 endchoice
248 
249 if IO_DELAY_0X80
250 config DEFAULT_IO_DELAY_TYPE
251         int
252         default IO_DELAY_TYPE_0X80
253 endif
254 
255 if IO_DELAY_0XED
256 config DEFAULT_IO_DELAY_TYPE
257         int
258         default IO_DELAY_TYPE_0XED
259 endif
260 
261 if IO_DELAY_UDELAY
262 config DEFAULT_IO_DELAY_TYPE
263         int
264         default IO_DELAY_TYPE_UDELAY
265 endif
266 
267 if IO_DELAY_NONE
268 config DEFAULT_IO_DELAY_TYPE
269         int
270         default IO_DELAY_TYPE_NONE
271 endif
272 
273 config DEBUG_BOOT_PARAMS
274         bool "Debug boot parameters"
275         depends on DEBUG_KERNEL
276         depends on DEBUG_FS
277         ---help---
278           This option will cause struct boot_params to be exported via debugfs.
279 
280 config CPA_DEBUG
281         bool "CPA self-test code"
282         depends on DEBUG_KERNEL
283         ---help---
284           Do change_page_attr() self-tests every 30 seconds.
285 
286 config OPTIMIZE_INLINING
287         bool "Allow gcc to uninline functions marked 'inline'"
288         ---help---
289           This option determines if the kernel forces gcc to inline the functions
290           developers have marked 'inline'. Doing so takes away freedom from gcc to
291           do what it thinks is best, which is desirable for the gcc 3.x series of
292           compilers. The gcc 4.x series have a rewritten inlining algorithm and
293           enabling this option will generate a smaller kernel there. Hopefully
294           this algorithm is so good that allowing gcc 4.x and above to make the
295           decision will become the default in the future. Until then this option
296           is there to test gcc for this.
297 
298           If unsure, say N.
299 
300 config DEBUG_ENTRY
301         bool "Debug low-level entry code"
302         depends on DEBUG_KERNEL
303         ---help---
304           This option enables sanity checks in x86's low-level entry code.
305           Some of these sanity checks may slow down kernel entries and
306           exits or otherwise impact performance.
307 
308           This is currently used to help test NMI code.
309 
310           If unsure, say N.
311 
312 config DEBUG_NMI_SELFTEST
313         bool "NMI Selftest"
314         depends on DEBUG_KERNEL && X86_LOCAL_APIC
315         ---help---
316           Enabling this option turns on a quick NMI selftest to verify
317           that the NMI behaves correctly.
318 
319           This might help diagnose strange hangs that rely on NMI to
320           function properly.
321 
322           If unsure, say N.
323 
324 config DEBUG_IMR_SELFTEST
325         bool "Isolated Memory Region self test"
326         default n
327         depends on INTEL_IMR
328         ---help---
329           This option enables automated sanity testing of the IMR code.
330           Some simple tests are run to verify IMR bounds checking, alignment
331           and overlapping. This option is really only useful if you are
332           debugging an IMR memory map or are modifying the IMR code and want to
333           test your changes.
334 
335           If unsure say N here.
336 
337 config X86_DEBUG_STATIC_CPU_HAS
338         bool "Debug alternatives"
339         depends on DEBUG_KERNEL
340         ---help---
341           This option causes additional code to be generated which
342           fails if static_cpu_has() is used before alternatives have
343           run.
344 
345           If unsure, say N.
346 
347 config X86_DEBUG_FPU
348         bool "Debug the x86 FPU code"
349         depends on DEBUG_KERNEL
350         default y
351         ---help---
352           If this option is enabled then there will be extra sanity
353           checks and (boot time) debug printouts added to the kernel.
354           This debugging adds some small amount of runtime overhead
355           to the kernel.
356 
357           If unsure, say N.
358 
359 config PUNIT_ATOM_DEBUG
360         tristate "ATOM Punit debug driver"
361         select DEBUG_FS
362         select IOSF_MBI
363         ---help---
364           This is a debug driver, which gets the power states
365           of all Punit North Complex devices. The power states of
366           each device is exposed as part of the debugfs interface.
367           The current power state can be read from
368           /sys/kernel/debug/punit_atom/dev_power_state
369 
370 endmenu

This page was automatically generated by LXR 0.3.1 (source).  •  Linux is a registered trademark of Linus Torvalds  •  Contact us