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