]>
Commit | Line | Data |
---|---|---|
74ce8322 MF |
1 | menu "Kernel hacking" |
2 | ||
3 | source "lib/Kconfig.debug" | |
4 | ||
a45d575f RG |
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. | |
11 | ||
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. | |
18 | ||
19 | This option will slow down process creation somewhat. | |
20 | ||
a5ac0129 | 21 | config HAVE_ARCH_KGDB |
459249aa MF |
22 | def_bool y |
23 | ||
9f06c38f RG |
24 | config DEBUG_VERBOSE |
25 | bool "Verbose fault messages" | |
26 | default y | |
27 | select PRINTK | |
28 | help | |
29 | When a program crashes due to an exception, or the kernel detects | |
30 | an internal error, the kernel can print a not so brief message | |
31 | explaining what the problem was. This debugging information is | |
32 | useful to developers and kernel hackers when tracking down problems, | |
33 | but mostly meaningless to other people. This is always helpful for | |
34 | debugging but serves no purpose on a production system. | |
35 | Most people should say N here. | |
36 | ||
74ce8322 MF |
37 | config DEBUG_MMRS |
38 | bool "Generate Blackfin MMR tree" | |
39 | select DEBUG_FS | |
40 | help | |
41 | Create a tree of Blackfin MMRs via the debugfs tree. If | |
42 | you enable this, you will find all MMRs laid out in the | |
43 | /sys/kernel/debug/blackfin/ directory where you can read/write | |
44 | MMRs directly from userspace. This is obviously just a debug | |
45 | feature. | |
46 | ||
47 | config DEBUG_HWERR | |
48 | bool "Hardware error interrupt debugging" | |
49 | depends on DEBUG_KERNEL | |
50 | help | |
51 | When enabled, the hardware error interrupt is never disabled, and | |
52 | will happen immediately when an error condition occurs. This comes | |
53 | at a slight cost in code size, but is necessary if you are getting | |
54 | hardware error interrupts and need to know where they are coming | |
55 | from. | |
56 | ||
b9a3899d RG |
57 | config EXACT_HWERR |
58 | bool "Try to make Hardware errors exact" | |
59 | depends on DEBUG_HWERR | |
60 | help | |
61 | By default, the Blackfin hardware errors are not exact - the error | |
62 | be reported multiple cycles after the error happens. This delay | |
63 | can cause the wrong application, or even the kernel to receive a | |
64 | signal to be killed. If you are getting HW errors in your system, | |
65 | try turning this on to ensure they are at least comming from the | |
66 | proper thread. | |
67 | ||
68 | On production systems, it is safe (and a small optimization) to say N. | |
69 | ||
0c7a6b21 RG |
70 | config DEBUG_DOUBLEFAULT |
71 | bool "Debug Double Faults" | |
72 | default n | |
73 | help | |
74 | If an exception is caused while executing code within the exception | |
75 | handler, the NMI handler, the reset vector, or in emulator mode, | |
76 | a double fault occurs. On the Blackfin, this is a unrecoverable | |
77 | event. You have two options: | |
78 | - RESET exactly when double fault occurs. The excepting | |
79 | instruction address is stored in RETX, where the next kernel | |
80 | boot will print it out. | |
81 | - Print debug message. This is much more error prone, although | |
82 | easier to handle. It is error prone since: | |
83 | - The excepting instruction is not committed. | |
84 | - All writebacks from the instruction are prevented. | |
85 | - The generated exception is not taken. | |
86 | - The EXCAUSE field is updated with an unrecoverable event | |
87 | The only way to check this is to see if EXCAUSE contains the | |
88 | unrecoverable event value at every exception return. By selecting | |
89 | this option, you are skipping over the faulting instruction, and | |
90 | hoping things stay together enough to print out a debug message. | |
91 | ||
92 | This does add a little kernel code, but is the only method to debug | |
93 | double faults - if unsure say "Y" | |
94 | ||
95 | choice | |
96 | prompt "Double Fault Failure Method" | |
97 | default DEBUG_DOUBLEFAULT_PRINT | |
98 | depends on DEBUG_DOUBLEFAULT | |
99 | ||
100 | config DEBUG_DOUBLEFAULT_PRINT | |
101 | bool "Print" | |
102 | ||
103 | config DEBUG_DOUBLEFAULT_RESET | |
104 | bool "Reset" | |
105 | ||
106 | endchoice | |
107 | ||
74ce8322 MF |
108 | config DEBUG_ICACHE_CHECK |
109 | bool "Check Instruction cache coherency" | |
110 | depends on DEBUG_KERNEL | |
111 | depends on DEBUG_HWERR | |
112 | help | |
113 | Say Y here if you are getting weird unexplained errors. This will | |
114 | ensure that icache is what SDRAM says it should be by doing a | |
115 | byte wise comparison between SDRAM and instruction cache. This | |
116 | also relocates the irq_panic() function to L1 memory, (which is | |
117 | un-cached). | |
118 | ||
119 | config DEBUG_HUNT_FOR_ZERO | |
120 | bool "Catch NULL pointer reads/writes" | |
121 | default y | |
122 | help | |
123 | Say Y here to catch reads/writes to anywhere in the memory range | |
124 | from 0x0000 - 0x0FFF (the first 4k) of memory. This is useful in | |
125 | catching common programming errors such as NULL pointer dereferences. | |
126 | ||
127 | Misbehaving applications will be killed (generate a SEGV) while the | |
128 | kernel will trigger a panic. | |
129 | ||
130 | Enabling this option will take up an extra entry in CPLB table. | |
131 | Otherwise, there is no extra overhead. | |
132 | ||
133 | config DEBUG_BFIN_HWTRACE_ON | |
134 | bool "Turn on Blackfin's Hardware Trace" | |
135 | default y | |
136 | help | |
137 | All Blackfins include a Trace Unit which stores a history of the last | |
138 | 16 changes in program flow taken by the program sequencer. The history | |
139 | allows the user to recreate the program sequencer’s recent path. This | |
140 | can be handy when an application dies - we print out the execution | |
141 | path of how it got to the offending instruction. | |
142 | ||
143 | By turning this off, you may save a tiny amount of power. | |
144 | ||
145 | choice | |
146 | prompt "Omit loop Tracing" | |
147 | default DEBUG_BFIN_HWTRACE_COMPRESSION_OFF | |
148 | depends on DEBUG_BFIN_HWTRACE_ON | |
149 | help | |
150 | The trace buffer can be configured to omit recording of changes in | |
151 | program flow that match either the last entry or one of the last | |
152 | two entries. Omitting one of these entries from the record prevents | |
153 | the trace buffer from overflowing because of any sort of loop (for, do | |
154 | while, etc) in the program. | |
155 | ||
156 | Because zero-overhead Hardware loops are not recorded in the trace buffer, | |
157 | this feature can be used to prevent trace overflow from loops that | |
158 | are nested four deep. | |
159 | ||
160 | config DEBUG_BFIN_HWTRACE_COMPRESSION_OFF | |
161 | bool "Trace all Loops" | |
162 | help | |
163 | The trace buffer records all changes of flow | |
164 | ||
165 | config DEBUG_BFIN_HWTRACE_COMPRESSION_ONE | |
166 | bool "Compress single-level loops" | |
167 | help | |
168 | The trace buffer does not record single loops - helpful if trace | |
169 | is spinning on a while or do loop. | |
170 | ||
171 | config DEBUG_BFIN_HWTRACE_COMPRESSION_TWO | |
172 | bool "Compress two-level loops" | |
173 | help | |
174 | The trace buffer does not record loops two levels deep. Helpful if | |
175 | the trace is spinning in a nested loop | |
176 | ||
177 | endchoice | |
178 | ||
179 | config DEBUG_BFIN_HWTRACE_COMPRESSION | |
180 | int | |
181 | depends on DEBUG_BFIN_HWTRACE_ON | |
182 | default 0 if DEBUG_BFIN_HWTRACE_COMPRESSION_OFF | |
183 | default 1 if DEBUG_BFIN_HWTRACE_COMPRESSION_ONE | |
184 | default 2 if DEBUG_BFIN_HWTRACE_COMPRESSION_TWO | |
185 | ||
186 | ||
187 | config DEBUG_BFIN_HWTRACE_EXPAND | |
188 | bool "Expand Trace Buffer greater than 16 entries" | |
189 | depends on DEBUG_BFIN_HWTRACE_ON | |
190 | default n | |
191 | help | |
192 | By selecting this option, every time the 16 hardware entries in | |
193 | the Blackfin's HW Trace buffer are full, the kernel will move them | |
194 | into a software buffer, for dumping when there is an issue. This | |
195 | has a great impact on performance, (an interrupt every 16 change of | |
196 | flows) and should normally be turned off, except in those nasty | |
197 | debugging sessions | |
198 | ||
199 | config DEBUG_BFIN_HWTRACE_EXPAND_LEN | |
200 | int "Size of Trace buffer (in power of 2k)" | |
201 | range 0 4 | |
202 | depends on DEBUG_BFIN_HWTRACE_EXPAND | |
203 | default 1 | |
204 | help | |
205 | This sets the size of the software buffer that the trace information | |
206 | is kept in. | |
207 | 0 for (2^0) 1k, or 256 entries, | |
208 | 1 for (2^1) 2k, or 512 entries, | |
209 | 2 for (2^2) 4k, or 1024 entries, | |
210 | 3 for (2^3) 8k, or 2048 entries, | |
211 | 4 for (2^4) 16k, or 4096 entries | |
212 | ||
213 | config DEBUG_BFIN_NO_KERN_HWTRACE | |
e60cb8a9 | 214 | bool "Turn off hwtrace in CPLB handlers" |
74ce8322 | 215 | depends on DEBUG_BFIN_HWTRACE_ON |
e60cb8a9 | 216 | default y |
74ce8322 | 217 | help |
e60cb8a9 | 218 | The CPLB error handler contains a lot of flow changes which can |
74ce8322 MF |
219 | quickly fill up the hardware trace buffer. When debugging crashes, |
220 | the hardware trace may indicate that the problem lies in kernel | |
221 | space when in reality an application is buggy. | |
222 | ||
223 | Say Y here to disable hardware tracing in some known "jumpy" pieces | |
224 | of code so that the trace buffer will extend further back. | |
225 | ||
226 | config EARLY_PRINTK | |
227 | bool "Early printk" | |
228 | default n | |
0cfbb323 | 229 | select SERIAL_CORE_CONSOLE |
74ce8322 MF |
230 | help |
231 | This option enables special console drivers which allow the kernel | |
232 | to print messages very early in the bootup process. | |
233 | ||
234 | This is useful for kernel debugging when your machine crashes very | |
235 | early before the console code is initialized. After enabling this | |
236 | feature, you must add "earlyprintk=serial,uart0,57600" to the | |
237 | command line (bootargs). It is safe to say Y here in all cases, as | |
238 | all of this lives in the init section and is thrown away after the | |
239 | kernel boots completely. | |
240 | ||
60ffdb36 GY |
241 | config NMI_WATCHDOG |
242 | bool "Enable NMI watchdog to help debugging lockup on SMP" | |
243 | default n | |
244 | depends on (SMP && !BFIN_SCRATCH_REG_RETN) | |
245 | help | |
246 | If any CPU in the system does not execute the period local timer | |
247 | interrupt for more than 5 seconds, then the NMI handler dumps debug | |
248 | information. This information can be used to debug the lockup. | |
249 | ||
74ce8322 MF |
250 | config CPLB_INFO |
251 | bool "Display the CPLB information" | |
252 | help | |
cf93425d | 253 | Display the CPLB information via /proc/cplbinfo. |
74ce8322 MF |
254 | |
255 | config ACCESS_CHECK | |
256 | bool "Check the user pointer address" | |
257 | default y | |
258 | help | |
259 | Usually the pointer transfer from user space is checked to see if its | |
260 | address is in the kernel space. | |
261 | ||
262 | Say N here to disable that check to improve the performance. | |
263 | ||
c40cdb2c MF |
264 | config BFIN_ISRAM_SELF_TEST |
265 | bool "isram boot self tests" | |
266 | default n | |
267 | help | |
268 | Run some self tests of the isram driver code at boot. | |
269 | ||
74ce8322 | 270 | endmenu |