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 /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 !! 74 /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 =_ " !! 75 /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 =_ " !! 76 /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 =_ " !! 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 /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 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 <<
145 167
146 file 168 file
147 The given string is compared against eithe !! 169 The given string is compared against either the full pathname, the
148 pathname, or the basename of the source fi !! 170 src-root relative pathname, or the basename of the source file of
149 Examples:: !! 171 each callsite. Examples::
150 172
151 file svcsock.c 173 file svcsock.c
152 file kernel/freezer.c # ie column 1 !! 174 file kernel/freezer.c
153 file drivers/usb/* # all callsite !! 175 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 176
157 module 177 module
158 The given string is compared against the m 178 The given string is compared against the module name
159 of each callsite. The module name is the 179 of each callsite. The module name is the string as
160 seen in ``lsmod``, i.e. without the direct 180 seen in ``lsmod``, i.e. without the directory or the ``.ko``
161 suffix and with ``-`` changed to ``_``. E 181 suffix and with ``-`` changed to ``_``. Examples::
162 182
163 module sunrpc 183 module sunrpc
164 module nfsd 184 module nfsd
165 module drm* # both drm, drm_kms_he <<
166 185
167 format 186 format
168 The given string is searched for in the dy 187 The given string is searched for in the dynamic debug format
169 string. Note that the string does not nee 188 string. Note that the string does not need to match the
170 entire format, only some part. Whitespace 189 entire format, only some part. Whitespace and other
171 special characters can be escaped using C 190 special characters can be escaped using C octal character
172 escape ``\ooo`` notation, e.g. the space c 191 escape ``\ooo`` notation, e.g. the space character is ``\040``.
173 Alternatively, the string can be enclosed 192 Alternatively, the string can be enclosed in double quote
174 characters (``"``) or single quote charact 193 characters (``"``) or single quote characters (``'``).
175 Examples:: 194 Examples::
176 195
177 format svcrdma: // many of the 196 format svcrdma: // many of the NFS/RDMA server pr_debugs
178 format readahead // some pr_deb 197 format readahead // some pr_debugs in the readahead cache
179 format nfsd:\040SETATTR // one way to 198 format nfsd:\040SETATTR // one way to match a format with whitespace
180 format "nfsd: SETATTR" // a neater wa 199 format "nfsd: SETATTR" // a neater way to match a format with whitespace
181 format 'nfsd: SETATTR' // yet another 200 format 'nfsd: SETATTR' // yet another way to match a format with whitespace
182 201
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 202 line
194 The given line number or range of line num 203 The given line number or range of line numbers is compared
195 against the line number of each ``pr_debug 204 against the line number of each ``pr_debug()`` callsite. A single
196 line number matches the callsite line numb 205 line number matches the callsite line number exactly. A
197 range of line numbers matches any callsite 206 range of line numbers matches any callsite between the first
198 and last line number inclusive. An empty 207 and last line number inclusive. An empty first number means
199 the first line in the file, an empty last 208 the first line in the file, an empty last line number means the
200 last line number in the file. Examples:: 209 last line number in the file. Examples::
201 210
202 line 1603 // exactly line 16 211 line 1603 // exactly line 1603
203 line 1600-1605 // the six lines f 212 line 1600-1605 // the six lines from line 1600 to line 1605
204 line -1605 // the 1605 lines 213 line -1605 // the 1605 lines from line 1 to line 1605
205 line 1600- // all lines from 214 line 1600- // all lines from line 1600 to the end of the file
206 215
207 The flags specification comprises a change ope 216 The flags specification comprises a change operation followed
208 by one or more flag characters. The change op 217 by one or more flag characters. The change operation is one
209 of the characters:: 218 of the characters::
210 219
211 - remove the given flags 220 - remove the given flags
212 + add the given flags 221 + add the given flags
213 = set the flags to the given flags 222 = set the flags to the given flags
214 223
215 The flags are:: 224 The flags are::
216 225
217 p enables the pr_debug() callsite. 226 p enables the pr_debug() callsite.
218 _ enables no flags. !! 227 f Include the function name in the printed message
>> 228 l Include line number in the printed message
>> 229 m Include module name in the printed message
>> 230 t Include thread ID in messages not generated from interrupt context
>> 231 _ No flags are set. (Or'd with others on input)
219 232
220 Decorator flags add to the message-prefix, i !! 233 For ``print_hex_dump_debug()`` and ``print_hex_dump_bytes()``, only ``p`` flag
221 t Include thread ID, or <intr> !! 234 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 235
227 For ``print_hex_dump_debug()`` and ``print_hex !! 236 For display, the flags are preceded by ``=``
228 the ``p`` flag has meaning, other flags are ig !! 237 (mnemonic: what the flags are currently equal to).
229 238
230 Note the regexp ``^[-+=][fslmpt_]+$`` matches !! 239 Note the regexp ``^[-+=][flmpt_]+$`` matches a flags specification.
231 To clear all flags at once, use ``=_`` or ``-f !! 240 To clear all flags at once, use ``=_`` or ``-flmpt``.
232 241
233 242
234 Debug messages during Boot Process 243 Debug messages during Boot Process
235 ================================== 244 ==================================
236 245
237 To activate debug messages for core code and b 246 To activate debug messages for core code and built-in modules during
238 the boot process, even before userspace and de 247 the boot process, even before userspace and debugfs exists, use
239 ``dyndbg="QUERY"`` or ``module.dyndbg="QUERY"` !! 248 ``dyndbg="QUERY"``, ``module.dyndbg="QUERY"``, or ``ddebug_query="QUERY"``
>> 249 (``ddebug_query`` is obsoleted by ``dyndbg``, and deprecated). QUERY follows
240 the syntax described above, but must not excee 250 the syntax described above, but must not exceed 1023 characters. Your
241 bootloader may impose lower limits. 251 bootloader may impose lower limits.
242 252
243 These ``dyndbg`` params are processed just aft 253 These ``dyndbg`` params are processed just after the ddebug tables are
244 processed, as part of the early_initcall. Thu !! 254 processed, as part of the arch_initcall. Thus you can enable debug
245 messages in all code run after this early_init !! 255 messages in all code run after this arch_initcall via this boot
246 parameter. 256 parameter.
247 257
248 On an x86 system for example ACPI enablement i 258 On an x86 system for example ACPI enablement is a subsys_initcall and::
249 259
250 dyndbg="file ec.c +p" 260 dyndbg="file ec.c +p"
251 261
252 will show early Embedded Controller transactio 262 will show early Embedded Controller transactions during ACPI setup if
253 your machine (typically a laptop) has an Embed 263 your machine (typically a laptop) has an Embedded Controller.
254 PCI (or other devices) initialization also is 264 PCI (or other devices) initialization also is a hot candidate for using
255 this boot parameter for debugging purposes. 265 this boot parameter for debugging purposes.
256 266
257 If ``foo`` module is not built-in, ``foo.dyndb 267 If ``foo`` module is not built-in, ``foo.dyndbg`` will still be processed at
258 boot time, without effect, but will be reproce 268 boot time, without effect, but will be reprocessed when module is
259 loaded later. Bare ``dyndbg=`` is only process !! 269 loaded later. ``ddebug_query=`` and bare ``dyndbg=`` are only processed at
>> 270 boot.
260 271
261 272
262 Debug Messages at Module Initialization Time 273 Debug Messages at Module Initialization Time
263 ============================================ 274 ============================================
264 275
265 When ``modprobe foo`` is called, modprobe scan 276 When ``modprobe foo`` is called, modprobe scans ``/proc/cmdline`` for
266 ``foo.params``, strips ``foo.``, and passes th 277 ``foo.params``, strips ``foo.``, and passes them to the kernel along with
267 params given in modprobe args or ``/etc/modpro !! 278 params given in modprobe args or ``/etc/modprob.d/*.conf`` files,
268 in the following order: 279 in the following order:
269 280
270 1. parameters given via ``/etc/modprobe.d/*.co 281 1. parameters given via ``/etc/modprobe.d/*.conf``::
271 282
272 options foo dyndbg=+pt 283 options foo dyndbg=+pt
273 options foo dyndbg # defaults to +p 284 options foo dyndbg # defaults to +p
274 285
275 2. ``foo.dyndbg`` as given in boot args, ``foo 286 2. ``foo.dyndbg`` as given in boot args, ``foo.`` is stripped and passed::
276 287
277 foo.dyndbg=" func bar +p; func buz +mp 288 foo.dyndbg=" func bar +p; func buz +mp"
278 289
279 3. args to modprobe:: 290 3. args to modprobe::
280 291
281 modprobe foo dyndbg==pmf # override pr 292 modprobe foo dyndbg==pmf # override previous settings
282 293
283 These ``dyndbg`` queries are applied in order, 294 These ``dyndbg`` queries are applied in order, with last having final say.
284 This allows boot args to override or modify th 295 This allows boot args to override or modify those from ``/etc/modprobe.d``
285 (sensible, since 1 is system wide, 2 is kernel 296 (sensible, since 1 is system wide, 2 is kernel or boot specific), and
286 modprobe args to override both. 297 modprobe args to override both.
287 298
288 In the ``foo.dyndbg="QUERY"`` form, the query 299 In the ``foo.dyndbg="QUERY"`` form, the query must exclude ``module foo``.
289 ``foo`` is extracted from the param-name, and 300 ``foo`` is extracted from the param-name, and applied to each query in
290 ``QUERY``, and only 1 match-spec of each type 301 ``QUERY``, and only 1 match-spec of each type is allowed.
291 302
292 The ``dyndbg`` option is a "fake" module param 303 The ``dyndbg`` option is a "fake" module parameter, which means:
293 304
294 - modules do not need to define it explicitly 305 - modules do not need to define it explicitly
295 - every module gets it tacitly, whether they u 306 - every module gets it tacitly, whether they use pr_debug or not
296 - it doesn't appear in ``/sys/module/$module/p 307 - it doesn't appear in ``/sys/module/$module/parameters/``
297 To see it, grep the control file, or inspect 308 To see it, grep the control file, or inspect ``/proc/cmdline.``
298 309
299 For ``CONFIG_DYNAMIC_DEBUG`` kernels, any sett 310 For ``CONFIG_DYNAMIC_DEBUG`` kernels, any settings given at boot-time (or
300 enabled by ``-DDEBUG`` flag during compilation 311 enabled by ``-DDEBUG`` flag during compilation) can be disabled later via
301 the debugfs interface if the debug messages ar 312 the debugfs interface if the debug messages are no longer needed::
302 313
303 echo "module module_name -p" > /proc/dynami !! 314 echo "module module_name -p" > <debugfs>/dynamic_debug/control
304 315
305 Examples 316 Examples
306 ======== 317 ========
307 318
308 :: 319 ::
309 320
310 // enable the message at line 1603 of file s 321 // enable the message at line 1603 of file svcsock.c
311 :#> ddcmd 'file svcsock.c line 1603 +p' !! 322 nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
>> 323 <debugfs>/dynamic_debug/control
312 324
313 // enable all the messages in file svcsock.c 325 // enable all the messages in file svcsock.c
314 :#> ddcmd 'file svcsock.c +p' !! 326 nullarbor:~ # echo -n 'file svcsock.c +p' >
>> 327 <debugfs>/dynamic_debug/control
315 328
316 // enable all the messages in the NFS server 329 // enable all the messages in the NFS server module
317 :#> ddcmd 'module nfsd +p' !! 330 nullarbor:~ # echo -n 'module nfsd +p' >
>> 331 <debugfs>/dynamic_debug/control
318 332
319 // enable all 12 messages in the function sv 333 // enable all 12 messages in the function svc_process()
320 :#> ddcmd 'func svc_process +p' !! 334 nullarbor:~ # echo -n 'func svc_process +p' >
>> 335 <debugfs>/dynamic_debug/control
321 336
322 // disable all 12 messages in the function s 337 // disable all 12 messages in the function svc_process()
323 :#> ddcmd 'func svc_process -p' !! 338 nullarbor:~ # echo -n 'func svc_process -p' >
>> 339 <debugfs>/dynamic_debug/control
324 340
325 // enable messages for NFS calls READ, READL 341 // enable messages for NFS calls READ, READLINK, READDIR and READDIR+.
326 :#> ddcmd 'format "nfsd: READ" +p' !! 342 nullarbor:~ # echo -n 'format "nfsd: READ" +p' >
>> 343 <debugfs>/dynamic_debug/control
327 344
328 // enable messages in files of which the pat 345 // enable messages in files of which the paths include string "usb"
329 :#> ddcmd 'file *usb* +p' !! 346 nullarbor:~ # echo -n '*usb* +p' > <debugfs>/dynamic_debug/control
330 347
331 // enable all messages 348 // enable all messages
332 :#> ddcmd '+p' !! 349 nullarbor:~ # echo -n '+p' > <debugfs>/dynamic_debug/control
333 350
334 // add module, function to all enabled messa 351 // add module, function to all enabled messages
335 :#> ddcmd '+mf' !! 352 nullarbor:~ # echo -n '+mf' > <debugfs>/dynamic_debug/control
336 353
337 // boot-args example, with newlines and comm 354 // boot-args example, with newlines and comments for readability
338 Kernel command line: ... 355 Kernel command line: ...
339 // see what's going on in dyndbg=value pro !! 356 // see whats going on in dyndbg=value processing
340 dynamic_debug.verbose=3 !! 357 dynamic_debug.verbose=1
341 // enable pr_debugs in the btrfs module (c !! 358 // enable pr_debugs in 2 builtins, #cmt is stripped
342 btrfs.dyndbg="+p" !! 359 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 360 // enable pr_debugs in 2 functions in a module loaded later
347 pc87360.dyndbg="func pc87360_init_device + 361 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.