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