[SCSI] qla2xxx: fix Kernel Panic with Qlogic 2472 Card.
[linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git] / arch / blackfin / Kconfig.debug
blob5f981d9ca625c4540ef6090e68d25d137ec29793
1 menu "Kernel hacking"
3 source "lib/Kconfig.debug"
5 config DEBUG_STACKOVERFLOW
6         bool "Check for stack overflows"
7         depends on DEBUG_KERNEL
8         help
9           This option will cause messages to be printed if free stack space
10           drops below a certain limit.
12 config DEBUG_STACK_USAGE
13         bool "Enable stack utilization instrumentation"
14         depends on DEBUG_KERNEL
15         help
16           Enables the display of the minimum amount of free stack which each
17           task has ever had available in the sysrq-T output.
19           This option will slow down process creation somewhat.
21 config HAVE_ARCH_KGDB
22         def_bool y
24 config KGDB_TESTCASE
25         tristate "KGDB: for test case in expect"
26         default n
27         help
28           This is a kgdb test case for automated testing.
30 config DEBUG_VERBOSE
31         bool "Verbose fault messages"
32         default y
33         select PRINTK
34         help
35           When a program crashes due to an exception, or the kernel detects
36           an internal error, the kernel can print a not so brief message
37           explaining what the problem was. This debugging information is
38           useful to developers and kernel hackers when tracking down problems,
39           but mostly meaningless to other people. This is always helpful for
40           debugging but serves no purpose on a production system.
41           Most people should say N here.
43 config DEBUG_MMRS
44         bool "Generate Blackfin MMR tree"
45         select DEBUG_FS
46         help
47           Create a tree of Blackfin MMRs via the debugfs tree.  If
48           you enable this, you will find all MMRs laid out in the
49           /sys/kernel/debug/blackfin/ directory where you can read/write
50           MMRs directly from userspace.  This is obviously just a debug
51           feature.
53 config DEBUG_HWERR
54         bool "Hardware error interrupt debugging"
55         depends on DEBUG_KERNEL
56         help
57           When enabled, the hardware error interrupt is never disabled, and
58           will happen immediately when an error condition occurs.  This comes
59           at a slight cost in code size, but is necessary if you are getting
60           hardware error interrupts and need to know where they are coming
61           from.
63 config DEBUG_DOUBLEFAULT
64         bool "Debug Double Faults"
65         default n
66         help
67           If an exception is caused while executing code within the exception
68           handler, the NMI handler, the reset vector, or in emulator mode,
69           a double fault occurs. On the Blackfin, this is a unrecoverable
70           event. You have two options:
71           - RESET exactly when double fault occurs. The excepting
72             instruction address is stored in RETX, where the next kernel
73             boot will print it out.
74           - Print debug message. This is much more error prone, although
75             easier to handle. It is error prone since:
76             - The excepting instruction is not committed.
77             - All writebacks from the instruction are prevented.
78             - The generated exception is not taken.
79             - The EXCAUSE field is updated with an unrecoverable event
80             The only way to check this is to see if EXCAUSE contains the
81             unrecoverable event value at every exception return. By selecting
82             this option, you are skipping over the faulting instruction, and 
83             hoping things stay together enough to print out a debug message.
85           This does add a little kernel code, but is the only method to debug
86           double faults - if unsure say "Y"
88 choice
89         prompt "Double Fault Failure Method"
90         default DEBUG_DOUBLEFAULT_PRINT
91         depends on DEBUG_DOUBLEFAULT
93 config DEBUG_DOUBLEFAULT_PRINT
94         bool "Print"
96 config DEBUG_DOUBLEFAULT_RESET
97         bool "Reset"
99 endchoice
101 config DEBUG_ICACHE_CHECK
102         bool "Check Instruction cache coherency"
103         depends on DEBUG_KERNEL
104         depends on DEBUG_HWERR
105         help
106           Say Y here if you are getting weird unexplained errors. This will
107           ensure that icache is what SDRAM says it should be by doing a
108           byte wise comparison between SDRAM and instruction cache. This
109           also relocates the irq_panic() function to L1 memory, (which is
110           un-cached).
112 config DEBUG_HUNT_FOR_ZERO
113         bool "Catch NULL pointer reads/writes"
114         default y
115         help
116           Say Y here to catch reads/writes to anywhere in the memory range
117           from 0x0000 - 0x0FFF (the first 4k) of memory.  This is useful in
118           catching common programming errors such as NULL pointer dereferences.
120           Misbehaving applications will be killed (generate a SEGV) while the
121           kernel will trigger a panic.
123           Enabling this option will take up an extra entry in CPLB table.
124           Otherwise, there is no extra overhead.
126 config DEBUG_BFIN_HWTRACE_ON
127         bool "Turn on Blackfin's Hardware Trace"
128         default y
129         help
130           All Blackfins include a Trace Unit which stores a history of the last
131           16 changes in program flow taken by the program sequencer. The history
132           allows the user to recreate the program sequencer’s recent path. This
133           can be handy when an application dies - we print out the execution
134           path of how it got to the offending instruction.
136           By turning this off, you may save a tiny amount of power.
138 choice
139         prompt "Omit loop Tracing"
140         default DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
141         depends on DEBUG_BFIN_HWTRACE_ON
142         help
143           The trace buffer can be configured to omit recording of changes in
144           program flow that match either the last entry or one of the last
145           two entries. Omitting one of these entries from the record prevents
146           the trace buffer from overflowing because of any sort of loop (for, do
147           while, etc) in the program.
149           Because zero-overhead Hardware loops are not recorded in the trace buffer,
150           this feature can be used to prevent trace overflow from loops that
151           are nested four deep.
153 config DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
154         bool "Trace all Loops"
155         help
156           The trace buffer records all changes of flow 
158 config DEBUG_BFIN_HWTRACE_COMPRESSION_ONE
159         bool "Compress single-level loops"
160         help
161           The trace buffer does not record single loops - helpful if trace 
162           is spinning on a while or do loop.
164 config DEBUG_BFIN_HWTRACE_COMPRESSION_TWO
165         bool "Compress two-level loops"
166         help
167           The trace buffer does not record loops two levels deep. Helpful if
168           the trace is spinning in a nested loop
170 endchoice
172 config DEBUG_BFIN_HWTRACE_COMPRESSION
173         int
174         depends on DEBUG_BFIN_HWTRACE_ON
175         default 0 if DEBUG_BFIN_HWTRACE_COMPRESSION_OFF
176         default 1 if DEBUG_BFIN_HWTRACE_COMPRESSION_ONE
177         default 2 if DEBUG_BFIN_HWTRACE_COMPRESSION_TWO
180 config DEBUG_BFIN_HWTRACE_EXPAND
181         bool "Expand Trace Buffer greater than 16 entries"
182         depends on DEBUG_BFIN_HWTRACE_ON
183         default n
184         help
185           By selecting this option, every time the 16 hardware entries in
186           the Blackfin's HW Trace buffer are full, the kernel will move them
187           into a software buffer, for dumping when there is an issue. This 
188           has a great impact on performance, (an interrupt every 16 change of 
189           flows) and should normally be turned off, except in those nasty
190           debugging sessions
192 config DEBUG_BFIN_HWTRACE_EXPAND_LEN
193         int "Size of Trace buffer (in power of 2k)"
194         range 0 4
195         depends on DEBUG_BFIN_HWTRACE_EXPAND
196         default 1
197         help
198           This sets the size of the software buffer that the trace information
199           is kept in.
200           0 for (2^0)  1k, or 256 entries,
201           1 for (2^1)  2k, or 512 entries,
202           2 for (2^2)  4k, or 1024 entries,
203           3 for (2^3)  8k, or 2048 entries,
204           4 for (2^4) 16k, or 4096 entries
206 config DEBUG_BFIN_NO_KERN_HWTRACE
207         bool "Turn off hwtrace in CPLB handlers"
208         depends on DEBUG_BFIN_HWTRACE_ON
209         default y
210         help
211           The CPLB error handler contains a lot of flow changes which can
212           quickly fill up the hardware trace buffer.  When debugging crashes,
213           the hardware trace may indicate that the problem lies in kernel
214           space when in reality an application is buggy.
216           Say Y here to disable hardware tracing in some known "jumpy" pieces
217           of code so that the trace buffer will extend further back.
219 config EARLY_PRINTK
220         bool "Early printk" 
221         default n
222         select SERIAL_CORE_CONSOLE
223         help
224           This option enables special console drivers which allow the kernel
225           to print messages very early in the bootup process.
227           This is useful for kernel debugging when your machine crashes very
228           early before the console code is initialized. After enabling this
229           feature, you must add "earlyprintk=serial,uart0,57600" to the
230           command line (bootargs). It is safe to say Y here in all cases, as
231           all of this lives in the init section and is thrown away after the
232           kernel boots completely.
234 config CPLB_INFO
235         bool "Display the CPLB information"
236         help
237           Display the CPLB information via /proc/cplbinfo.
239 config ACCESS_CHECK
240         bool "Check the user pointer address"
241         default y
242         help
243           Usually the pointer transfer from user space is checked to see if its
244           address is in the kernel space.
246           Say N here to disable that check to improve the performance.
248 endmenu