Abstract:
A computer system provides a vector monitor for monitoring a first instance of an error-handling vector in architected memory. The monitoring can involve repeatedly comparing the first instance with a second instance of the vector so as to detect a mismatch, should it occur. If a mismatch is detected, the vector monitor can notify an administrator, automatically initiate diagnostic routines, and/or correct the mismatch. As a result, potential fatal events in which firmware confronts a corrupted error-handling vector are less likely to occur.

Description:
BACKGROUND OF THE INVENTION 
   The present invention relates to computers and, more particularly, to error-handling in computers. In this specification, related art labeled “prior art” is admitted prior art; related art not labeled “prior art” is not admitted prior art. 
   Typically, when computers are powered on, firmware guides the initialization process until an operating system can assume control by causing itself and other programs to be executed on one or more processors. Once the operating system is running, it provides most of the functionality including managing programs and handling errors. To the latter end, the operating system stores a vector (pointer) to these error-handler routines in architected memory that the firmware is hard-wired to check in certain error-handling scenarios. Thus, when the firmware is required to handle an error, e.g., one that requires reinitialization of a processor on which an operating system is running, the firmware can read the vector to determine where the error-handling routines are stored so it can use them in helping the computer to recover. 
   SUMMARY OF THE INVENTION 
   In the course of the present invention it was discovered that corruption of error-handler vectors relied on by the firmware, while infrequent, can occur, e.g., they can be overwritten by defective software. When such corruption occurs, it can have a serious negative impact on performance and the user experience. In particular, corruption of the firmware-accessible vectors to error handlers prevents graceful recovery from errors in which the operating system must be suspended. 
   Accordingly, the present invention, as defined in the claims, provides for vector corruption detection, e.g., by a background vector-monitor process or daemon. For example, the vector monitor can compare the error-handler vectors written by the operating system into architected memory with one or more copies of the vectors. A mismatch can indicate the vectors have been corrupted. If vector corruption is detected, the vector monitor can notify a user or administrator, correct the mismatch, and/or initiate a diagnostic routine. In general, the present invention helps ensure the graceful recovery promised by firmware-directed error handling. These and other features and advantages of the invention are apparent from the description below with reference to the following drawings. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  is a schematic block diagram of one of many computer systems provided for by the present invention. 
       FIG. 2  is a flow chart of one of many possible methods provided for by the present invention. 
   

   DETAILED DESCRIPTION 
   A computer system AP 1  in accordance with the present invention comprises a processor  11 , firmware  13 , memory  15 , input/output (I/O) devices  17 , and an interconnecting bus  19 , as shown in  FIG. 1 . Memory  15  includes both disk-based memory and solid-state memory, e.g., RAM. Memory  15  includes architected memory  21 , which is memory in which the values for predetermined parameters are stored at predetermined physical locations. In the illustrated embodiment, processor  11  is a PA-RISC processor and architected memory  15  is Page zero. Placing a value in architected memory permits firmware  13  to find information independent of any dynamic memory allocation scheme. Memory  15  further stores an operating system  23 , other applications  25 , data  27 , and error-handling routines (error handlers)  29 . Operating system  21  is HP-UX, a UNIX variant available from Hewlett-Packard Company. 
   Operating system  23  actually uses storage of its code in two forms: its code lies completely on hard disk initially, and is loaded into RAM upon boot-up. In an alternative embodiment, not all of the operating system is loaded into RAM upon boot-up, but is loaded into RAM on an as-needed basis to save limited RAM capacity. For example, the actual code for an error handler may not be loaded into RAM upon boot, but a vector pointing to the location of the error handler can be quickly found in a symbol table at a known storage address on the disk. 
   In the illustrated embodiment, an instance  31  of the error-handler vector in a symbol table  33  is copied during boot-up to RAM, to form “operating-system” vector  35 ; operating system  23  then copies vector  35  to a dedicated location in architected memory  21 , where it takes the form of firmware-accessible error-handler vector  37 . 
   Operating system  23  also loads a vector monitor  40  into RAM during boot up. Vector monitor  40  runs as a background process and, as part of the boot up process, copies firmware vector  37  to RAM in the form of “monitor” vector  41 . Thus, in system AP 1 , there are four instances of the error-handling vector, “symbol” vector  31  on disk in symbol table  33 , firmware vector  37  in architected memory  21 , and monitor vector  41  managed by vector monitor  40 , and, operating-system vector  35 . 
   Vector monitor  40  repeatedly checks firmware vectors  37  for corruption by comparing them with its copy  41 . When vector monitor  40  determines that its instance  41  and the instance  37  in architected memory match, it does nothing. If a mismatch is detected, vector monitor  40  takes a user-configurable action. Vector monitor  40  can be configured to notify a user or administrator in a variety of ways, e.g., by a message on a display for system AP 1  (assuming a workstation instead of a server), by email, by voicemail, or by simply logging the problem in an error log. The person notified can then take action to correct the mismatch and/or perform diagnostics. 
   Vector monitor  40  can also be configured to perform automatically many of the actions that an administrator might perform, e.g., automatically correct a mismatch or to initiate diagnostics. For example, vector monitor  40  can be configured to examine the operating system instance  35  of the error handling vectors and/or the symbol table instance  31  of the vectors to determine whether it is the firmware vectors  37  or the monitor vectors  41  that have been changed. Once the victim of the corruption is identified, it can be overwritten with a correct value. In an alternative embodiment, the vector monitor does not maintain its own instance of error-handling vectors, but uses the instance maintained in RAM by the operating system; in this case, an instance in the symbol table is used to determine which instance in RAM is corrupt when a mismatch is detected. 
   Vector monitor  40  can also initiate diagnostic procedures. For example, vector monitor can cause firmware  13  to assert a “transfer-of-control” (TOC) signal or a “high-priority machine check” (HPMC) signal to processor  11 . Processor  11  is a PA-RISC processor available from Hewlett-Packard Company; alternatively, an Itanium processor available from Intel Corporation supports similar signals. If vector monitor  40  has already corrected the mismatch, there is also the option of having firmware  13  perform diagnostics while operating system  23  is suspended. In some multi-partition embodiments of the invention, processes running on a partition on which a mismatch is detected can be transferred to other partitions so that the incorporating computer system can remain operational. Note that in a multi-partition system, each partition can have its own vector monitor. 
   One of many possible methods provided by the present invention and used in connection with computer system AP 1  is flow charted in  FIG. 2 . At method segment S 11 , computer system AP 1  is turned on. At method segment S 12 , firmware  13  directs the power-on sequence; at method segment S 13 , firmware  13  launches operating system  23 , which examines the hardware configuration of computer system AP 1  and determines physical memory allocations for non-architected memory. 
   At method segment S 14 , operating system  23  writes its error-handler vector  35  to architected memory  21 , resulting in vector instance  37 . At method segment S 15 , operating system  23  launches vector monitor  40 , which reads firmware-accessible error-handler vector  37  to make its copy  41  at method segment S 16 . 
   Once the boot-up process is complete, vector monitor  40  repeatedly compares firmware vectors  37  with monitor vectors  41  at method segment S 21 . If a match is found at method segment S 22 , method M 1  returns to method segment S 21 . If a mismatch is detected at method segment S 22 , a user-configurable action is taken that can include notification at method segment S 23 , correction at method segment S 24 , and initiating diagnostic procedures at method segment S 25 . 
   Herein, “error handler” encompasses interrupt handlers as well as other types of error-related events. An “error-handler” vector is a value that refers to a location in memory of an error-handling routine. The vector may point directly or indirectly to such a location. In a single partition system, the vector can point directly to the location of an error handling routine. In a multiple partition system (with multiple instances of an operating system, each with its own vector monitor), the vector in architected memory can point to a location which stores a procedure that provides the correct vector for the partition requesting error handling. By “copy” is meant the underlying information is the same, even if the format of the information is different. 
   A user or an administrator, once notified, can take any of many possible diagnostic and/or corrective actions. These include running diagnostic routines, reinitializing the processor and operating system with or without specifying additional diagnostic processes running in the background. In principle, any set of procedures that an administrator can implement can also be automated in firmware and software. These and other variations upon and modifications to the illustrated embodiment are provided for by the present invention, the scope of which is defined by the following claims.