diff options
Diffstat (limited to 'documentation/content/en/books/developers-handbook/kerneldebug/_index.adoc')
| -rw-r--r-- | documentation/content/en/books/developers-handbook/kerneldebug/_index.adoc | 182 |
1 files changed, 136 insertions, 46 deletions
diff --git a/documentation/content/en/books/developers-handbook/kerneldebug/_index.adoc b/documentation/content/en/books/developers-handbook/kerneldebug/_index.adoc index daea455841..817ef1f7de 100644 --- a/documentation/content/en/books/developers-handbook/kerneldebug/_index.adoc +++ b/documentation/content/en/books/developers-handbook/kerneldebug/_index.adoc @@ -38,13 +38,20 @@ toc::[] [[kerneldebug-obtain]] == Obtaining a Kernel Crash Dump -When running a development kernel (e.g., FreeBSD-CURRENT), such as a kernel under extreme conditions (e.g., very high load averages, tens of thousands of connections, exceedingly high number of concurrent users, hundreds of man:jail[8]s, etc.), or using a new feature or device driver on FreeBSD-STABLE (e.g., PAE), sometimes a kernel will panic. In the event that it does, this chapter will demonstrate how to extract useful information out of a crash. +When running a development kernel (e.g., FreeBSD-CURRENT), such as a kernel under extreme conditions (e.g., very high load averages, tens of thousands of connections, exceedingly high number of concurrent users, hundreds of man:jail[8]s, etc.), +or using a new feature or device driver on FreeBSD-STABLE (e.g., PAE), sometimes a kernel will panic. +In the event that it does, this chapter will demonstrate how to extract useful information out of a crash. -A system reboot is inevitable once a kernel panics. Once a system is rebooted, the contents of a system's physical memory (RAM) is lost, as well as any bits that are on the swap device before the panic. To preserve the bits in physical memory, the kernel makes use of the swap device as a temporary place to store the bits that are in RAM across a reboot after a crash. In doing this, when FreeBSD boots after a crash, a kernel image can now be extracted and debugging can take place. +A system reboot is inevitable once a kernel panics. +Once a system is rebooted, the contents of a system's physical memory (RAM) is lost, as well as any bits that are on the swap device before the panic. +To preserve the bits in physical memory, the kernel makes use of the swap device as a temporary place to store the bits that are in RAM across a reboot after a crash. +In doing this, when FreeBSD boots after a crash, a kernel image can now be extracted and debugging can take place. [NOTE] ==== -A swap device that has been configured as a dump device still acts as a swap device. Dumps to non-swap devices (such as tapes or CDRWs, for example) are not supported at this time. A "swap device" is synonymous with a "swap partition." +A swap device that has been configured as a dump device still acts as a swap device. +Dumps to non-swap devices (such as tapes or CDRWs, for example) are not supported at this time. +A "swap device" is synonymous with a "swap partition." ==== Several types of kernel crash dumps are available: @@ -63,11 +70,15 @@ Minidumps are the default dump type as of FreeBSD 7.0, and in most cases will ca [[config-dumpdev]] === Configuring the Dump Device -Before the kernel will dump the contents of its physical memory to a dump device, a dump device must be configured. A dump device is specified by using the man:dumpon[8] command to tell the kernel where to save kernel crash dumps. The man:dumpon[8] program must be called after the swap partition has been configured with man:swapon[8]. This is normally handled by setting the `dumpdev` variable in man:rc.conf[5] to the path of the swap device (the recommended way to extract a kernel dump) or `AUTO` to use the first configured swap device. The default for `dumpdev` is `AUTO` in HEAD, and changed to `NO` on RELENG_* branches (except for RELENG_7, which was left set to `AUTO`). On FreeBSD 9.0-RELEASE and later versions, bsdinstall will ask whether crash dumps should be enabled on the target system during the install process. +Before the kernel will dump the contents of its physical memory to a dump device, a dump device must be configured. +A dump device is specified by using the man:dumpon[8] command to tell the kernel where to save kernel crash dumps. +The man:dumpon[8] program must be called after the swap partition has been configured with man:swapon[8]. +This is normally handled by setting the `dumpdev` variable in man:rc.conf[5] to the path of the swap device (the recommended way to extract a kernel dump) or `AUTO` to use the first configured swap device. +The default for `dumpdev` is `AUTO` in HEAD, and changed to `NO` on RELENG_* branches (except for RELENG_7, which was left set to `AUTO`). +On FreeBSD 9.0-RELEASE and later versions, bsdinstall will ask whether crash dumps should be enabled on the target system during the install process. [TIP] ==== - Check [.filename]#/etc/fstab# or man:swapinfo[8] for a list of swap devices. ==== @@ -87,16 +98,23 @@ Also, remember that the contents of [.filename]#/var/crash# is sensitive and ver [[extract-dump]] === Extracting a Kernel Dump -Once a dump has been written to a dump device, the dump must be extracted before the swap device is mounted. To extract a dump from a dump device, use the man:savecore[8] program. If `dumpdev` has been set in man:rc.conf[5], man:savecore[8] will be called automatically on the first multi-user boot after the crash and before the swap device is mounted. The location of the extracted core is placed in the man:rc.conf[5] value `dumpdir`, by default [.filename]#/var/crash# and will be named [.filename]#vmcore.0#. +Once a dump has been written to a dump device, the dump must be extracted before the swap device is mounted. +To extract a dump from a dump device, use the man:savecore[8] program. +If `dumpdev` has been set in man:rc.conf[5], man:savecore[8] will be called automatically on the first multi-user boot after the crash and before the swap device is mounted. +The location of the extracted core is placed in the man:rc.conf[5] value `dumpdir`, by default [.filename]#/var/crash# and will be named [.filename]#vmcore.0#. -In the event that there is already a file called [.filename]#vmcore.0# in [.filename]#/var/crash# (or whatever `dumpdir` is set to), the kernel will increment the trailing number for every crash to avoid overwriting an existing [.filename]#vmcore# (e.g., [.filename]#vmcore.1#). man:savecore[8] will always create a symbolic link to named [.filename]#vmcore.last# in [.filename]#/var/crash# after a dump is saved. This symbolic link can be used to locate the name of the most recent dump. +In the event that there is already a file called [.filename]#vmcore.0# in [.filename]#/var/crash# (or whatever `dumpdir` is set to), the kernel will increment the trailing number for every crash to avoid overwriting an existing [.filename]#vmcore# (e.g., [.filename]#vmcore.1#). +man:savecore[8] will always create a symbolic link to named [.filename]#vmcore.last# in [.filename]#/var/crash# after a dump is saved. +This symbolic link can be used to locate the name of the most recent dump. -The man:crashinfo[8] utility generates a text file containing a summary of information from a full memory dump or minidump. If `dumpdev` has been set in man:rc.conf[5], man:crashinfo[8] will be invoked automatically after man:savecore[8]. The output is saved to a file in `dumpdir` named [.filename]#core.txt.N#. +The man:crashinfo[8] utility generates a text file containing a summary of information from a full memory dump or minidump. +If `dumpdev` has been set in man:rc.conf[5], man:crashinfo[8] will be invoked automatically after man:savecore[8]. +The output is saved to a file in `dumpdir` named [.filename]#core.txt.N#. [TIP] ==== - -If you are testing a new kernel but need to boot a different one in order to get your system up and running again, boot it only into single user mode using the `-s` flag at the boot prompt, and then perform the following steps: +If you are testing a new kernel but need to boot a different one in order to get your system up and running again, +boot it only into single user mode using the `-s` flag at the boot prompt, and then perform the following steps: [source,bash] .... @@ -106,12 +124,16 @@ If you are testing a new kernel but need to boot a different one in order to get # exit # exit to multi-user .... -This instructs man:savecore[8] to extract a kernel dump from [.filename]#/dev/ad0s1b# and place the contents in [.filename]#/var/crash#. Do not forget to make sure the destination directory [.filename]#/var/crash# has enough space for the dump. Also, do not forget to specify the correct path to your swap device as it is likely different than [.filename]#/dev/ad0s1b#! +This instructs man:savecore[8] to extract a kernel dump from [.filename]#/dev/ad0s1b# and place the contents in [.filename]#/var/crash#. +Do not forget to make sure the destination directory [.filename]#/var/crash# has enough space for the dump. +Also, do not forget to specify the correct path to your swap device as it is likely different than [.filename]#/dev/ad0s1b#! ==== === Testing Kernel Dump Configuration -The kernel includes a man:sysctl[8] node that requests a kernel panic. This can be used to verify that your system is properly configured to save kernel crash dumps. You may wish to remount existing file systems as read-only in single user mode before triggering the crash to avoid data loss. +The kernel includes a man:sysctl[8] node that requests a kernel panic. +This can be used to verify that your system is properly configured to save kernel crash dumps. +You may wish to remount existing file systems as read-only in single user mode before triggering the crash to avoid data loss. [source,bash] .... @@ -131,7 +153,9 @@ After rebooting, your system should save a dump in [.filename]#/var/crash# along [NOTE] ==== -This section covers man:kgdb[1]. The latest version is included in the package:devel/gdb[]. An older version is also present in FreeBSD 11 and earlier. +This section covers man:kgdb[1]. +The latest version is included in the package:devel/gdb[]. +An older version is also present in FreeBSD 11 and earlier. ==== To enter into the debugger and begin getting information from the dump, start kgdb: @@ -141,14 +165,16 @@ To enter into the debugger and begin getting information from the dump, start kg # kgdb -n N .... -Where _N_ is the suffix of the [.filename]#vmcore.N# to examine. To open the most recent dump use: +Where _N_ is the suffix of the [.filename]#vmcore.N# to examine. +To open the most recent dump use: [source,bash] .... # kgdb -n last .... -Normally, man:kgdb[1] should be able to locate the kernel running at the time the dump was generated. If it is not able to locate the correct kernel, pass the pathname of the kernel and dump as two arguments to kgdb: +Normally, man:kgdb[1] should be able to locate the kernel running at the time the dump was generated. +If it is not able to locate the correct kernel, pass the pathname of the kernel and dump as two arguments to kgdb: [source,bash] .... @@ -157,7 +183,12 @@ Normally, man:kgdb[1] should be able to locate the kernel running at the time th You can debug the crash dump using the kernel sources just like you can for any other program. -This dump is from a 5.2-BETA kernel and the crash comes from deep within the kernel. The output below has been modified to include line numbers on the left. This first trace inspects the instruction pointer and obtains a back trace. The address that is used on line 41 for the `list` command is the instruction pointer and can be found on line 17. Most developers will request having at least this information sent to them if you are unable to debug the problem yourself. If, however, you do solve the problem, make sure that your patch winds its way into the source tree via a problem report, mailing lists, or by being able to commit it! +This dump is from a 5.2-BETA kernel and the crash comes from deep within the kernel. +The output below has been modified to include line numbers on the left. +This first trace inspects the instruction pointer and obtains a back trace. +The address that is used on line 41 for the `list` command is the instruction pointer and can be found on line 17. +Most developers will request having at least this information sent to them if you are unable to debug the problem yourself. +If, however, you do solve the problem, make sure that your patch winds its way into the source tree via a problem report, mailing lists, or by being able to commit it! [source,bash] .... @@ -255,16 +286,19 @@ This dump is from a 5.2-BETA kernel and the crash comes from deep within the ker [TIP] ==== - -If your system is crashing regularly and you are running out of disk space, deleting old [.filename]#vmcore# files in [.filename]#/var/crash# could save a considerable amount of disk space! +If your system is crashing regularly and you are running out of disk space, +deleting old [.filename]#vmcore# files in [.filename]#/var/crash# could save a considerable amount of disk space! ==== [[kerneldebug-online-ddb]] == On-Line Kernel Debugging Using DDB -While `kgdb` as an off-line debugger provides a very high level of user interface, there are some things it cannot do. The most important ones being breakpointing and single-stepping kernel code. +While `kgdb` as an off-line debugger provides a very high level of user interface, there are some things it cannot do. +The most important ones being breakpointing and single-stepping kernel code. -If you need to do low-level debugging on your kernel, there is an on-line debugger available called DDB. It allows setting of breakpoints, single-stepping kernel functions, examining and changing kernel variables, etc. However, it cannot access kernel source files, and only has access to the global and static symbols, not to the full debug information like `kgdb` does. +If you need to do low-level debugging on your kernel, there is an on-line debugger available called DDB. +It allows setting of breakpoints, single-stepping kernel functions, examining and changing kernel variables, etc. +However, it cannot access kernel source files, and only has access to the global and static symbols, not to the full debug information like `kgdb` does. To configure your kernel to include DDB, add the options [.programlisting] @@ -277,20 +311,32 @@ options KDB options DDB .... -to your config file, and rebuild. (See link:{handbook}/[The FreeBSD Handbook] for details on configuring the FreeBSD kernel). +to your config file, and rebuild. +(See link:{handbook}/[The FreeBSD Handbook] for details on configuring the FreeBSD kernel). -Once your DDB kernel is running, there are several ways to enter DDB. The first, and earliest way is to use the boot flag `-d`. The kernel will start up in debug mode and enter DDB prior to any device probing. Hence you can even debug the device probe/attach functions. To use this, exit the loader's boot menu and enter `boot -d` at the loader prompt. +Once your DDB kernel is running, there are several ways to enter DDB. +The first, and earliest way is to use the boot flag `-d`. +The kernel will start up in debug mode and enter DDB prior to any device probing. +Hence you can even debug the device probe/attach functions. +To use this, exit the loader's boot menu and enter `boot -d` at the loader prompt. -The second scenario is to drop to the debugger once the system has booted. There are two simple ways to accomplish this. If you would like to break to the debugger from the command prompt, simply type the command: +The second scenario is to drop to the debugger once the system has booted. +There are two simple ways to accomplish this. +If you would like to break to the debugger from the command prompt, simply type the command: [source,bash] .... # sysctl debug.kdb.enter=1 .... -Alternatively, if you are at the system console, you may use a hot-key on the keyboard. The default break-to-debugger sequence is kbd:[Ctrl+Alt+ESC]. For syscons, this sequence can be remapped and some of the distributed maps out there do this, so check to make sure you know the right sequence to use. There is an option available for serial consoles that allows the use of a serial line BREAK on the console line to enter DDB (`options BREAK_TO_DEBUGGER` in the kernel config file). It is not the default since there are a lot of serial adapters around that gratuitously generate a BREAK condition, for example when pulling the cable. +Alternatively, if you are at the system console, you may use a hot-key on the keyboard. +The default break-to-debugger sequence is kbd:[Ctrl+Alt+ESC]. +For syscons, this sequence can be remapped and some of the distributed maps out there do this, so check to make sure you know the right sequence to use. +There is an option available for serial consoles that allows the use of a serial line BREAK on the console line to enter DDB (`options BREAK_TO_DEBUGGER` in the kernel config file). +It is not the default since there are a lot of serial adapters around that gratuitously generate a BREAK condition, for example when pulling the cable. -The third way is that any panic condition will branch to DDB if the kernel is configured to use it. For this reason, it is not wise to configure a kernel with DDB for a machine running unattended. +The third way is that any panic condition will branch to DDB if the kernel is configured to use it. +For this reason, it is not wise to configure a kernel with DDB for a machine running unattended. To obtain the unattended functionality, add: @@ -301,14 +347,17 @@ options KDB_UNATTENDED to the kernel configuration file and rebuild/reinstall. -The DDB commands roughly resemble some `gdb` commands. The first thing you probably need to do is to set a breakpoint: +The DDB commands roughly resemble some `gdb` commands. +The first thing you probably need to do is to set a breakpoint: [source,bash] .... break function-name address .... -Numbers are taken hexadecimal by default, but to make them distinct from symbol names; hexadecimal numbers starting with the letters `a-f` need to be preceded with `0x` (this is optional for other numbers). Simple expressions are allowed, for example: `function-name + 0x103`. +Numbers are taken hexadecimal by default, but to make them distinct from symbol names; +hexadecimal numbers starting with the letters `a-f` need to be preceded with `0x` (this is optional for other numbers). +Simple expressions are allowed, for example: `function-name + 0x103`. To exit the debugger and continue execution, type: @@ -334,7 +383,8 @@ If you want to remove a breakpoint, use del address-expression .... -The first form will be accepted immediately after a breakpoint hit, and deletes the current breakpoint. The second form can remove any breakpoint, but you need to specify the exact address; this can be obtained from: +The first form will be accepted immediately after a breakpoint hit, and deletes the current breakpoint. +The second form can remove any breakpoint, but you need to specify the exact address; this can be obtained from: [source,bash] .... @@ -364,7 +414,8 @@ This will step into functions, but you can make DDB trace them until the matchin [NOTE] ==== -This is different from ``gdb``'s `next` statement; it is like ``gdb``'s `finish`. Pressing kbd:[n] more than once will cause a continue. +This is different from ``gdb``'s `next` statement; it is like ``gdb``'s `finish`. +Pressing kbd:[n] more than once will cause a continue. ==== To examine data from memory, use (for example): @@ -377,7 +428,9 @@ To examine data from memory, use (for example): x/s stringbuf .... -for word/halfword/byte access, and hexadecimal/decimal/character/ string display. The number after the comma is the object count. To display the next 0x10 items, simply use: +for word/halfword/byte access, and hexadecimal/decimal/character/ string display. +The number after the comma is the object count. +To display the next 0x10 items, simply use: [source,bash] .... @@ -401,7 +454,8 @@ To modify memory, use the write command: w/w 0xf0010030 0 0 .... -The command modifier (`b`/`h`/`w`) specifies the size of the data to be written, the first following expression is the address to write to and the remainder is interpreted as data to write to successive memory locations. +The command modifier (`b`/`h`/`w`) specifies the size of the data to be written, +the first following expression is the address to write to and the remainder is interpreted as data to write to successive memory locations. If you need to know the current registers, use: @@ -440,7 +494,9 @@ For a man:ps[1] style summary of all running processes, use: ps .... -Now you have examined why your kernel failed, and you wish to reboot. Remember that, depending on the severity of previous malfunctioning, not all parts of the kernel might still be working as expected. Perform one of the following actions to shut down and reboot your system: +Now you have examined why your kernel failed, and you wish to reboot. +Remember that, depending on the severity of previous malfunctioning, not all parts of the kernel might still be working as expected. +Perform one of the following actions to shut down and reboot your system: [source,bash] .... @@ -454,7 +510,8 @@ This will cause your kernel to dump core and reboot, so you can later analyze th call boot(0) .... -Might be a good way to cleanly shut down the running system, `sync()` all disks, and finally, in some cases, reboot. As long as the disk and filesystem interfaces of the kernel are not damaged, this could be a good way for an almost clean shutdown. +Might be a good way to cleanly shut down the running system, `sync()` all disks, and finally, in some cases, reboot. +As long as the disk and filesystem interfaces of the kernel are not damaged, this could be a good way for an almost clean shutdown. [source,bash] .... @@ -470,16 +527,28 @@ If you need a short command summary, simply type: help .... -It is highly recommended to have a printed copy of the man:ddb[4] manual page ready for a debugging session. Remember that it is hard to read the on-line manual while single-stepping the kernel. +It is highly recommended to have a printed copy of the man:ddb[4] manual page ready for a debugging session. +Remember that it is hard to read the on-line manual while single-stepping the kernel. [[kerneldebug-online-gdb]] == On-Line Kernel Debugging Using Remote GDB This feature has been supported since FreeBSD 2.2, and it is actually a very neat one. -GDB has already supported _remote debugging_ for a long time. This is done using a very simple protocol along a serial line. Unlike the other methods described above, you will need two machines for doing this. One is the host providing the debugging environment, including all the sources, and a copy of the kernel binary with all the symbols in it, and the other one is the target machine that simply runs a similar copy of the very same kernel (but stripped of the debugging information). +GDB has already supported _remote debugging_ for a long time. +This is done using a very simple protocol along a serial line. +Unlike the other methods described above, you will need two machines for doing this. +One is the host providing the debugging environment, including all the sources, and a copy of the kernel binary with all the symbols in it, +and the other one is the target machine that simply runs a similar copy of the very same kernel (but stripped of the debugging information). -You should configure the kernel in question with `config -g` if building the "traditional" way. If building the "new" way, make sure that `makeoptions DEBUG=-g` is in the configuration. In both cases, include `DDB` in the configuration, and compile it as usual. This gives a large binary, due to the debugging information. Copy this kernel to the target machine, strip the debugging symbols off with `strip -x`, and boot it using the `-d` boot option. Connect the serial line of the target machine that has "flags 080" set on its uart device to any serial line of the debugging host. See man:uart[4] for information on how to set the flags on an uart device. Now, on the debugging machine, go to the compile directory of the target kernel, and start `gdb`: +You should configure the kernel in question with `config -g` if building the "traditional" way. +If building the "new" way, make sure that `makeoptions DEBUG=-g` is in the configuration. +In both cases, include `DDB` in the configuration, and compile it as usual. +This gives a large binary, due to the debugging information. +Copy this kernel to the target machine, strip the debugging symbols off with `strip -x`, and boot it using the `-d` boot option. +Connect the serial line of the target machine that has "flags 080" set on its uart device to any serial line of the debugging host. +See man:uart[4] for information on how to set the flags on an uart device. +Now, on the debugging machine, go to the compile directory of the target kernel, and start `gdb`: [source,bash] .... @@ -515,7 +584,9 @@ DDB will respond with: Next trap will enter GDB remote protocol mode .... -Every time you type `gdb`, the mode will be toggled between remote GDB and local DDB. In order to force a next trap immediately, simply type `s` (step). Your hosting GDB will now gain control over the target kernel: +Every time you type `gdb`, the mode will be toggled between remote GDB and local DDB +In order to force a next trap immediately, simply type `s` (step). +Your hosting GDB will now gain control over the target kernel: [source,bash] .... @@ -525,19 +596,27 @@ Debugger (msg=0xf01b0383 "Boot flags requested debugger") (kgdb) .... -You can use this session almost as any other GDB session, including full access to the source, running it in gud-mode inside an Emacs window (which gives you an automatic source code display in another Emacs window), etc. +You can use this session almost as any other GDB session, including full access to the source, +running it in gud-mode inside an Emacs window (which gives you an automatic source code display in another Emacs window), etc. [[kerneldebug-console]] == Debugging a Console Driver -Since you need a console driver to run DDB on, things are more complicated if the console driver itself is failing. You might remember the use of a serial console (either with modified boot blocks, or by specifying `-h` at the `Boot:` prompt), and hook up a standard terminal onto your first serial port. DDB works on any configured console driver, including a serial console. +Since you need a console driver to run DDB on, things are more complicated if the console driver itself is failing. +You might remember the use of a serial console (either with modified boot blocks, or by specifying `-h` at the `Boot:` prompt), +and hook up a standard terminal onto your first serial port. +DDB works on any configured console driver, including a serial console. [[kerneldebug-deadlocks]] == Debugging Deadlocks -You may experience so called deadlocks, a situation where a system stops doing useful work. To provide a helpful bug report in this situation, use man:ddb[4] as described in the previous section. Include the output of `ps` and `trace` for suspected processes in the report. +You may experience so called deadlocks, a situation where a system stops doing useful work. +To provide a helpful bug report in this situation, use man:ddb[4] as described in the previous section. +Include the output of `ps` and `trace` for suspected processes in the report. -If possible, consider doing further investigation. The recipe below is especially useful if you suspect that a deadlock occurs in the VFS layer. Add these options to the kernel configuration file. +If possible, consider doing further investigation. +The recipe below is especially useful if you suspect that a deadlock occurs in the VFS layer. +Add these options to the kernel configuration file. [.programlisting] .... @@ -558,13 +637,22 @@ To obtain meaningful backtraces for threaded processes, use `thread thread-id` t [[kerneldebug-dcons]] == Kernel debugging with Dcons -man:dcons[4] is a very simple console driver that is not directly connected with any physical devices. It just reads and writes characters from and to a buffer in a kernel or loader. Due to its simple nature, it is very useful for kernel debugging, especially with a FireWire(R) device. Currently, FreeBSD provides two ways to interact with the buffer from outside of the kernel using man:dconschat[8]. +man:dcons[4] is a very simple console driver that is not directly connected with any physical devices. +It just reads and writes characters from and to a buffer in a kernel or loader. +Due to its simple nature, it is very useful for kernel debugging, especially with a FireWire(R) device. +Currently, FreeBSD provides two ways to interact with the buffer from outside of the kernel using man:dconschat[8]. === Dcons over FireWire(R) -Most FireWire(R) (IEEE1394) host controllers are based on the OHCI specification that supports physical access to the host memory. This means that once the host controller is initialized, we can access the host memory without the help of software (kernel). We can exploit this facility for interaction with man:dcons[4]. man:dcons[4] provides similar functionality as a serial console. It emulates two serial ports, one for the console and DDB, the other for GDB. Since remote memory access is fully handled by the hardware, the man:dcons[4] buffer is accessible even when the system crashes. +Most FireWire(R) (IEEE1394) host controllers are based on the OHCI specification that supports physical access to the host memory. +This means that once the host controller is initialized, we can access the host memory without the help of software (kernel). +We can exploit this facility for interaction with man:dcons[4]. +man:dcons[4] provides similar functionality as a serial console. +It emulates two serial ports, one for the console and DDB, the other for GDB. +Since remote memory access is fully handled by the hardware, the man:dcons[4] buffer is accessible even when the system crashes. -FireWire(R) devices are not limited to those integrated into motherboards. PCI cards exist for desktops, and a cardbus interface can be purchased for laptops. +FireWire(R) devices are not limited to those integrated into motherboards. +PCI cards exist for desktops, and a cardbus interface can be purchased for laptops. ==== Enabling FireWire(R) and Dcons support on the target machine @@ -588,7 +676,8 @@ Add `LOADER_FIREWIRE_SUPPORT=YES` in [.filename]#/etc/make.conf# and rebuild man To enable man:dcons[4] as an active low-level console, add `boot_multicons="YES"` to [.filename]#/boot/loader.conf#. -Here are a few configuration examples. A sample kernel configuration file would contain: +Here are a few configuration examples. +A sample kernel configuration file would contain: [source,bash] .... @@ -689,7 +778,8 @@ LANG=C ddd --debugger kgdb kernel /dev/fwmem0.2 === Dcons with KVM -We can directly read the man:dcons[4] buffer via [.filename]#/dev/mem# for live systems, and in the core dump for crashed systems. These give you similar output to `dmesg -a`, but the man:dcons[4] buffer includes more information. +We can directly read the man:dcons[4] buffer via [.filename]#/dev/mem# for live systems, and in the core dump for crashed systems. +These give you similar output to `dmesg -a`, but the man:dcons[4] buffer includes more information. ==== Using Dcons with KVM |