KDB Commands

KDB kernel debugger and kdb command

This artcile  describes the KDB kernel debugger and kdb command.
The KDB kernel debugger and the kdb command are the primary tools a developer or admin uses for debugging device drivers, kernel extensions, and the kernel itself.

KDB kernel debugger

The KDB kernel debugger is integrated into the kernel and allows full control of the system while a debugging session is in progress.
The KDB kernel debugger allows for traditional debugging tasks such as setting breakpoints and single-stepping through code.

kdb command

This command is implemented as an ordinary user-space program and is typically used for post-mortem analysis of a previously-crashed system by using a system dump file. The kdb command includes subcommands specific to the manipulation of system dumps.

Invoking the KDB kernel debugger:

Loading and starting the KDB kernel debugger:
The KDB kernel debugger must be loaded at boot time. This requires that a boot image be created with the debugger enabled. To enable the KDB kernel debugger, use either the -I or -D options of the bosboot command.

Examples of bosboot commands are as follows:

To disable the KDB kernel debugger, use the following command:
bosboot -a -d /dev/ipldevice

To enable the KDB kernel debugger, but not invoke it during system initialization, use the following command:
bosboot -a -d /dev/ipldevice -D

To enable the KDB kernel debugger, and invoke it during system initialization, use the following command:
bosboot -a -d /dev/ipldevice -I

Entering the KDB kernel debugger:
You can enter the KDB kernel debugger using several different procedures.

Enter the KDB kernel debugger using one of the following procedures:

•   On a tty keyboard, press the Ctrl+4 key sequence for IBM® 3151 terminals or the Ctrl+\ key sequence for BQ 303, BQ 310C, and WYSE 50 terminals.
•   On other keyboards, press the Ctrl+Alt+Numpad4 key sequence.
•   Set a breakpoint using one of the Breakpoint and steps subcommands.

  Call the brkpoint subroutine from the C code. The syntax for calling this subroutine is the following:
  brkpoint();

You can use the kdb command with the dw subcommand to determine whether the KDB kernel debugger is available by typing the following:

     # kdb
     (0)> dw kdb_avail
     (0)> dw kdb_wanted

kdb command

The kdb command is an interactive utility for examining an operating system image or the running kernel. The kdb command interprets and formats control structures in the system and provides miscellaneous functions for examining a dump.

The SystemImageFile parameter specifies the file that contains the system image. The value can indicate a system dump, the name of a dump device, or the /dev/pmem special file. The default SystemImageFile is /dev/pmem.

The KernelFile parameter specifies the AIX® kernel that kdb will use to resolve kernel symbol definitions. A kernel file must be available. When examining a system dump it is imperative that the kernel file be the same as the kernel that was used to take the system dump. The default for the KernelFile is /unix.

The KernelModule parameters specify the file names of any additional kernel modules which the kdb command uses to resolve symbol definitions not found in the kernel file itself.

Root permissions are required for use of the kdb command on the active system. This is required because the special file /dev/pmem is used. To run the kdb command on the active system, type the following:

kdb

To invoke the kdb command on a system image file, type:

kdb SystemImageFile

Examples
The following examples demonstrate invocation options for the kdb command

To invoke the kdb command with the default system image and kernel image files, type:
kdb

The kdb program returns a (0)> prompt and waits for entry of a subcommand.

To invoke the kdb command using a dump file named /var/adm/ras/vmcore.0 and the UNIX kernel file named /unix, type:

kdb /var/adm/ras/vmcore.0 /unix
The kdb program returns a (0)> prompt and waits for entry of a subcommand.

Check VSCSI adapter mapping:

With the next command, we can find out which VHOST is mapped to which VSCSI in the VIOS level (show vscsi <–> vhost mappings).

Run on LPAR Client (not on VIO Server):

root@um_lpar: / # echo "cvai" | kdb | grep vscsi                        
 vscsi0 0x000008 0x0000000001 0x0 VIOa->vhost1
 vscsi1 0x000008 0x0000000002 0x0 VIOb->vhost1

Check NPIV adapter mapping

To check the connection between your VFCHOST and FC physical port in the VIOS level (show vfchost <–> fcs mappings).

Run on LPAR Client (not on VIO Server):

root@um_lpar: / # echo "vfcs" | kdb                                      
 NAME ADDRESS STATE HOST HOST_ADAP OPENED NUM_ACTIVE
 fcs0 0xF1000A000032C123 0x0008 VIO1 vfchost1 0x01 0x0000
 fcs1 0xF1000A000032D543 0x0008 VIO2 vfchost2 0x01 0x0000


To View  how many Vitrual Process are Active  
        #  echo "vpm" | kdb

To View Filesystem Details
       # echo vfs | kdb