Abstract:
Method and system for managing boot trace information is provided. The system includes a utility module executed by a computing system processor that enables boot trace collection in a host bus adapter, wherein the utility module enables boot trace collection for different software modules and boot trace information is stored in a designated area of a non-volatile memory, if hardware initialization fails; if firmware loading is unacceptable; if BIOS initialization is unacceptable; and if target discovery is improper.

Description:
BACKGROUND 
     1. Field of the Invention 
     The present invention relates to computing systems, and more particularly, to managing and storing boot trace information in network adapters. 
     2. Background of the Invention 
     Conventional computing systems typically include several functional components. These components may include a central processing unit (CPU), main memory, input/output (“I/O”) devices, and streaming storage devices (for example, tape drives). In conventional systems, the main memory is coupled to the CPU via a system bus or a local memory bus. The main memory is used to provide the CPU access to data and/or program information that is stored in main memory at execution time. Typically, the main memory is composed of random access memory (RAM) circuits. A computing system is often referred to as a host system. 
     Host systems are used in various applications and environments, including networks and storage area networks (“SAN”). SANs are commonly used to store and access data. SAN is a high-speed sub-network of shared storage devices, for example, disks and tape drives. 
     Host systems often communicate with storage systems via a host bus adapter (“HBA”, may also be referred to as a “controller” and/or “adapter”) using an interface, for example, the “PCI” (or PCI-X/PCI-Express) bus interface. The standard bus specifications are incorporated herein by reference in their entirety. 
     Various standard protocols are used to facilitate host system communication with SAN devices. Fibre Channel is one such standard. Fibre Channel is a set of American National Standard Institute (ANSI) standards, which provide a serial transmission protocol for storage and network protocols such as HIPPI, SCSI, IP, ATM and others. Fibre Channel provides an input/output interface to meet the requirements of both channel and network users. The Fibre Channel standards are incorporated herein by reference in their entirety. 
     Host systems use a set executable code, called “boot code” to install an operating system, for example, Windows® to start operating the system. Boot code can be stored locally in host memory or it can be acquired from a storage device that is connected to a SAN. If boot code is accessed from a SAN connected device, it is referred to as SAN boot. 
     Booting from SAN is advantageous, but comes with complications. For example, there are dedicated Fibre Channel HBAs connected to fabric switches often in complex configurations. If a failure occurs during SAN boot, it is very difficult to troubleshoot. 
     For example, in Windows® operating environment, to troubleshoot boot installation, a Microsoft Kernel Debugger is used. However, a standard operating system CD may not have any way to enable the debugger. A user has to copy the entire operating system CD image to a hard drive, modify certain files, enable the debugger and then re-create the operating system image. Thereafter, a debugging system is setup and connected with a serial cable, before installation can start. 
     When the operating system is not fully functional, during boot error, the host system simply provides some encrypted information and crash code. This makes it difficult to access boot errors. 
     A similar de-bugging problem occurs when basic input/output operating system (BIOS) code; extended firmware interface code (EFI) or any other code that a HBA executes from its read only memory during host system initialization. Currently, messages can only be displayed on a display device, but as the code executes, the messages simply scroll away. 
     Therefore, there is a need for a method and system to better manage boot trace information. 
     SUMMARY OF THE PRESENT INVENTION 
     In one aspect of the present invention, a system for managing boot trace information is provided. The system includes a utility module executed by a computing system processor that enables boot trace collection in a host bus adapter, wherein the utility module enables boot trace collection for different software modules and boot trace information is stored in a designated area of a non-volatile memory, if hardware initialization fails; if firmware loading is unacceptable; if BIOS initialization is unacceptable; and if target discovery is improper. 
     In another aspect of the present invention, a method for managing boot trace information is provided. The method includes enabling boot trace collection in a host bus adapter, wherein a utility module enables boot trace collection for different software modules; saving boot trace information in a designated area of a non-volatile memory, if hardware initialization fails; saving boot trace information in a designated area of the non-volatile memory, if firmware loading is unacceptable; saving boot trace information in a designated area of the non-volatile memory, if BIOS initialization is unacceptable; and saving boot trace information in a designated area of the non-volatile memory, if target discovery is improper. 
     In another aspects of the present invention, computer-executable process steps stored on computer-readable media for managing boot trace information in a host bus adapter are provided. The process steps include code for enabling boot trace collection in a host bus adapter, wherein a utility module enables boot trace collection for different software modules; code for saving boot trace information in a designated area of a non-volatile memory, if hardware initialization fails; code for saving boot trace information in a designated area of the non-volatile memory, if firmware loading is unacceptable; code for saving boot trace information in a designated area of the non-volatile memory, if BIOS initialization is unacceptable; and code for saving boot trace information in a designated area of the non-volatile memory, if target discovery is improper. 
     This brief summary has been provided so that the nature of the invention may be understood quickly. A more complete understanding of the invention can be obtained by reference to the following detailed description of the preferred embodiments thereof in connection with the attached drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing features and other features of the present invention will now be described with reference to the drawings of a preferred embodiment. In the drawings, the same components have the same reference numerals. The illustrated embodiment is intended to illustrate, but not to limit the invention. The drawings include the following Figures: 
         FIG. 1A  shows a top-level block diagram of a system using a HBA, according to one aspect of the present invention; 
         FIG. 1B  shows top-level block diagram of a HBA used according to one aspect of the present invention; 
         FIG. 2A  shows a top-level block diagram of a software architecture used according to one aspect of the present invention; 
         FIG. 2B  shows a block diagram of a boot trace utility, according to one aspect of the present invention; 
         FIG. 2C  shows an example of boot trace parameters, used according to one aspect of the present invention; and 
         FIG. 3  shows a flow diagram for boot tracing, according to one aspect of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     To facilitate an understanding of the preferred embodiment, the general architecture and operation of a system using storage devices will be described. The specific architecture and operation of the preferred embodiment will then be described with reference to the general architecture. 
       FIG. 1A  shows a block diagram of system  100 . System  100  includes a host computing system  100 A (may also be referred to as host system) with a central processing unit  101  that executes program instructions out of memory  102  that may be random access memory (RAM). Read only memory  103  is also provided to store invariant instruction sequences such as start-up instruction sequences or basic input/output operating system (BIOS). Other devices (shown as  104 ) for example, a display device, mouse, and/or keyboard are also attached to bus  105 . 
     Host system  100 A interfaces with HBA  106 . HBA  106  is used to interface host system  100 A with storage system  108  via network  107  (for example, a SAN, used interchangeably throughout this specification). 
     Boot code  109  can be physically stored in storage system  108 . Boot code  109  is made available to CPU  101  that executes boot code  109  from RAM  102 . HBA  106  is used to store boot trace information in a memory buffer  106 A, according to one aspect of the present invention, as described below in detail. 
       FIG. 1B  shows a top-level diagram of HBA  106  that interfaces with host system  100 A via host interface  106 C and a bus  106 G. Bus  106 G can be a PCI, PCI-X, PCI-Express or any other standard/non-standard bus. The bus specifications are incorporated herein by reference in their entirety. Host interface  106 C is customized to handle the type of bus that is being used and performs standard interface functions, for example, signal conversion and others. 
     HBA  106  communicates with other networked devices via a network interface  106 D and network link  106 H. Different standard network protocols can be used to facilitate this communication. For example, Fibre Channel, iSCSI, Infiniband and others can be used. The protocol standards are incorporated herein by reference in their entirety. Network interface  106 D is customized to handle these different protocols. 
     HBA  106  has processor  106 E that executes firmware instructions  106 F to control the overall operations of HBA  106 . Processor  106 E can be a reduced instruction set computer (RISC) or any other processor. 
     Processor  106 E has access to non-volatile memory  106 B, which stores firmware code ( 106 F), HBA basic input output instructions (BIOS)  106 G, extended firmware interface code (EFI) and other information (for example, FCODE). These codes are different for different operating systems, for example, Windows®, Linux, Solaris® and others. As discussed above, the de-bugging problems also arise when BIOS  106 G, EFI and FCODE are being executed during host system boot process. 
     Memory  106 B also stores boot trace information (in buffer  106 A), when host system  100 A is executing boot code  109 , as described below in detail. 
     When boot tracing is enabled, each read only memory (ROM) code (i.e. BIOS, EFI, FCODE and driver) reads boot-tracing information from a designated memory buffer. If boot trace is enabled for each type of code (described below with respect to  FIG. 2C ) with a specified trace level, the ROM code/driver writes trace data onto a buffer location ( 106 A) in memory  106 B. In one aspect, trace data includes ASCii strings so that it can be displayed easily. 
       FIG. 2A  shows a block diagram of the overall software architecture that allows host system  100 A to interface with various networked devices. Host system  100 A has an operating system  100 C, which may be Windows®, Linux or any other operating system. It is noteworthy that the present invention is not based on any particular operating system. Boot code  109  is used to boot/initialize operating system  100 C before host system  100 A becomes functional. 
     A driver (HBA driver)  100 B interfaces between operating system  100 C and host bus adapter firmware code  106 F. Typically, firmware code  106 F resides in a non-volatile memory of HBA  106 , as shown in  FIG. 1B . 
     Boot trace utility  200  (may also be referred to as “utility module” “utility  200 ”) enables HBA  106  to collect boot trace information. Boot trace information can be ported from memory buffer  106 A using utility module  200 , as described below.  FIG. 2B  shows a top-level block diagram of utility module  200  that includes a configuration module  201 , clear module  202 , display module  203  and an export module  204 . 
     Configure module  201  is used to configure HBA  106  to collect boot trace information and store boot trace information in buffer  106 A. Trace information stored in non-volatile memory  106 B is cleared by clear module  202 . Display module  203  displays boot trace interface to a user on a display device for example, a monitor. Export module  204  is used to port or move boot trace information from buffer  106 A to another device. 
     It is noteworthy that utility module  200  operates as a user interface allowing a user to easily view, manage and display boot trace information. 
       FIG. 3  shows a process flow diagram for using utility module  200  and managing boot information, according to one aspect of the present invention. 
     The process starts in step S 300 , when boot tracing is enabled. In one aspect, setting a register bit in memory  106 B enables boot tracing. Since HBA  106  operates in different operating system environments, a different bit may be set for different software components, for example, FCODE, EFI or BIOS. 
       FIG. 2C  shows an example of boot trace configuration parameters  205 . Memory  106 B has a dedicated segment that stores boot configuration information/parameters. The boot trace level  206  can be programmed that determines how much boot information should be stored. Boot trace for driver, BIOS, EFI or FCODE can be enabled/disabled by setting a bit value (shown in segment  207 ). 
     The bit values for “bios boot clr on init”, “efi boot trace clr on init”; and “fcode boot clr on init” (also shown in segment  207 ) clear the buffer ( 106 A) that stores boot trace information for HBA driver  100 B, BIOS (also shown as bios in  FIG. 2C ), EFI (also shown as efi in  FIG. 2C ) and FCODE (also shown as fcode in  FIG. 2C ). 
     Segment  208  provides memory addresses where boot trace information is stored. This is helpful when boot trace information is being retrieved or ported. It is noteworthy that the example of  FIG. 2C  have been provided to illustrate the adaptive aspects of the present invention and not to limit the invention to any particular bit value, command name, memory address and others. 
     Referring back to  FIG. 3 , in step S 302 , host system  100 A BIOS calls for BIOS initialization entry point. In S 304 , host system  100 A determines if hardware initialization is acceptable/proper. If hardware initialization is not proper, then in step S 306 , the trace message is stored in a dedicated area of non-volatile memory. 
     If hardware initialization is acceptable, then in step S 308 , host system  100 A determines if firmware loading is acceptable. If not, then trace message is stored in step S 310  in assigned memory space. 
     If loading is acceptable, then in step S 312 , host system  100 A determines if BIOS initialization is acceptable. If not, then in step S 314 , trace messages with respect to BIOS initialization is saved in assigned memory buffer. 
     In step S 314 , host system  100 A determines if a target has been discovered. If not, then trace messages are saved in step S 316 . If a target has been properly discovered, then in step S 318  an input/output request is serviced and a status report is sent. Thereafter, the process ends in step S 320 . 
     It is noteworthy that although the foregoing example has been provided with respect to HBAs, the boot trace collection process/utility can be used in any other system/environment. 
     In one aspect of the present invention, a utility can configure boot trace collection by a HBA. Boot trace information can be displayed or transferred to another system for analysis. 
     Although the present invention has been described with reference to specific embodiments, these embodiments are illustrative only and not limiting. Many other applications and embodiments of the present invention will be apparent in light of this disclosure and the following claims.