Commit | Line | Data |
---|---|---|
e3e2aaf7 JW |
1 | <?xml version="1.0" encoding="UTF-8"?> |
2 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" | |
3 | "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> | |
4 | ||
5 | <book id="kgdbOnLinux"> | |
6 | <bookinfo> | |
84c08fd6 | 7 | <title>Using kgdb, kdb and the kernel debugger internals</title> |
e3e2aaf7 JW |
8 | |
9 | <authorgroup> | |
10 | <author> | |
11 | <firstname>Jason</firstname> | |
12 | <surname>Wessel</surname> | |
13 | <affiliation> | |
14 | <address> | |
15 | <email>jason.wessel@windriver.com</email> | |
16 | </address> | |
17 | </affiliation> | |
18 | </author> | |
19 | </authorgroup> | |
e3e2aaf7 | 20 | <copyright> |
84c08fd6 | 21 | <year>2008,2010</year> |
e3e2aaf7 JW |
22 | <holder>Wind River Systems, Inc.</holder> |
23 | </copyright> | |
24 | <copyright> | |
25 | <year>2004-2005</year> | |
26 | <holder>MontaVista Software, Inc.</holder> | |
27 | </copyright> | |
28 | <copyright> | |
29 | <year>2004</year> | |
30 | <holder>Amit S. Kale</holder> | |
31 | </copyright> | |
32 | ||
33 | <legalnotice> | |
34 | <para> | |
35 | This file is licensed under the terms of the GNU General Public License | |
36 | version 2. This program is licensed "as is" without any warranty of any | |
37 | kind, whether express or implied. | |
38 | </para> | |
39 | ||
40 | </legalnotice> | |
41 | </bookinfo> | |
42 | ||
43 | <toc></toc> | |
44 | <chapter id="Introduction"> | |
45 | <title>Introduction</title> | |
46 | <para> | |
84c08fd6 JW |
47 | The kernel has two different debugger front ends (kdb and kgdb) |
48 | which interface to the debug core. It is possible to use either | |
49 | of the debugger front ends and dynamically transition between them | |
50 | if you configure the kernel properly at compile and runtime. | |
51 | </para> | |
52 | <para> | |
53 | Kdb is simplistic shell-style interface which you can use on a | |
54 | system console with a keyboard or serial console. You can use it | |
55 | to inspect memory, registers, process lists, dmesg, and even set | |
56 | breakpoints to stop in a certain location. Kdb is not a source | |
57 | level debugger, although you can set breakpoints and execute some | |
58 | basic kernel run control. Kdb is mainly aimed at doing some | |
59 | analysis to aid in development or diagnosing kernel problems. You | |
60 | can access some symbols by name in kernel built-ins or in kernel | |
61 | modules if the code was built | |
62 | with <symbol>CONFIG_KALLSYMS</symbol>. | |
63 | </para> | |
64 | <para> | |
65 | Kgdb is intended to be used as a source level debugger for the | |
66 | Linux kernel. It is used along with gdb to debug a Linux kernel. | |
67 | The expectation is that gdb can be used to "break in" to the | |
68 | kernel to inspect memory, variables and look through call stack | |
69 | information similar to the way an application developer would use | |
70 | gdb to debug an application. It is possible to place breakpoints | |
71 | in kernel code and perform some limited execution stepping. | |
e3e2aaf7 JW |
72 | </para> |
73 | <para> | |
84c08fd6 JW |
74 | Two machines are required for using kgdb. One of these machines is |
75 | a development machine and the other is the target machine. The | |
76 | kernel to be debugged runs on the target machine. The development | |
77 | machine runs an instance of gdb against the vmlinux file which | |
78 | contains the symbols (not boot image such as bzImage, zImage, | |
79 | uImage...). In gdb the developer specifies the connection | |
80 | parameters and connects to kgdb. The type of connection a | |
81 | developer makes with gdb depends on the availability of kgdb I/O | |
82 | modules compiled as built-ins or loadable kernel modules in the test | |
83 | machine's kernel. | |
e3e2aaf7 JW |
84 | </para> |
85 | </chapter> | |
86 | <chapter id="CompilingAKernel"> | |
84c08fd6 JW |
87 | <title>Compiling a kernel</title> |
88 | <para> | |
89 | <itemizedlist> | |
90 | <listitem><para>In order to enable compilation of kdb, you must first enable kgdb.</para></listitem> | |
91 | <listitem><para>The kgdb test compile options are described in the kgdb test suite chapter.</para></listitem> | |
92 | </itemizedlist> | |
93 | </para> | |
94 | <sect1 id="CompileKGDB"> | |
95 | <title>Kernel config options for kgdb</title> | |
e3e2aaf7 | 96 | <para> |
f9250937 | 97 | To enable <symbol>CONFIG_KGDB</symbol> you should first turn on |
98 | "Prompt for development and/or incomplete code/drivers" | |
99 | (CONFIG_EXPERIMENTAL) in "General setup", then under the | |
84c08fd6 JW |
100 | "Kernel debugging" select "KGDB: kernel debugger". |
101 | </para> | |
102 | <para> | |
103 | While it is not a hard requirement that you have symbols in your | |
104 | vmlinux file, gdb tends not to be very useful without the symbolic | |
105 | data, so you will want to turn | |
106 | on <symbol>CONFIG_DEBUG_INFO</symbol> which is called "Compile the | |
107 | kernel with debug info" in the config menu. | |
e3e2aaf7 JW |
108 | </para> |
109 | <para> | |
5f5ddfb3 | 110 | It is advised, but not required that you turn on the |
84c08fd6 JW |
111 | <symbol>CONFIG_FRAME_POINTER</symbol> kernel option which is called "Compile the |
112 | kernel with frame pointers" in the config menu. This option | |
113 | inserts code to into the compiled executable which saves the frame | |
114 | information in registers or on the stack at different points which | |
115 | allows a debugger such as gdb to more accurately construct | |
116 | stack back traces while debugging the kernel. | |
5f5ddfb3 JW |
117 | </para> |
118 | <para> | |
a9b60bf4 JW |
119 | If the architecture that you are using supports the kernel option |
120 | CONFIG_DEBUG_RODATA, you should consider turning it off. This | |
121 | option will prevent the use of software breakpoints because it | |
122 | marks certain regions of the kernel's memory space as read-only. | |
123 | If kgdb supports it for the architecture you are using, you can | |
124 | use hardware breakpoints if you desire to run with the | |
125 | CONFIG_DEBUG_RODATA option turned on, else you need to turn off | |
126 | this option. | |
127 | </para> | |
128 | <para> | |
84c08fd6 JW |
129 | Next you should choose one of more I/O drivers to interconnect |
130 | debugging host and debugged target. Early boot debugging requires | |
131 | a KGDB I/O driver that supports early debugging and the driver | |
132 | must be built into the kernel directly. Kgdb I/O driver | |
133 | configuration takes place via kernel or module parameters which | |
134 | you can learn more about in the in the section that describes the | |
135 | parameter "kgdboc". | |
e3e2aaf7 | 136 | </para> |
84c08fd6 JW |
137 | <para>Here is an example set of .config symbols to enable or |
138 | disable for kgdb: | |
139 | <itemizedlist> | |
140 | <listitem><para># CONFIG_DEBUG_RODATA is not set</para></listitem> | |
141 | <listitem><para>CONFIG_FRAME_POINTER=y</para></listitem> | |
142 | <listitem><para>CONFIG_KGDB=y</para></listitem> | |
143 | <listitem><para>CONFIG_KGDB_SERIAL_CONSOLE=y</para></listitem> | |
144 | </itemizedlist> | |
e3e2aaf7 | 145 | </para> |
84c08fd6 JW |
146 | </sect1> |
147 | <sect1 id="CompileKDB"> | |
148 | <title>Kernel config options for kdb</title> | |
149 | <para>Kdb is quite a bit more complex than the simple gdbstub | |
150 | sitting on top of the kernel's debug core. Kdb must implement a | |
151 | shell, and also adds some helper functions in other parts of the | |
152 | kernel, responsible for printing out interesting data such as what | |
153 | you would see if you ran "lsmod", or "ps". In order to build kdb | |
154 | into the kernel you follow the same steps as you would for kgdb. | |
155 | </para> | |
156 | <para>The main config option for kdb | |
157 | is <symbol>CONFIG_KGDB_KDB</symbol> which is called "KGDB_KDB: | |
158 | include kdb frontend for kgdb" in the config menu. In theory you | |
159 | would have already also selected an I/O driver such as the | |
160 | CONFIG_KGDB_SERIAL_CONSOLE interface if you plan on using kdb on a | |
161 | serial port, when you were configuring kgdb. | |
162 | </para> | |
163 | <para>If you want to use a PS/2-style keyboard with kdb, you would | |
164 | select CONFIG_KDB_KEYBOARD which is called "KGDB_KDB: keyboard as | |
165 | input device" in the config menu. The CONFIG_KDB_KEYBOARD option | |
166 | is not used for anything in the gdb interface to kgdb. The | |
167 | CONFIG_KDB_KEYBOARD option only works with kdb. | |
168 | </para> | |
169 | <para>Here is an example set of .config symbols to enable/disable kdb: | |
170 | <itemizedlist> | |
171 | <listitem><para># CONFIG_DEBUG_RODATA is not set</para></listitem> | |
172 | <listitem><para>CONFIG_FRAME_POINTER=y</para></listitem> | |
173 | <listitem><para>CONFIG_KGDB=y</para></listitem> | |
174 | <listitem><para>CONFIG_KGDB_SERIAL_CONSOLE=y</para></listitem> | |
175 | <listitem><para>CONFIG_KGDB_KDB=y</para></listitem> | |
176 | <listitem><para>CONFIG_KDB_KEYBOARD=y</para></listitem> | |
177 | </itemizedlist> | |
178 | </para> | |
179 | </sect1> | |
e3e2aaf7 | 180 | </chapter> |
84c08fd6 JW |
181 | <chapter id="kgdbKernelArgs"> |
182 | <title>Kernel Debugger Boot Arguments</title> | |
183 | <para>This section describes the various runtime kernel | |
184 | parameters that affect the configuration of the kernel debugger. | |
185 | The following chapter covers using kdb and kgdb as well as | |
186 | provides some examples of the configuration parameters.</para> | |
187 | <sect1 id="kgdboc"> | |
188 | <title>Kernel parameter: kgdboc</title> | |
189 | <para>The kgdboc driver was originally an abbreviation meant to | |
190 | stand for "kgdb over console". Today it is the primary mechanism | |
191 | to configure how to communicate from gdb to kgdb as well as the | |
192 | devices you want to use to interact with the kdb shell. | |
193 | </para> | |
194 | <para>For kgdb/gdb, kgdboc is designed to work with a single serial | |
195 | port. It is intended to cover the circumstance where you want to | |
196 | use a serial console as your primary console as well as using it to | |
197 | perform kernel debugging. It is also possible to use kgdb on a | |
198 | serial port which is not designated as a system console. Kgdboc | |
199 | may be configured as a kernel built-in or a kernel loadable module. | |
200 | You can only make use of <constant>kgdbwait</constant> and early | |
201 | debugging if you build kgdboc into the kernel as a built-in. | |
65b5ac14 JW |
202 | <para>Optionally you can elect to activate kms (Kernel Mode |
203 | Setting) integration. When you use kms with kgdboc and you have a | |
204 | video driver that has atomic mode setting hooks, it is possible to | |
205 | enter the debugger on the graphics console. When the kernel | |
206 | execution is resumed, the previous graphics mode will be restored. | |
207 | This integration can serve as a useful tool to aid in diagnosing | |
208 | crashes or doing analysis of memory with kdb while allowing the | |
209 | full graphics console applications to run. | |
210 | </para> | |
e3e2aaf7 | 211 | </para> |
84c08fd6 JW |
212 | <sect2 id="kgdbocArgs"> |
213 | <title>kgdboc arguments</title> | |
65b5ac14 JW |
214 | <para>Usage: <constant>kgdboc=[kms][[,]kbd][[,]serial_device][,baud]</constant></para> |
215 | <para>The order listed above must be observed if you use any of the | |
216 | optional configurations together. | |
217 | </para> | |
218 | <para>Abbreviations: | |
219 | <itemizedlist> | |
220 | <listitem><para>kms = Kernel Mode Setting</para></listitem> | |
221 | <listitem><para>kbd = Keyboard</para></listitem> | |
222 | </itemizedlist> | |
223 | </para> | |
224 | <para>You can configure kgdboc to use the keyboard, and or a serial | |
225 | device depending on if you are using kdb and or kgdb, in one of the | |
226 | following scenarios. The order listed above must be observed if | |
227 | you use any of the optional configurations together. Using kms + | |
228 | only gdb is generally not a useful combination.</para> | |
84c08fd6 JW |
229 | <sect3 id="kgdbocArgs1"> |
230 | <title>Using loadable module or built-in</title> | |
e3e2aaf7 | 231 | <para> |
84c08fd6 JW |
232 | <orderedlist> |
233 | <listitem><para>As a kernel built-in:</para> | |
234 | <para>Use the kernel boot argument: <constant>kgdboc=<tty-device>,[baud]</constant></para></listitem> | |
235 | <listitem> | |
236 | <para>As a kernel loadable module:</para> | |
237 | <para>Use the command: <constant>modprobe kgdboc kgdboc=<tty-device>,[baud]</constant></para> | |
65b5ac14 | 238 | <para>Here are two examples of how you might format the kgdboc |
84c08fd6 JW |
239 | string. The first is for an x86 target using the first serial port. |
240 | The second example is for the ARM Versatile AB using the second | |
241 | serial port. | |
242 | <orderedlist> | |
243 | <listitem><para><constant>kgdboc=ttyS0,115200</constant></para></listitem> | |
244 | <listitem><para><constant>kgdboc=ttyAMA1,115200</constant></para></listitem> | |
245 | </orderedlist> | |
e3e2aaf7 | 246 | </para> |
84c08fd6 JW |
247 | </listitem> |
248 | </orderedlist></para> | |
249 | </sect3> | |
250 | <sect3 id="kgdbocArgs2"> | |
251 | <title>Configure kgdboc at runtime with sysfs</title> | |
252 | <para>At run time you can enable or disable kgdboc by echoing a | |
253 | parameters into the sysfs. Here are two examples:</para> | |
254 | <orderedlist> | |
255 | <listitem><para>Enable kgdboc on ttyS0</para> | |
256 | <para><constant>echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem> | |
257 | <listitem><para>Disable kgdboc</para> | |
258 | <para><constant>echo "" > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem> | |
259 | </orderedlist> | |
260 | <para>NOTE: You do not need to specify the baud if you are | |
261 | configuring the console on tty which is already configured or | |
262 | open.</para> | |
263 | </sect3> | |
264 | <sect3 id="kgdbocArgs3"> | |
265 | <title>More examples</title> | |
65b5ac14 JW |
266 | <para>You can configure kgdboc to use the keyboard, and or a serial |
267 | device depending on if you are using kdb and or kgdb, in one of the | |
268 | following scenarios.</para> | |
84c08fd6 JW |
269 | <para>You can configure kgdboc to use the keyboard, and or a serial device |
270 | depending on if you are using kdb and or kgdb, in one of the | |
271 | following scenarios. | |
272 | <orderedlist> | |
273 | <listitem><para>kdb and kgdb over only a serial port</para> | |
274 | <para><constant>kgdboc=<serial_device>[,baud]</constant></para> | |
275 | <para>Example: <constant>kgdboc=ttyS0,115200</constant></para> | |
276 | </listitem> | |
277 | <listitem><para>kdb and kgdb with keyboard and a serial port</para> | |
278 | <para><constant>kgdboc=kbd,<serial_device>[,baud]</constant></para> | |
279 | <para>Example: <constant>kgdboc=kbd,ttyS0,115200</constant></para> | |
280 | </listitem> | |
281 | <listitem><para>kdb with a keyboard</para> | |
282 | <para><constant>kgdboc=kbd</constant></para> | |
283 | </listitem> | |
65b5ac14 JW |
284 | <listitem><para>kdb with kernel mode setting</para> |
285 | <para><constant>kgdboc=kms,kbd</constant></para> | |
286 | </listitem> | |
287 | <listitem><para>kdb with kernel mode setting and kgdb over a serial port</para> | |
288 | <para><constant>kgdboc=kms,kbd,ttyS0,115200</constant></para> | |
289 | </listitem> | |
84c08fd6 JW |
290 | </orderedlist> |
291 | </para> | |
292 | </sect3> | |
293 | <para>NOTE: Kgdboc does not support interrupting the target via the | |
294 | gdb remote protocol. You must manually send a sysrq-g unless you | |
295 | have a proxy that splits console output to a terminal program. | |
296 | A console proxy has a separate TCP port for the debugger and a separate | |
297 | TCP port for the "human" console. The proxy can take care of sending | |
298 | the sysrq-g for you. | |
299 | </para> | |
300 | <para>When using kgdboc with no debugger proxy, you can end up | |
301 | connecting the debugger at one of two entry points. If an | |
302 | exception occurs after you have loaded kgdboc, a message should | |
303 | print on the console stating it is waiting for the debugger. In | |
304 | this case you disconnect your terminal program and then connect the | |
305 | debugger in its place. If you want to interrupt the target system | |
306 | and forcibly enter a debug session you have to issue a Sysrq | |
307 | sequence and then type the letter <constant>g</constant>. Then | |
308 | you disconnect the terminal session and connect gdb. Your options | |
309 | if you don't like this are to hack gdb to send the sysrq-g for you | |
310 | as well as on the initial connect, or to use a debugger proxy that | |
311 | allows an unmodified gdb to do the debugging. | |
312 | </para> | |
313 | </sect2> | |
314 | </sect1> | |
e3e2aaf7 JW |
315 | <sect1 id="kgdbwait"> |
316 | <title>Kernel parameter: kgdbwait</title> | |
317 | <para> | |
318 | The Kernel command line option <constant>kgdbwait</constant> makes | |
319 | kgdb wait for a debugger connection during booting of a kernel. You | |
320 | can only use this option you compiled a kgdb I/O driver into the | |
321 | kernel and you specified the I/O driver configuration as a kernel | |
322 | command line option. The kgdbwait parameter should always follow the | |
323 | configuration parameter for the kgdb I/O driver in the kernel | |
324 | command line else the I/O driver will not be configured prior to | |
325 | asking the kernel to use it to wait. | |
326 | </para> | |
327 | <para> | |
328 | The kernel will stop and wait as early as the I/O driver and | |
84c08fd6 JW |
329 | architecture allows when you use this option. If you build the |
330 | kgdb I/O driver as a loadable kernel module kgdbwait will not do | |
331 | anything. | |
e3e2aaf7 JW |
332 | </para> |
333 | </sect1> | |
84c08fd6 JW |
334 | <sect1 id="kgdbcon"> |
335 | <title>Kernel parameter: kgdbcon</title> | |
336 | <para> The kgdbcon feature allows you to see printk() messages | |
337 | inside gdb while gdb is connected to the kernel. Kdb does not make | |
338 | use of the kgdbcon feature. | |
339 | </para> | |
340 | <para>Kgdb supports using the gdb serial protocol to send console | |
341 | messages to the debugger when the debugger is connected and running. | |
342 | There are two ways to activate this feature. | |
343 | <orderedlist> | |
344 | <listitem><para>Activate with the kernel command line option:</para> | |
345 | <para><constant>kgdbcon</constant></para> | |
346 | </listitem> | |
347 | <listitem><para>Use sysfs before configuring an I/O driver</para> | |
348 | <para> | |
349 | <constant>echo 1 > /sys/module/kgdb/parameters/kgdb_use_con</constant> | |
350 | </para> | |
351 | <para> | |
352 | NOTE: If you do this after you configure the kgdb I/O driver, the | |
353 | setting will not take effect until the next point the I/O is | |
354 | reconfigured. | |
355 | </para> | |
356 | </listitem> | |
357 | </orderedlist> | |
358 | <para>IMPORTANT NOTE: You cannot use kgdboc + kgdbcon on a tty that is an | |
359 | active system console. An example incorrect usage is <constant>console=ttyS0,115200 kgdboc=ttyS0 kgdbcon</constant> | |
360 | </para> | |
361 | <para>It is possible to use this option with kgdboc on a tty that is not a system console. | |
362 | </para> | |
e3e2aaf7 | 363 | </para> |
84c08fd6 JW |
364 | </sect1> |
365 | </chapter> | |
366 | <chapter id="usingKDB"> | |
367 | <title>Using kdb</title> | |
e3e2aaf7 | 368 | <para> |
84c08fd6 JW |
369 | </para> |
370 | <sect1 id="quickKDBserial"> | |
371 | <title>Quick start for kdb on a serial port</title> | |
372 | <para>This is a quick example of how to use kdb.</para> | |
373 | <para><orderedlist> | |
374 | <listitem><para>Boot kernel with arguments: | |
375 | <itemizedlist> | |
376 | <listitem><para><constant>console=ttyS0,115200 kgdboc=ttyS0,115200</constant></para></listitem> | |
377 | </itemizedlist></para> | |
378 | <para>OR</para> | |
379 | <para>Configure kgdboc after the kernel booted; assuming you are using a serial port console: | |
380 | <itemizedlist> | |
381 | <listitem><para><constant>echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem> | |
382 | </itemizedlist> | |
e3e2aaf7 JW |
383 | </para> |
384 | </listitem> | |
84c08fd6 JW |
385 | <listitem><para>Enter the kernel debugger manually or by waiting for an oops or fault. There are several ways you can enter the kernel debugger manually; all involve using the sysrq-g, which means you must have enabled CONFIG_MAGIC_SYSRQ=y in your kernel config.</para> |
386 | <itemizedlist> | |
387 | <listitem><para>When logged in as root or with a super user session you can run:</para> | |
388 | <para><constant>echo g > /proc/sysrq-trigger</constant></para></listitem> | |
389 | <listitem><para>Example using minicom 2.2</para> | |
390 | <para>Press: <constant>Control-a</constant></para> | |
391 | <para>Press: <constant>f</constant></para> | |
392 | <para>Press: <constant>g</constant></para> | |
e3e2aaf7 | 393 | </listitem> |
84c08fd6 JW |
394 | <listitem><para>When you have telneted to a terminal server that supports sending a remote break</para> |
395 | <para>Press: <constant>Control-]</constant></para> | |
396 | <para>Type in:<constant>send break</constant></para> | |
397 | <para>Press: <constant>Enter</constant></para> | |
398 | <para>Press: <constant>g</constant></para> | |
399 | </listitem> | |
400 | </itemizedlist> | |
401 | </listitem> | |
402 | <listitem><para>From the kdb prompt you can run the "help" command to see a complete list of the commands that are available.</para> | |
403 | <para>Some useful commands in kdb include: | |
404 | <itemizedlist> | |
405 | <listitem><para>lsmod -- Shows where kernel modules are loaded</para></listitem> | |
406 | <listitem><para>ps -- Displays only the active processes</para></listitem> | |
407 | <listitem><para>ps A -- Shows all the processes</para></listitem> | |
408 | <listitem><para>summary -- Shows kernel version info and memory usage</para></listitem> | |
409 | <listitem><para>bt -- Get a backtrace of the current process using dump_stack()</para></listitem> | |
410 | <listitem><para>dmesg -- View the kernel syslog buffer</para></listitem> | |
411 | <listitem><para>go -- Continue the system</para></listitem> | |
412 | </itemizedlist> | |
e3e2aaf7 | 413 | </para> |
84c08fd6 JW |
414 | </listitem> |
415 | <listitem> | |
416 | <para>When you are done using kdb you need to consider rebooting the | |
417 | system or using the "go" command to resuming normal kernel | |
418 | execution. If you have paused the kernel for a lengthy period of | |
419 | time, applications that rely on timely networking or anything to do | |
420 | with real wall clock time could be adversely affected, so you | |
421 | should take this into consideration when using the kernel | |
422 | debugger.</para> | |
423 | </listitem> | |
424 | </orderedlist></para> | |
425 | </sect1> | |
426 | <sect1 id="quickKDBkeyboard"> | |
427 | <title>Quick start for kdb using a keyboard connected console</title> | |
428 | <para>This is a quick example of how to use kdb with a keyboard.</para> | |
429 | <para><orderedlist> | |
430 | <listitem><para>Boot kernel with arguments: | |
431 | <itemizedlist> | |
432 | <listitem><para><constant>kgdboc=kbd</constant></para></listitem> | |
433 | </itemizedlist></para> | |
434 | <para>OR</para> | |
435 | <para>Configure kgdboc after the kernel booted: | |
436 | <itemizedlist> | |
437 | <listitem><para><constant>echo kbd > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem> | |
438 | </itemizedlist> | |
e3e2aaf7 | 439 | </para> |
84c08fd6 JW |
440 | </listitem> |
441 | <listitem><para>Enter the kernel debugger manually or by waiting for an oops or fault. There are several ways you can enter the kernel debugger manually; all involve using the sysrq-g, which means you must have enabled CONFIG_MAGIC_SYSRQ=y in your kernel config.</para> | |
442 | <itemizedlist> | |
443 | <listitem><para>When logged in as root or with a super user session you can run:</para> | |
444 | <para><constant>echo g > /proc/sysrq-trigger</constant></para></listitem> | |
445 | <listitem><para>Example using a laptop keyboard</para> | |
446 | <para>Press and hold down: <constant>Alt</constant></para> | |
447 | <para>Press and hold down: <constant>Fn</constant></para> | |
448 | <para>Press and release the key with the label: <constant>SysRq</constant></para> | |
449 | <para>Release: <constant>Fn</constant></para> | |
450 | <para>Press and release: <constant>g</constant></para> | |
451 | <para>Release: <constant>Alt</constant></para> | |
452 | </listitem> | |
453 | <listitem><para>Example using a PS/2 101-key keyboard</para> | |
454 | <para>Press and hold down: <constant>Alt</constant></para> | |
455 | <para>Press and release the key with the label: <constant>SysRq</constant></para> | |
456 | <para>Press and release: <constant>g</constant></para> | |
457 | <para>Release: <constant>Alt</constant></para> | |
458 | </listitem> | |
459 | </itemizedlist> | |
460 | </listitem> | |
461 | <listitem> | |
462 | <para>Now type in a kdb command such as "help", "dmesg", "bt" or "go" to continue kernel execution.</para> | |
463 | </listitem> | |
464 | </orderedlist></para> | |
e3e2aaf7 | 465 | </sect1> |
84c08fd6 JW |
466 | </chapter> |
467 | <chapter id="EnableKGDB"> | |
468 | <title>Using kgdb / gdb</title> | |
469 | <para>In order to use kgdb you must activate it by passing | |
470 | configuration information to one of the kgdb I/O drivers. If you | |
471 | do not pass any configuration information kgdb will not do anything | |
472 | at all. Kgdb will only actively hook up to the kernel trap hooks | |
473 | if a kgdb I/O driver is loaded and configured. If you unconfigure | |
474 | a kgdb I/O driver, kgdb will unregister all the kernel hook points. | |
475 | </para> | |
476 | <para> All kgdb I/O drivers can be reconfigured at run time, if | |
477 | <symbol>CONFIG_SYSFS</symbol> and <symbol>CONFIG_MODULES</symbol> | |
478 | are enabled, by echo'ing a new config string to | |
479 | <constant>/sys/module/<driver>/parameter/<option></constant>. | |
480 | The driver can be unconfigured by passing an empty string. You cannot | |
481 | change the configuration while the debugger is attached. Make sure | |
482 | to detach the debugger with the <constant>detach</constant> command | |
483 | prior to trying to unconfigure a kgdb I/O driver. | |
484 | </para> | |
485 | <sect1 id="ConnectingGDB"> | |
486 | <title>Connecting with gdb to a serial port</title> | |
e3e2aaf7 | 487 | <orderedlist> |
84c08fd6 JW |
488 | <listitem><para>Configure kgdboc</para> |
489 | <para>Boot kernel with arguments: | |
490 | <itemizedlist> | |
491 | <listitem><para><constant>kgdboc=ttyS0,115200</constant></para></listitem> | |
492 | </itemizedlist></para> | |
493 | <para>OR</para> | |
494 | <para>Configure kgdboc after the kernel booted: | |
495 | <itemizedlist> | |
496 | <listitem><para><constant>echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc</constant></para></listitem> | |
497 | </itemizedlist></para> | |
e3e2aaf7 | 498 | </listitem> |
84c08fd6 JW |
499 | <listitem> |
500 | <para>Stop kernel execution (break into the debugger)</para> | |
501 | <para>In order to connect to gdb via kgdboc, the kernel must | |
502 | first be stopped. There are several ways to stop the kernel which | |
503 | include using kgdbwait as a boot argument, via a sysrq-g, or running | |
504 | the kernel until it takes an exception where it waits for the | |
505 | debugger to attach. | |
506 | <itemizedlist> | |
507 | <listitem><para>When logged in as root or with a super user session you can run:</para> | |
508 | <para><constant>echo g > /proc/sysrq-trigger</constant></para></listitem> | |
509 | <listitem><para>Example using minicom 2.2</para> | |
510 | <para>Press: <constant>Control-a</constant></para> | |
511 | <para>Press: <constant>f</constant></para> | |
512 | <para>Press: <constant>g</constant></para> | |
e3e2aaf7 | 513 | </listitem> |
84c08fd6 JW |
514 | <listitem><para>When you have telneted to a terminal server that supports sending a remote break</para> |
515 | <para>Press: <constant>Control-]</constant></para> | |
516 | <para>Type in:<constant>send break</constant></para> | |
517 | <para>Press: <constant>Enter</constant></para> | |
518 | <para>Press: <constant>g</constant></para> | |
519 | </listitem> | |
520 | </itemizedlist> | |
e3e2aaf7 | 521 | </para> |
84c08fd6 JW |
522 | </listitem> |
523 | <listitem> | |
524 | <para>Connect from from gdb</para> | |
e3e2aaf7 | 525 | <para> |
84c08fd6 | 526 | Example (using a directly connected port): |
e3e2aaf7 JW |
527 | </para> |
528 | <programlisting> | |
529 | % gdb ./vmlinux | |
530 | (gdb) set remotebaud 115200 | |
531 | (gdb) target remote /dev/ttyS0 | |
532 | </programlisting> | |
533 | <para> | |
84c08fd6 | 534 | Example (kgdb to a terminal server on TCP port 2012): |
e3e2aaf7 JW |
535 | </para> |
536 | <programlisting> | |
537 | % gdb ./vmlinux | |
a606b5e2 | 538 | (gdb) target remote 192.168.2.2:2012 |
e3e2aaf7 JW |
539 | </programlisting> |
540 | <para> | |
541 | Once connected, you can debug a kernel the way you would debug an | |
542 | application program. | |
543 | </para> | |
544 | <para> | |
545 | If you are having problems connecting or something is going | |
546 | seriously wrong while debugging, it will most often be the case | |
547 | that you want to enable gdb to be verbose about its target | |
548 | communications. You do this prior to issuing the <constant>target | |
d34a792d | 549 | remote</constant> command by typing in: <constant>set debug remote 1</constant> |
e3e2aaf7 | 550 | </para> |
84c08fd6 JW |
551 | </listitem> |
552 | </orderedlist> | |
553 | <para>Remember if you continue in gdb, and need to "break in" again, | |
554 | you need to issue an other sysrq-g. It is easy to create a simple | |
555 | entry point by putting a breakpoint at <constant>sys_sync</constant> | |
556 | and then you can run "sync" from a shell or script to break into the | |
557 | debugger.</para> | |
558 | </sect1> | |
559 | </chapter> | |
560 | <chapter id="switchKdbKgdb"> | |
561 | <title>kgdb and kdb interoperability</title> | |
562 | <para>It is possible to transition between kdb and kgdb dynamically. | |
563 | The debug core will remember which you used the last time and | |
564 | automatically start in the same mode.</para> | |
565 | <sect1> | |
566 | <title>Switching between kdb and kgdb</title> | |
567 | <sect2> | |
568 | <title>Switching from kgdb to kdb</title> | |
569 | <para> | |
570 | There are two ways to switch from kgdb to kdb: you can use gdb to | |
571 | issue a maintenance packet, or you can blindly type the command $3#33. | |
572 | Whenever kernel debugger stops in kgdb mode it will print the | |
573 | message <constant>KGDB or $3#33 for KDB</constant>. It is important | |
574 | to note that you have to type the sequence correctly in one pass. | |
575 | You cannot type a backspace or delete because kgdb will interpret | |
576 | that as part of the debug stream. | |
577 | <orderedlist> | |
578 | <listitem><para>Change from kgdb to kdb by blindly typing:</para> | |
579 | <para><constant>$3#33</constant></para></listitem> | |
580 | <listitem><para>Change from kgdb to kdb with gdb</para> | |
581 | <para><constant>maintenance packet 3</constant></para> | |
582 | <para>NOTE: Now you must kill gdb. Typically you press control-z and | |
583 | issue the command: kill -9 %</para></listitem> | |
584 | </orderedlist> | |
585 | </para> | |
586 | </sect2> | |
587 | <sect2> | |
588 | <title>Change from kdb to kgdb</title> | |
589 | <para>There are two ways you can change from kdb to kgdb. You can | |
590 | manually enter kgdb mode by issuing the kgdb command from the kdb | |
591 | shell prompt, or you can connect gdb while the kdb shell prompt is | |
592 | active. The kdb shell looks for the typical first commands that gdb | |
593 | would issue with the gdb remote protocol and if it sees one of those | |
594 | commands it automatically changes into kgdb mode.</para> | |
595 | <orderedlist> | |
596 | <listitem><para>From kdb issue the command:</para> | |
597 | <para><constant>kgdb</constant></para> | |
598 | <para>Now disconnect your terminal program and connect gdb in its place</para></listitem> | |
599 | <listitem><para>At the kdb prompt, disconnect the terminal program and connect gdb in its place.</para></listitem> | |
600 | </orderedlist> | |
601 | </sect2> | |
602 | </sect1> | |
603 | <sect1> | |
604 | <title>Running kdb commands from gdb</title> | |
605 | <para>It is possible to run a limited set of kdb commands from gdb, | |
606 | using the gdb monitor command. You don't want to execute any of the | |
607 | run control or breakpoint operations, because it can disrupt the | |
608 | state of the kernel debugger. You should be using gdb for | |
609 | breakpoints and run control operations if you have gdb connected. | |
610 | The more useful commands to run are things like lsmod, dmesg, ps or | |
611 | possibly some of the memory information commands. To see all the kdb | |
612 | commands you can run <constant>monitor help</constant>.</para> | |
613 | <para>Example: | |
614 | <informalexample><programlisting> | |
615 | (gdb) monitor ps | |
616 | 1 idle process (state I) and | |
617 | 27 sleeping system daemon (state M) processes suppressed, | |
618 | use 'ps A' to see all. | |
619 | Task Addr Pid Parent [*] cpu State Thread Command | |
620 | ||
621 | 0xc78291d0 1 0 0 0 S 0xc7829404 init | |
622 | 0xc7954150 942 1 0 0 S 0xc7954384 dropbear | |
623 | 0xc78789c0 944 1 0 0 S 0xc7878bf4 sh | |
624 | (gdb) | |
625 | </programlisting></informalexample> | |
626 | </para> | |
627 | </sect1> | |
e3e2aaf7 JW |
628 | </chapter> |
629 | <chapter id="KGDBTestSuite"> | |
630 | <title>kgdb Test Suite</title> | |
631 | <para> | |
632 | When kgdb is enabled in the kernel config you can also elect to | |
633 | enable the config parameter KGDB_TESTS. Turning this on will | |
634 | enable a special kgdb I/O module which is designed to test the | |
635 | kgdb internal functions. | |
636 | </para> | |
637 | <para> | |
638 | The kgdb tests are mainly intended for developers to test the kgdb | |
639 | internals as well as a tool for developing a new kgdb architecture | |
640 | specific implementation. These tests are not really for end users | |
641 | of the Linux kernel. The primary source of documentation would be | |
642 | to look in the drivers/misc/kgdbts.c file. | |
643 | </para> | |
644 | <para> | |
645 | The kgdb test suite can also be configured at compile time to run | |
646 | the core set of tests by setting the kernel config parameter | |
647 | KGDB_TESTS_ON_BOOT. This particular option is aimed at automated | |
648 | regression testing and does not require modifying the kernel boot | |
649 | config arguments. If this is turned on, the kgdb test suite can | |
650 | be disabled by specifying "kgdbts=" as a kernel boot argument. | |
651 | </para> | |
652 | </chapter> | |
653 | <chapter id="CommonBackEndReq"> | |
84c08fd6 | 654 | <title>Kernel Debugger Internals</title> |
225a4424 | 655 | <sect1 id="kgdbArchitecture"> |
e3e2aaf7 JW |
656 | <title>Architecture Specifics</title> |
657 | <para> | |
84c08fd6 | 658 | The kernel debugger is organized into a number of components: |
e3e2aaf7 | 659 | <orderedlist> |
84c08fd6 | 660 | <listitem><para>The debug core</para> |
e3e2aaf7 | 661 | <para> |
84c08fd6 | 662 | The debug core is found in kernel/debugger/debug_core.c. It contains: |
e3e2aaf7 | 663 | <itemizedlist> |
84c08fd6 JW |
664 | <listitem><para>A generic OS exception handler which includes |
665 | sync'ing the processors into a stopped state on an multi-CPU | |
666 | system.</para></listitem> | |
e3e2aaf7 | 667 | <listitem><para>The API to talk to the kgdb I/O drivers</para></listitem> |
84c08fd6 | 668 | <listitem><para>The API to make calls to the arch-specific kgdb implementation</para></listitem> |
e3e2aaf7 JW |
669 | <listitem><para>The logic to perform safe memory reads and writes to memory while using the debugger</para></listitem> |
670 | <listitem><para>A full implementation for software breakpoints unless overridden by the arch</para></listitem> | |
84c08fd6 | 671 | <listitem><para>The API to invoke either the kdb or kgdb frontend to the debug core.</para></listitem> |
65b5ac14 JW |
672 | <listitem><para>The structures and callback API for atomic kernel mode setting.</para> |
673 | <para>NOTE: kgdboc is where the kms callbacks are invoked.</para></listitem> | |
e3e2aaf7 JW |
674 | </itemizedlist> |
675 | </para> | |
676 | </listitem> | |
84c08fd6 | 677 | <listitem><para>kgdb arch-specific implementation</para> |
e3e2aaf7 JW |
678 | <para> |
679 | This implementation is generally found in arch/*/kernel/kgdb.c. | |
680 | As an example, arch/x86/kernel/kgdb.c contains the specifics to | |
681 | implement HW breakpoint as well as the initialization to | |
682 | dynamically register and unregister for the trap handlers on | |
84c08fd6 | 683 | this architecture. The arch-specific portion implements: |
e3e2aaf7 | 684 | <itemizedlist> |
84c08fd6 | 685 | <listitem><para>contains an arch-specific trap catcher which |
e3e2aaf7 JW |
686 | invokes kgdb_handle_exception() to start kgdb about doing its |
687 | work</para></listitem> | |
688 | <listitem><para>translation to and from gdb specific packet format to pt_regs</para></listitem> | |
689 | <listitem><para>Registration and unregistration of architecture specific trap hooks</para></listitem> | |
690 | <listitem><para>Any special exception handling and cleanup</para></listitem> | |
691 | <listitem><para>NMI exception handling and cleanup</para></listitem> | |
692 | <listitem><para>(optional)HW breakpoints</para></listitem> | |
693 | </itemizedlist> | |
694 | </para> | |
695 | </listitem> | |
84c08fd6 JW |
696 | <listitem><para>gdbstub frontend (aka kgdb)</para> |
697 | <para>The gdbstub is located in kernel/debug/gdbstub.c. It contains:</para> | |
698 | <itemizedlist> | |
699 | <listitem><para>All the logic to implement the gdb serial protocol</para></listitem> | |
700 | </itemizedlist> | |
701 | </listitem> | |
702 | <listitem><para>kdb frontend</para> | |
703 | <para>The kdb debugger shell is broken down into a number of | |
704 | components. The kdb core is located in kernel/debug/kdb. There | |
705 | are a number of helper functions in some of the other kernel | |
706 | components to make it possible for kdb to examine and report | |
707 | information about the kernel without taking locks that could | |
708 | cause a kernel deadlock. The kdb core contains implements the following functionality.</para> | |
709 | <itemizedlist> | |
710 | <listitem><para>A simple shell</para></listitem> | |
711 | <listitem><para>The kdb core command set</para></listitem> | |
712 | <listitem><para>A registration API to register additional kdb shell commands.</para> | |
4aad8f51 JW |
713 | <itemizedlist> |
714 | <listitem><para>A good example of a self-contained kdb module | |
715 | is the "ftdump" command for dumping the ftrace buffer. See: | |
716 | kernel/trace/trace_kdb.c</para></listitem> | |
717 | <listitem><para>For an example of how to dynamically register | |
718 | a new kdb command you can build the kdb_hello.ko kernel module | |
719 | from samples/kdb/kdb_hello.c. To build this example you can | |
720 | set CONFIG_SAMPLES=y and CONFIG_SAMPLE_KDB=m in your kernel | |
721 | config. Later run "modprobe kdb_hello" and the next time you | |
722 | enter the kdb shell, you can run the "hello" | |
723 | command.</para></listitem> | |
724 | </itemizedlist></listitem> | |
84c08fd6 JW |
725 | <listitem><para>The implementation for kdb_printf() which |
726 | emits messages directly to I/O drivers, bypassing the kernel | |
727 | log.</para></listitem> | |
728 | <listitem><para>SW / HW breakpoint management for the kdb shell</para></listitem> | |
729 | </itemizedlist> | |
730 | </listitem> | |
e3e2aaf7 JW |
731 | <listitem><para>kgdb I/O driver</para> |
732 | <para> | |
84c08fd6 | 733 | Each kgdb I/O driver has to provide an implementation for the following: |
225a4424 | 734 | <itemizedlist> |
84c08fd6 | 735 | <listitem><para>configuration via built-in or module</para></listitem> |
225a4424 JW |
736 | <listitem><para>dynamic configuration and kgdb hook registration calls</para></listitem> |
737 | <listitem><para>read and write character interface</para></listitem> | |
738 | <listitem><para>A cleanup handler for unconfiguring from the kgdb core</para></listitem> | |
739 | <listitem><para>(optional) Early debug methodology</para></listitem> | |
740 | </itemizedlist> | |
741 | Any given kgdb I/O driver has to operate very closely with the | |
742 | hardware and must do it in such a way that does not enable | |
743 | interrupts or change other parts of the system context without | |
744 | completely restoring them. The kgdb core will repeatedly "poll" | |
745 | a kgdb I/O driver for characters when it needs input. The I/O | |
746 | driver is expected to return immediately if there is no data | |
747 | available. Doing so allows for the future possibility to touch | |
748 | watch dog hardware in such a way as to have a target system not | |
749 | reset when these are enabled. | |
e3e2aaf7 JW |
750 | </para> |
751 | </listitem> | |
752 | </orderedlist> | |
753 | </para> | |
754 | <para> | |
755 | If you are intent on adding kgdb architecture specific support | |
756 | for a new architecture, the architecture should define | |
757 | <constant>HAVE_ARCH_KGDB</constant> in the architecture specific | |
758 | Kconfig file. This will enable kgdb for the architecture, and | |
759 | at that point you must create an architecture specific kgdb | |
760 | implementation. | |
761 | </para> | |
762 | <para> | |
763 | There are a few flags which must be set on every architecture in | |
764 | their <asm/kgdb.h> file. These are: | |
765 | <itemizedlist> | |
766 | <listitem> | |
767 | <para> | |
768 | NUMREGBYTES: The size in bytes of all of the registers, so | |
769 | that we can ensure they will all fit into a packet. | |
770 | </para> | |
771 | <para> | |
772 | BUFMAX: The size in bytes of the buffer GDB will read into. | |
773 | This must be larger than NUMREGBYTES. | |
774 | </para> | |
775 | <para> | |
776 | CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call | |
777 | flush_cache_range or flush_icache_range. On some architectures, | |
778 | these functions may not be safe to call on SMP since we keep other | |
779 | CPUs in a holding pattern. | |
780 | </para> | |
781 | </listitem> | |
782 | </itemizedlist> | |
783 | </para> | |
784 | <para> | |
785 | There are also the following functions for the common backend, | |
786 | found in kernel/kgdb.c, that must be supplied by the | |
787 | architecture-specific backend unless marked as (optional), in | |
788 | which case a default function maybe used if the architecture | |
789 | does not need to provide a specific implementation. | |
790 | </para> | |
791 | !Iinclude/linux/kgdb.h | |
225a4424 JW |
792 | </sect1> |
793 | <sect1 id="kgdbocDesign"> | |
794 | <title>kgdboc internals</title> | |
65b5ac14 JW |
795 | <sect2> |
796 | <title>kgdboc and uarts</title> | |
225a4424 JW |
797 | <para> |
798 | The kgdboc driver is actually a very thin driver that relies on the | |
799 | underlying low level to the hardware driver having "polling hooks" | |
800 | which the to which the tty driver is attached. In the initial | |
801 | implementation of kgdboc it the serial_core was changed to expose a | |
84c08fd6 | 802 | low level UART hook for doing polled mode reading and writing of a |
225a4424 | 803 | single character while in an atomic context. When kgdb makes an I/O |
65b5ac14 JW |
804 | request to the debugger, kgdboc invokes a callback in the serial |
805 | core which in turn uses the callback in the UART driver.</para> | |
225a4424 | 806 | <para> |
84c08fd6 | 807 | When using kgdboc with a UART, the UART driver must implement two callbacks in the <constant>struct uart_ops</constant>. Example from drivers/8250.c:<programlisting> |
225a4424 JW |
808 | #ifdef CONFIG_CONSOLE_POLL |
809 | .poll_get_char = serial8250_get_poll_char, | |
810 | .poll_put_char = serial8250_put_poll_char, | |
811 | #endif | |
812 | </programlisting> | |
813 | Any implementation specifics around creating a polling driver use the | |
814 | <constant>#ifdef CONFIG_CONSOLE_POLL</constant>, as shown above. | |
815 | Keep in mind that polling hooks have to be implemented in such a way | |
816 | that they can be called from an atomic context and have to restore | |
84c08fd6 | 817 | the state of the UART chip on return such that the system can return |
225a4424 | 818 | to normal when the debugger detaches. You need to be very careful |
65b5ac14 | 819 | with any kind of lock you consider, because failing here is most likely |
225a4424 JW |
820 | going to mean pressing the reset button. |
821 | </para> | |
65b5ac14 JW |
822 | </sect2> |
823 | <sect2 id="kgdbocKbd"> | |
824 | <title>kgdboc and keyboards</title> | |
825 | <para>The kgdboc driver contains logic to configure communications | |
826 | with an attached keyboard. The keyboard infrastructure is only | |
827 | compiled into the kernel when CONFIG_KDB_KEYBOARD=y is set in the | |
828 | kernel configuration.</para> | |
829 | <para>The core polled keyboard driver driver for PS/2 type keyboards | |
830 | is in drivers/char/kdb_keyboard.c. This driver is hooked into the | |
831 | debug core when kgdboc populates the callback in the array | |
832 | called <constant>kdb_poll_funcs[]</constant>. The | |
833 | kdb_get_kbd_char() is the top-level function which polls hardware | |
834 | for single character input. | |
835 | </para> | |
836 | </sect2> | |
837 | <sect2 id="kgdbocKms"> | |
838 | <title>kgdboc and kms</title> | |
839 | <para>The kgdboc driver contains logic to request the graphics | |
840 | display to switch to a text context when you are using | |
841 | "kgdboc=kms,kbd", provided that you have a video driver which has a | |
842 | frame buffer console and atomic kernel mode setting support.</para> | |
843 | <para> | |
844 | Every time the kernel | |
845 | debugger is entered it calls kgdboc_pre_exp_handler() which in turn | |
846 | calls con_debug_enter() in the virtual console layer. On resuming kernel | |
847 | execution, the kernel debugger calls kgdboc_post_exp_handler() which | |
848 | in turn calls con_debug_leave().</para> | |
849 | <para>Any video driver that wants to be compatible with the kernel | |
850 | debugger and the atomic kms callbacks must implement the | |
851 | mode_set_base_atomic, fb_debug_enter and fb_debug_leave operations. | |
852 | For the fb_debug_enter and fb_debug_leave the option exists to use | |
853 | the generic drm fb helper functions or implement something custom for | |
854 | the hardware. The following example shows the initialization of the | |
855 | .mode_set_base_atomic operation in | |
856 | drivers/gpu/drm/i915/intel_display.c: | |
857 | <informalexample> | |
858 | <programlisting> | |
859 | static const struct drm_crtc_helper_funcs intel_helper_funcs = { | |
860 | [...] | |
861 | .mode_set_base_atomic = intel_pipe_set_base_atomic, | |
862 | [...] | |
863 | }; | |
864 | </programlisting> | |
865 | </informalexample> | |
866 | </para> | |
867 | <para>Here is an example of how the i915 driver initializes the fb_debug_enter and fb_debug_leave functions to use the generic drm helpers in | |
868 | drivers/gpu/drm/i915/intel_fb.c: | |
869 | <informalexample> | |
870 | <programlisting> | |
871 | static struct fb_ops intelfb_ops = { | |
872 | [...] | |
873 | .fb_debug_enter = drm_fb_helper_debug_enter, | |
874 | .fb_debug_leave = drm_fb_helper_debug_leave, | |
875 | [...] | |
876 | }; | |
877 | </programlisting> | |
878 | </informalexample> | |
879 | </para> | |
880 | </sect2> | |
225a4424 | 881 | </sect1> |
e3e2aaf7 JW |
882 | </chapter> |
883 | <chapter id="credits"> | |
884 | <title>Credits</title> | |
885 | <para> | |
886 | The following people have contributed to this document: | |
887 | <orderedlist> | |
888 | <listitem><para>Amit Kale<email>amitkale@linsyssoft.com</email></para></listitem> | |
889 | <listitem><para>Tom Rini<email>trini@kernel.crashing.org</email></para></listitem> | |
e3e2aaf7 | 890 | </orderedlist> |
225a4424 JW |
891 | In March 2008 this document was completely rewritten by: |
892 | <itemizedlist> | |
893 | <listitem><para>Jason Wessel<email>jason.wessel@windriver.com</email></para></listitem> | |
894 | </itemizedlist> | |
84c08fd6 JW |
895 | In Jan 2010 this document was updated to include kdb. |
896 | <itemizedlist> | |
897 | <listitem><para>Jason Wessel<email>jason.wessel@windriver.com</email></para></listitem> | |
898 | </itemizedlist> | |
e3e2aaf7 JW |
899 | </para> |
900 | </chapter> | |
901 | </book> | |
902 |