Browse Prior Art Database

Mechanism to Expedite Boot-Time Debugging

IP.com Disclosure Number: IPCOM000115602D
Original Publication Date: 1995-May-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 141K

Publishing Venue

IBM

Related People

Bo, W: AUTHOR [+2]

Abstract

The AIX* boot process is quite complicated. Not only is it a significant part of the kernel, but also several commands and libraries are exercised during boot. A bug in any of these components may result in the system hanging or crashing while booting. Such boot problems are not uncommon, especially during the development cycle.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 41% of the total text.

Mechanism to Expedite Boot-Time Debugging

      The AIX* boot process is quite complicated.  Not only is it a
significant part of the kernel, but also several commands and
libraries
are exercised during boot.  A bug in any of these components may
result
in the system  hanging  or crashing while booting.  Such boot
problems
are not uncommon, especially during the development cycle.

      The bugging boot* problem is not trivial since the system
console is not configured until late in the boot process and the
on-going activities of the system cannot be easily determined.  The
current approach to debugging these problems can be time consuming
and tedious, and can prolong development time significantly.  The
first step is to build a new boot image with trace and debugger
enabled.  To  get trace information from the rc.boot shell script
which controls the boot process, one must edit this script before the
new boot image is built.  This requires some knowledge of the rc.boot
script.  Next, a new boot image is created by running the command
"bosboot " with a -I option so that at the beginning of boot, the
system will stop in the kernel debugger and further debugging can
be done.  Since the boot image is built differently for different
bootable media, the boot image for the correct boot medium must be
built.  If the boot medium happens to be a hard disk and if the
system failed  to boot, then the system is booted from a tape,
CDROM, or a network to get to maintenance mode before the
"bosboot" command can be run.  The new boot image that has  been
built needs to be placed on a bootable medium.  If the medium is a
CDROM, this means cutting a new CD to put a new boot image on it.
This typically takes several hours, and is usually not done due to
overhead.  If the  bootable medium is a tape, a new boot image and
an install image can be easily made but it takes 30 to 40 minutes
to do so.  The system is then rebooted from the bootable medium.

      Once  the system stops in the debugger, a special kernel
variable called "enter_dbg" has to be set to nonzero to inform the
console device driver that the trace output should be sent to the
debug serial port S1.  To do this, the address of "enter_dbg" has to
be determined from the kernel map or from the symbol table of the
kernel used in creating the boot image.  Currently, this is the
only way to obtain the output from the system during early phases of
boot before the console has been configured.

      Thus, boot debugging  can  be a lengthy process which can
prolong development time significantly.  Also, it may not be
able to replicate some bugs once the boot image is rebuilt with
the -I option in the bosboot command.

      This  disclosure describes a scheme which can make boot
debugging much easier and faster by incoporating a mechanism to
optionally break into the debugger at the right instant and provide
a menu option in the kernel debugger to set the tra...