Merge branch 'for-2.6.35' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie...

[safe/jmp/linux-2.6] / arch / blackfin / Kconfig.debug

diff --git a/arch/blackfin/Kconfig.debug b/arch/blackfin/Kconfig.debug
index f08aea4..aec89a5 100644 (file)
--- a/arch/blackfin/Kconfig.debug
+++ b/arch/blackfin/Kconfig.debug
@@ -2,8 +2,34 @@ menu "Kernel hacking"
 
 source "lib/Kconfig.debug"
 
-config HAVE_ARCH_KGDB
-       def_bool y
+config DEBUG_STACKOVERFLOW
+       bool "Check for stack overflows"
+       depends on DEBUG_KERNEL
+       help
+         This option will cause messages to be printed if free stack space
+         drops below a certain limit.
+
+config DEBUG_STACK_USAGE
+       bool "Enable stack utilization instrumentation"
+       depends on DEBUG_KERNEL
+       help
+         Enables the display of the minimum amount of free stack which each
+         task has ever had available in the sysrq-T output.
+
+         This option will slow down process creation somewhat.
+
+config DEBUG_VERBOSE
+       bool "Verbose fault messages"
+       default y
+       select PRINTK
+       help
+         When a program crashes due to an exception, or the kernel detects
+         an internal error, the kernel can print a not so brief message
+         explaining what the problem was. This debugging information is
+         useful to developers and kernel hackers when tracking down problems,
+         but mostly meaningless to other people. This is always helpful for
+         debugging but serves no purpose on a production system.
+         Most people should say N here.
 
 config DEBUG_MMRS
        bool "Generate Blackfin MMR tree"
@@ -25,6 +51,19 @@ config DEBUG_HWERR
          hardware error interrupts and need to know where they are coming
          from.
 
+config EXACT_HWERR
+       bool "Try to make Hardware errors exact"
+       depends on DEBUG_HWERR
+       help
+         By default, the Blackfin hardware errors are not exact - the error
+          be reported multiple cycles after the error happens. This delay
+         can cause the wrong application, or even the kernel to receive a
+         signal to be killed. If you are getting HW errors in your system,
+         try turning this on to ensure they are at least comming from the
+         proper thread.
+
+         On production systems, it is safe (and a small optimization) to say N.
+
 config DEBUG_DOUBLEFAULT
        bool "Debug Double Faults"
        default n
@@ -169,11 +208,11 @@ config DEBUG_BFIN_HWTRACE_EXPAND_LEN
          4 for (2^4) 16k, or 4096 entries
 
 config DEBUG_BFIN_NO_KERN_HWTRACE
-       bool "Trace user apps (turn off hwtrace in kernel)"
+       bool "Turn off hwtrace in CPLB handlers"
        depends on DEBUG_BFIN_HWTRACE_ON
-       default n
+       default y
        help
-         Some pieces of the kernel contain a lot of flow changes which can
+         The CPLB error handler contains a lot of flow changes which can
          quickly fill up the hardware trace buffer.  When debugging crashes,
          the hardware trace may indicate that the problem lies in kernel
          space when in reality an application is buggy.
@@ -196,6 +235,15 @@ config EARLY_PRINTK
          all of this lives in the init section and is thrown away after the
          kernel boots completely.
 
+config NMI_WATCHDOG
+       bool "Enable NMI watchdog to help debugging lockup on SMP"
+       default n
+       depends on (SMP && !BFIN_SCRATCH_REG_RETN)
+       help
+         If any CPU in the system does not execute the period local timer
+         interrupt for more than 5 seconds, then the NMI handler dumps debug
+         information. This information can be used to debug the lockup.
+
 config CPLB_INFO
        bool "Display the CPLB information"
        help
@@ -210,4 +258,10 @@ config ACCESS_CHECK
 
          Say N here to disable that check to improve the performance.
 
+config BFIN_ISRAM_SELF_TEST
+       bool "isram boot self tests"
+       default n
+       help
+         Run some self tests of the isram driver code at boot.
+
 endmenu