kbuild: Spelling/grammar fixes for config DEBUG_SECTION_MISMATCH

[linux-2.6-omap-h63xx.git] / lib / Kconfig.debug

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index aa56e631580d6a2ca2104ca1ca0a43fb1cdf8f60..0d385be682db021dccc6482f385d8bb6f30fa75e 100644 (file)
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -81,7 +81,7 @@ config HEADERS_CHECK
 
 config DEBUG_SECTION_MISMATCH
        bool "Enable full Section mismatch analysis"
-       default n
+       depends on UNDEFINED
        help
          The section mismatch analysis checks if there are illegal
          references from one section to another section.
@@ -90,19 +90,19 @@ config DEBUG_SECTION_MISMATCH
          most likely result in an oops.
          In the code functions and variables are annotated with
          __init, __devinit etc. (see full list in include/linux/init.h)
-         which result in the code/data being placed in specific sections.
-         The section mismatch anaylsis are always done after a full
-         kernel build but enabling this options will in addition
+         which results in the code/data being placed in specific sections.
+         The section mismatch analysis is always done after a full
+         kernel build but enabling this option will in addition
          do the following:
          - Add the option -fno-inline-functions-called-once to gcc
            When inlining a function annotated __init in a non-init
-           function we would loose the section information and thus
+           function we would lose the section information and thus
            the analysis would not catch the illegal reference.
-           This options tell gcc to inline less but will also
+           This option tells gcc to inline less but will also
            result in a larger kernel.
          - Run the section mismatch analysis for each module/built-in.o
            When we run the section mismatch analysis on vmlinux.o we
-           looses valueable information about where the mismatch was
+           lose valueble information about where the mismatch was
            introduced.
            Running the analysis for each module/built-in.o file
            will tell where the mismatch happens much closer to the
@@ -581,10 +581,38 @@ config LATENCYTOP
        select STACKTRACE
        select SCHEDSTATS
        select SCHED_DEBUG
-       depends on X86 || X86_64
+       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 PROVIDE_OHCI1394_DMA_INIT
+       bool "Provide code for enabling DMA 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.
 
 source "samples/Kconfig"