Kconfig.debug 9.0 KB

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