source "lib/Kconfig.debug"
+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 HAVE_ARCH_KGDB
+ def_bool y
+
+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"
select DEBUG_FS
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
+ help
+ If an exception is caused while executing code within the exception
+ handler, the NMI handler, the reset vector, or in emulator mode,
+ a double fault occurs. On the Blackfin, this is a unrecoverable
+ event. You have two options:
+ - RESET exactly when double fault occurs. The excepting
+ instruction address is stored in RETX, where the next kernel
+ boot will print it out.
+ - Print debug message. This is much more error prone, although
+ easier to handle. It is error prone since:
+ - The excepting instruction is not committed.
+ - All writebacks from the instruction are prevented.
+ - The generated exception is not taken.
+ - The EXCAUSE field is updated with an unrecoverable event
+ The only way to check this is to see if EXCAUSE contains the
+ unrecoverable event value at every exception return. By selecting
+ this option, you are skipping over the faulting instruction, and
+ hoping things stay together enough to print out a debug message.
+
+ This does add a little kernel code, but is the only method to debug
+ double faults - if unsure say "Y"
+
+choice
+ prompt "Double Fault Failure Method"
+ default DEBUG_DOUBLEFAULT_PRINT
+ depends on DEBUG_DOUBLEFAULT
+
+config DEBUG_DOUBLEFAULT_PRINT
+ bool "Print"
+
+config DEBUG_DOUBLEFAULT_RESET
+ bool "Reset"
+
+endchoice
+
config DEBUG_ICACHE_CHECK
bool "Check Instruction cache coherency"
depends on DEBUG_KERNEL
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.
config EARLY_PRINTK
bool "Early printk"
default n
+ select SERIAL_CORE_CONSOLE
help
This option enables special console drivers which allow the kernel
to print messages very early in the bootup process.