1 Dynamic debug 1 Dynamic debug
2 +++++++++++++ 2 +++++++++++++
3 3
4 4
5 Introduction 5 Introduction
6 ============ 6 ============
7 7
8 Dynamic debug allows you to dynamically enable !! 8 This document describes how to use the dynamic debug (dyndbg) feature.
9 debug-print code to obtain additional kernel i <<
10 9
11 If ``/proc/dynamic_debug/control`` exists, you !! 10 Dynamic debug is designed to allow you to dynamically enable/disable
12 debug. You'll need root access (sudo su) to u !! 11 kernel code to obtain additional kernel information. Currently, if
>> 12 ``CONFIG_DYNAMIC_DEBUG`` is set, then all ``pr_debug()``/``dev_dbg()`` and
>> 13 ``print_hex_dump_debug()``/``print_hex_dump_bytes()`` calls can be dynamically
>> 14 enabled per-callsite.
13 15
14 Dynamic debug provides: !! 16 If ``CONFIG_DYNAMIC_DEBUG`` is not set, ``print_hex_dump_debug()`` is just
>> 17 shortcut for ``print_hex_dump(KERN_DEBUG)``.
15 18
16 * a Catalog of all *prdbgs* in your kernel. !! 19 For ``print_hex_dump_debug()``/``print_hex_dump_bytes()``, format string is
17 ``cat /proc/dynamic_debug/control`` to see !! 20 its ``prefix_str`` argument, if it is constant string; or ``hexdump``
>> 21 in case ``prefix_str`` is built dynamically.
>> 22
>> 23 Dynamic debug has even more useful features:
18 24
19 * a Simple query/command language to alter *p !! 25 * Simple query language allows turning on and off debugging
20 any combination of 0 or 1 of: !! 26 statements by matching any combination of 0 or 1 of:
21 27
22 - source filename 28 - source filename
23 - function name 29 - function name
24 - line number (including ranges of line num 30 - line number (including ranges of line numbers)
25 - module name 31 - module name
26 - format string 32 - format string
27 - class name (as known/declared by each mod <<
28 33
29 NOTE: To actually get the debug-print output o !! 34 * Provides a debugfs control file: ``<debugfs>/dynamic_debug/control``
30 need to adjust the kernel ``loglevel=``, or us !! 35 which can be read to display the complete list of known debug
31 Read about these kernel parameters in !! 36 statements, to help guide you
32 Documentation/admin-guide/kernel-parameters.rs !! 37
>> 38 Controlling dynamic debug Behaviour
>> 39 ===================================
>> 40
>> 41 The behaviour of ``pr_debug()``/``dev_dbg()`` are controlled via writing to a
>> 42 control file in the 'debugfs' filesystem. Thus, you must first mount
>> 43 the debugfs filesystem, in order to make use of this feature.
>> 44 Subsequently, we refer to the control file as:
>> 45 ``<debugfs>/dynamic_debug/control``. For example, if you want to enable
>> 46 printing from source file ``svcsock.c``, line 1603 you simply do::
>> 47
>> 48 nullarbor:~ # echo 'file svcsock.c line 1603 +p' >
>> 49 <debugfs>/dynamic_debug/control
>> 50
>> 51 If you make a mistake with the syntax, the write will fail thus::
>> 52
>> 53 nullarbor:~ # echo 'file svcsock.c wtf 1 +p' >
>> 54 <debugfs>/dynamic_debug/control
>> 55 -bash: echo: write error: Invalid argument
33 56
34 Viewing Dynamic Debug Behaviour 57 Viewing Dynamic Debug Behaviour
35 =============================== 58 ===============================
36 59
37 You can view the currently configured behaviou !! 60 You can view the currently configured behaviour of all the debug
>> 61 statements via::
38 62
39 :#> head -n7 /proc/dynamic_debug/control !! 63 nullarbor:~ # cat <debugfs>/dynamic_debug/control
40 # filename:lineno [module]function flags for 64 # filename:lineno [module]function flags format
41 init/main.c:1179 [main]initcall_blacklist =_ !! 65 /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ "SVCRDMA Module Removed, deregister RPC RDMA transport\012"
42 init/main.c:1218 [main]initcall_blacklisted !! 66 /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ "\011max_inline : %d\012"
43 init/main.c:1424 [main]run_init_process =_ " !! 67 /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ "\011sq_depth : %d\012"
44 init/main.c:1426 [main]run_init_process =_ " !! 68 /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ "\011max_requests : %d\012"
45 init/main.c:1427 [main]run_init_process =_ " !! 69 ...
46 init/main.c:1429 [main]run_init_process =_ " <<
47 70
48 The 3rd space-delimited column shows the curre <<
49 a ``=`` for easy use with grep/cut. ``=p`` sho <<
50 71
51 Controlling dynamic debug Behaviour !! 72 You can also apply standard Unix text manipulation filters to this
52 =================================== !! 73 data, e.g.::
53 74
54 The behaviour of *prdbg* sites are controlled !! 75 nullarbor:~ # grep -i rdma <debugfs>/dynamic_debug/control | wc -l
55 query/commands to the control file. Example:: !! 76 62
56 77
57 # grease the interface !! 78 nullarbor:~ # grep -i tcp <debugfs>/dynamic_debug/control | wc -l
58 :#> alias ddcmd='echo $* > /proc/dynamic_deb !! 79 42
59 80
60 :#> ddcmd '-p; module main func run* +p' !! 81 The third column shows the currently enabled flags for each debug
61 :#> grep =p /proc/dynamic_debug/control !! 82 statement callsite (see below for definitions of the flags). The
62 init/main.c:1424 [main]run_init_process =p " !! 83 default value, with no flags enabled, is ``=_``. So you can view all
63 init/main.c:1426 [main]run_init_process =p " !! 84 the debug statement callsites with any non-default flags::
64 init/main.c:1427 [main]run_init_process =p " <<
65 init/main.c:1429 [main]run_init_process =p " <<
66 <<
67 Error messages go to console/syslog:: <<
68 <<
69 :#> ddcmd mode foo +p <<
70 dyndbg: unknown keyword "mode" <<
71 dyndbg: query parse failed <<
72 bash: echo: write error: Invalid argument <<
73 85
74 If debugfs is also enabled and mounted, ``dyna !! 86 nullarbor:~ # awk '$3 != "=_"' <debugfs>/dynamic_debug/control
75 also under the mount-dir, typically ``/sys/ker !! 87 # filename:lineno [module]function flags format
>> 88 /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012"
76 89
77 Command Language Reference 90 Command Language Reference
78 ========================== 91 ==========================
79 92
80 At the basic lexical level, a command is a seq !! 93 At the lexical level, a command comprises a sequence of words separated
81 by spaces or tabs. So these are all equivalen 94 by spaces or tabs. So these are all equivalent::
82 95
83 :#> ddcmd file svcsock.c line 1603 +p !! 96 nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
84 :#> ddcmd "file svcsock.c line 1603 +p" !! 97 <debugfs>/dynamic_debug/control
85 :#> ddcmd ' file svcsock.c line 1603 !! 98 nullarbor:~ # echo -n ' file svcsock.c line 1603 +p ' >
>> 99 <debugfs>/dynamic_debug/control
>> 100 nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
>> 101 <debugfs>/dynamic_debug/control
86 102
87 Command submissions are bounded by a write() s 103 Command submissions are bounded by a write() system call.
88 Multiple commands can be written together, sep 104 Multiple commands can be written together, separated by ``;`` or ``\n``::
89 105
90 :#> ddcmd "func pnpacpi_get_resources +p; fu !! 106 ~# echo "func pnpacpi_get_resources +p; func pnp_assign_mem +p" \
91 :#> ddcmd <<"EOC" !! 107 > <debugfs>/dynamic_debug/control
92 func pnpacpi_get_resources +p <<
93 func pnp_assign_mem +p <<
94 EOC <<
95 :#> cat query-batch-file > /proc/dynamic_deb <<
96 <<
97 You can also use wildcards in each query term. <<
98 ``*`` (matches zero or more characters) and `` <<
99 character). For example, you can match all usb <<
100 108
101 :#> ddcmd file "drivers/usb/*" +p # "" t !! 109 If your query set is big, you can batch them too::
102 110
103 Syntactically, a command is pairs of keyword v !! 111 ~# cat query-batch-file > <debugfs>/dynamic_debug/control
104 flags change or setting:: <<
105 112
106 command ::= match-spec* flags-spec !! 113 Another way is to use wildcards. The match rule supports ``*`` (matches
>> 114 zero or more characters) and ``?`` (matches exactly one character). For
>> 115 example, you can match all usb drivers::
107 116
108 The match-spec's select *prdbgs* from the cata !! 117 ~# echo "file drivers/usb/* +p" > <debugfs>/dynamic_debug/control
109 the flags-spec, all constraints are ANDed toge <<
110 is the same as keyword "*". <<
111 118
>> 119 At the syntactical level, a command comprises a sequence of match
>> 120 specifications, followed by a flags change specification::
112 121
113 A match specification is a keyword, which sele !! 122 command ::= match-spec* flags-spec
114 the callsite to be compared, and a value to co !! 123
115 keywords are::: !! 124 The match-spec's are used to choose a subset of the known pr_debug()
>> 125 callsites to which to apply the flags-spec. Think of them as a query
>> 126 with implicit ANDs between each pair. Note that an empty list of
>> 127 match-specs will select all debug statement callsites.
>> 128
>> 129 A match specification comprises a keyword, which controls the
>> 130 attribute of the callsite to be compared, and a value to compare
>> 131 against. Possible keywords are:::
116 132
117 match-spec ::= 'func' string | 133 match-spec ::= 'func' string |
118 'file' string | 134 'file' string |
119 'module' string | 135 'module' string |
120 'format' string | 136 'format' string |
121 'class' string | <<
122 'line' line-range 137 'line' line-range
123 138
124 line-range ::= lineno | 139 line-range ::= lineno |
125 '-'lineno | 140 '-'lineno |
126 lineno'-' | 141 lineno'-' |
127 lineno'-'lineno 142 lineno'-'lineno
128 143
129 lineno ::= unsigned-int 144 lineno ::= unsigned-int
130 145
131 .. note:: 146 .. note::
132 147
133 ``line-range`` cannot contain space, e.g. 148 ``line-range`` cannot contain space, e.g.
134 "1-30" is valid range but "1 - 30" is not. 149 "1-30" is valid range but "1 - 30" is not.
135 150
136 151
137 The meanings of each keyword are: 152 The meanings of each keyword are:
138 153
139 func 154 func
140 The given string is compared against the f 155 The given string is compared against the function name
141 of each callsite. Example:: 156 of each callsite. Example::
142 157
143 func svc_tcp_accept 158 func svc_tcp_accept
144 func *recv* # in rfcomm, b <<
145 159
146 file 160 file
147 The given string is compared against eithe !! 161 The given string is compared against either the full pathname, the
148 pathname, or the basename of the source fi !! 162 src-root relative pathname, or the basename of the source file of
149 Examples:: !! 163 each callsite. Examples::
150 164
151 file svcsock.c 165 file svcsock.c
152 file kernel/freezer.c # ie column 1 !! 166 file kernel/freezer.c
153 file drivers/usb/* # all callsite !! 167 file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c
154 file inode.c:start_* # parse :tail <<
155 file inode.c:1-100 # parse :tail <<
156 168
157 module 169 module
158 The given string is compared against the m 170 The given string is compared against the module name
159 of each callsite. The module name is the 171 of each callsite. The module name is the string as
160 seen in ``lsmod``, i.e. without the direct 172 seen in ``lsmod``, i.e. without the directory or the ``.ko``
161 suffix and with ``-`` changed to ``_``. E 173 suffix and with ``-`` changed to ``_``. Examples::
162 174
163 module sunrpc 175 module sunrpc
164 module nfsd 176 module nfsd
165 module drm* # both drm, drm_kms_he <<
166 177
167 format 178 format
168 The given string is searched for in the dy 179 The given string is searched for in the dynamic debug format
169 string. Note that the string does not nee 180 string. Note that the string does not need to match the
170 entire format, only some part. Whitespace 181 entire format, only some part. Whitespace and other
171 special characters can be escaped using C 182 special characters can be escaped using C octal character
172 escape ``\ooo`` notation, e.g. the space c 183 escape ``\ooo`` notation, e.g. the space character is ``\040``.
173 Alternatively, the string can be enclosed 184 Alternatively, the string can be enclosed in double quote
174 characters (``"``) or single quote charact 185 characters (``"``) or single quote characters (``'``).
175 Examples:: 186 Examples::
176 187
177 format svcrdma: // many of the 188 format svcrdma: // many of the NFS/RDMA server pr_debugs
178 format readahead // some pr_deb 189 format readahead // some pr_debugs in the readahead cache
179 format nfsd:\040SETATTR // one way to 190 format nfsd:\040SETATTR // one way to match a format with whitespace
180 format "nfsd: SETATTR" // a neater wa 191 format "nfsd: SETATTR" // a neater way to match a format with whitespace
181 format 'nfsd: SETATTR' // yet another 192 format 'nfsd: SETATTR' // yet another way to match a format with whitespace
182 193
183 class <<
184 The given class_name is validated against <<
185 have declared a list of known class_names. <<
186 found for a module, callsite & class match <<
187 proceeds. Examples:: <<
188 <<
189 class DRM_UT_KMS # a DRM.debug <<
190 class JUNK # silent non-m <<
191 // class TLD_* # NOTICE: no w <<
192 <<
193 line 194 line
194 The given line number or range of line num 195 The given line number or range of line numbers is compared
195 against the line number of each ``pr_debug 196 against the line number of each ``pr_debug()`` callsite. A single
196 line number matches the callsite line numb 197 line number matches the callsite line number exactly. A
197 range of line numbers matches any callsite 198 range of line numbers matches any callsite between the first
198 and last line number inclusive. An empty 199 and last line number inclusive. An empty first number means
199 the first line in the file, an empty last 200 the first line in the file, an empty last line number means the
200 last line number in the file. Examples:: 201 last line number in the file. Examples::
201 202
202 line 1603 // exactly line 16 203 line 1603 // exactly line 1603
203 line 1600-1605 // the six lines f 204 line 1600-1605 // the six lines from line 1600 to line 1605
204 line -1605 // the 1605 lines 205 line -1605 // the 1605 lines from line 1 to line 1605
205 line 1600- // all lines from 206 line 1600- // all lines from line 1600 to the end of the file
206 207
207 The flags specification comprises a change ope 208 The flags specification comprises a change operation followed
208 by one or more flag characters. The change op 209 by one or more flag characters. The change operation is one
209 of the characters:: 210 of the characters::
210 211
211 - remove the given flags 212 - remove the given flags
212 + add the given flags 213 + add the given flags
213 = set the flags to the given flags 214 = set the flags to the given flags
214 215
215 The flags are:: 216 The flags are::
216 217
217 p enables the pr_debug() callsite. 218 p enables the pr_debug() callsite.
218 _ enables no flags. !! 219 f Include the function name in the printed message
>> 220 l Include line number in the printed message
>> 221 m Include module name in the printed message
>> 222 t Include thread ID in messages not generated from interrupt context
>> 223 _ No flags are set. (Or'd with others on input)
219 224
220 Decorator flags add to the message-prefix, i !! 225 For ``print_hex_dump_debug()`` and ``print_hex_dump_bytes()``, only ``p`` flag
221 t Include thread ID, or <intr> !! 226 have meaning, other flags ignored.
222 m Include module name <<
223 f Include the function name <<
224 s Include the source file name <<
225 l Include line number <<
226 227
227 For ``print_hex_dump_debug()`` and ``print_hex !! 228 For display, the flags are preceded by ``=``
228 the ``p`` flag has meaning, other flags are ig !! 229 (mnemonic: what the flags are currently equal to).
229 230
230 Note the regexp ``^[-+=][fslmpt_]+$`` matches !! 231 Note the regexp ``^[-+=][flmpt_]+$`` matches a flags specification.
231 To clear all flags at once, use ``=_`` or ``-f !! 232 To clear all flags at once, use ``=_`` or ``-flmpt``.
232 233
233 234
234 Debug messages during Boot Process 235 Debug messages during Boot Process
235 ================================== 236 ==================================
236 237
237 To activate debug messages for core code and b 238 To activate debug messages for core code and built-in modules during
238 the boot process, even before userspace and de 239 the boot process, even before userspace and debugfs exists, use
239 ``dyndbg="QUERY"`` or ``module.dyndbg="QUERY"` !! 240 ``dyndbg="QUERY"``, ``module.dyndbg="QUERY"``, or ``ddebug_query="QUERY"``
>> 241 (``ddebug_query`` is obsoleted by ``dyndbg``, and deprecated). QUERY follows
240 the syntax described above, but must not excee 242 the syntax described above, but must not exceed 1023 characters. Your
241 bootloader may impose lower limits. 243 bootloader may impose lower limits.
242 244
243 These ``dyndbg`` params are processed just aft 245 These ``dyndbg`` params are processed just after the ddebug tables are
244 processed, as part of the early_initcall. Thu !! 246 processed, as part of the arch_initcall. Thus you can enable debug
245 messages in all code run after this early_init !! 247 messages in all code run after this arch_initcall via this boot
246 parameter. 248 parameter.
247 249
248 On an x86 system for example ACPI enablement i 250 On an x86 system for example ACPI enablement is a subsys_initcall and::
249 251
250 dyndbg="file ec.c +p" 252 dyndbg="file ec.c +p"
251 253
252 will show early Embedded Controller transactio 254 will show early Embedded Controller transactions during ACPI setup if
253 your machine (typically a laptop) has an Embed 255 your machine (typically a laptop) has an Embedded Controller.
254 PCI (or other devices) initialization also is 256 PCI (or other devices) initialization also is a hot candidate for using
255 this boot parameter for debugging purposes. 257 this boot parameter for debugging purposes.
256 258
257 If ``foo`` module is not built-in, ``foo.dyndb 259 If ``foo`` module is not built-in, ``foo.dyndbg`` will still be processed at
258 boot time, without effect, but will be reproce 260 boot time, without effect, but will be reprocessed when module is
259 loaded later. Bare ``dyndbg=`` is only process !! 261 loaded later. ``ddebug_query=`` and bare ``dyndbg=`` are only processed at
>> 262 boot.
260 263
261 264
262 Debug Messages at Module Initialization Time 265 Debug Messages at Module Initialization Time
263 ============================================ 266 ============================================
264 267
265 When ``modprobe foo`` is called, modprobe scan 268 When ``modprobe foo`` is called, modprobe scans ``/proc/cmdline`` for
266 ``foo.params``, strips ``foo.``, and passes th 269 ``foo.params``, strips ``foo.``, and passes them to the kernel along with
267 params given in modprobe args or ``/etc/modpro !! 270 params given in modprobe args or ``/etc/modprob.d/*.conf`` files,
268 in the following order: 271 in the following order:
269 272
270 1. parameters given via ``/etc/modprobe.d/*.co 273 1. parameters given via ``/etc/modprobe.d/*.conf``::
271 274
272 options foo dyndbg=+pt 275 options foo dyndbg=+pt
273 options foo dyndbg # defaults to +p 276 options foo dyndbg # defaults to +p
274 277
275 2. ``foo.dyndbg`` as given in boot args, ``foo 278 2. ``foo.dyndbg`` as given in boot args, ``foo.`` is stripped and passed::
276 279
277 foo.dyndbg=" func bar +p; func buz +mp 280 foo.dyndbg=" func bar +p; func buz +mp"
278 281
279 3. args to modprobe:: 282 3. args to modprobe::
280 283
281 modprobe foo dyndbg==pmf # override pr 284 modprobe foo dyndbg==pmf # override previous settings
282 285
283 These ``dyndbg`` queries are applied in order, 286 These ``dyndbg`` queries are applied in order, with last having final say.
284 This allows boot args to override or modify th 287 This allows boot args to override or modify those from ``/etc/modprobe.d``
285 (sensible, since 1 is system wide, 2 is kernel 288 (sensible, since 1 is system wide, 2 is kernel or boot specific), and
286 modprobe args to override both. 289 modprobe args to override both.
287 290
288 In the ``foo.dyndbg="QUERY"`` form, the query 291 In the ``foo.dyndbg="QUERY"`` form, the query must exclude ``module foo``.
289 ``foo`` is extracted from the param-name, and 292 ``foo`` is extracted from the param-name, and applied to each query in
290 ``QUERY``, and only 1 match-spec of each type 293 ``QUERY``, and only 1 match-spec of each type is allowed.
291 294
292 The ``dyndbg`` option is a "fake" module param 295 The ``dyndbg`` option is a "fake" module parameter, which means:
293 296
294 - modules do not need to define it explicitly 297 - modules do not need to define it explicitly
295 - every module gets it tacitly, whether they u 298 - every module gets it tacitly, whether they use pr_debug or not
296 - it doesn't appear in ``/sys/module/$module/p 299 - it doesn't appear in ``/sys/module/$module/parameters/``
297 To see it, grep the control file, or inspect 300 To see it, grep the control file, or inspect ``/proc/cmdline.``
298 301
299 For ``CONFIG_DYNAMIC_DEBUG`` kernels, any sett 302 For ``CONFIG_DYNAMIC_DEBUG`` kernels, any settings given at boot-time (or
300 enabled by ``-DDEBUG`` flag during compilation 303 enabled by ``-DDEBUG`` flag during compilation) can be disabled later via
301 the debugfs interface if the debug messages ar 304 the debugfs interface if the debug messages are no longer needed::
302 305
303 echo "module module_name -p" > /proc/dynami !! 306 echo "module module_name -p" > <debugfs>/dynamic_debug/control
304 307
305 Examples 308 Examples
306 ======== 309 ========
307 310
308 :: 311 ::
309 312
310 // enable the message at line 1603 of file s 313 // enable the message at line 1603 of file svcsock.c
311 :#> ddcmd 'file svcsock.c line 1603 +p' !! 314 nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
>> 315 <debugfs>/dynamic_debug/control
312 316
313 // enable all the messages in file svcsock.c 317 // enable all the messages in file svcsock.c
314 :#> ddcmd 'file svcsock.c +p' !! 318 nullarbor:~ # echo -n 'file svcsock.c +p' >
>> 319 <debugfs>/dynamic_debug/control
315 320
316 // enable all the messages in the NFS server 321 // enable all the messages in the NFS server module
317 :#> ddcmd 'module nfsd +p' !! 322 nullarbor:~ # echo -n 'module nfsd +p' >
>> 323 <debugfs>/dynamic_debug/control
318 324
319 // enable all 12 messages in the function sv 325 // enable all 12 messages in the function svc_process()
320 :#> ddcmd 'func svc_process +p' !! 326 nullarbor:~ # echo -n 'func svc_process +p' >
>> 327 <debugfs>/dynamic_debug/control
321 328
322 // disable all 12 messages in the function s 329 // disable all 12 messages in the function svc_process()
323 :#> ddcmd 'func svc_process -p' !! 330 nullarbor:~ # echo -n 'func svc_process -p' >
>> 331 <debugfs>/dynamic_debug/control
324 332
325 // enable messages for NFS calls READ, READL 333 // enable messages for NFS calls READ, READLINK, READDIR and READDIR+.
326 :#> ddcmd 'format "nfsd: READ" +p' !! 334 nullarbor:~ # echo -n 'format "nfsd: READ" +p' >
>> 335 <debugfs>/dynamic_debug/control
327 336
328 // enable messages in files of which the pat 337 // enable messages in files of which the paths include string "usb"
329 :#> ddcmd 'file *usb* +p' !! 338 nullarbor:~ # echo -n '*usb* +p' > <debugfs>/dynamic_debug/control
330 339
331 // enable all messages 340 // enable all messages
332 :#> ddcmd '+p' !! 341 nullarbor:~ # echo -n '+p' > <debugfs>/dynamic_debug/control
333 342
334 // add module, function to all enabled messa 343 // add module, function to all enabled messages
335 :#> ddcmd '+mf' !! 344 nullarbor:~ # echo -n '+mf' > <debugfs>/dynamic_debug/control
336 345
337 // boot-args example, with newlines and comm 346 // boot-args example, with newlines and comments for readability
338 Kernel command line: ... 347 Kernel command line: ...
339 // see what's going on in dyndbg=value pro !! 348 // see whats going on in dyndbg=value processing
340 dynamic_debug.verbose=3 !! 349 dynamic_debug.verbose=1
341 // enable pr_debugs in the btrfs module (c !! 350 // enable pr_debugs in 2 builtins, #cmt is stripped
342 btrfs.dyndbg="+p" !! 351 dyndbg="module params +p #cmt ; module sys +p"
343 // enable pr_debugs in all files under ini <<
344 // and the function parse_one, #cmt is str <<
345 dyndbg="file init/* +p #cmt ; func parse_o <<
346 // enable pr_debugs in 2 functions in a mo 352 // enable pr_debugs in 2 functions in a module loaded later
347 pc87360.dyndbg="func pc87360_init_device + 353 pc87360.dyndbg="func pc87360_init_device +p; func pc87360_find +p"
348 <<
349 Kernel Configuration <<
350 ==================== <<
351 <<
352 Dynamic Debug is enabled via kernel config ite <<
353 <<
354 CONFIG_DYNAMIC_DEBUG=y # build catalo <<
355 CONFIG_DYNAMIC_DEBUG_CORE=y # enable mecha <<
356 <<
357 If you do not want to enable dynamic debug glo <<
358 system), you may set ``CONFIG_DYNAMIC_DEBUG_CO <<
359 debug and add ``ccflags := -DDYNAMIC_DEBUG_MOD <<
360 modules which you'd like to dynamically debug <<
361 <<
362 <<
363 Kernel *prdbg* API <<
364 ================== <<
365 <<
366 The following functions are cataloged and cont <<
367 debug is enabled:: <<
368 <<
369 pr_debug() <<
370 dev_dbg() <<
371 print_hex_dump_debug() <<
372 print_hex_dump_bytes() <<
373 <<
374 Otherwise, they are off by default; ``ccflags <<
375 ``#define DEBUG`` in a source file will enable <<
376 <<
377 If ``CONFIG_DYNAMIC_DEBUG`` is not set, ``prin <<
378 just a shortcut for ``print_hex_dump(KERN_DEBU <<
379 <<
380 For ``print_hex_dump_debug()``/``print_hex_dum <<
381 its ``prefix_str`` argument, if it is constant <<
382 in case ``prefix_str`` is built dynamically. <<
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.