JPH0675807A - Fault processing verifying system - Google Patents

Abstract

PURPOSE:To execute an inspection in a short time, and also, at a low cost by collating actual fault information subjected to logging and fault information of a generated expected value and verifying a fault processing. CONSTITUTION:A detaching means 3 detaches a device group for constituting the system into one set of specific processing device 1 and the remaining other device 2. In this case, by an artificial fault generating means 4, a specific artificial fault 41 is generated by the other device 2, and when the specific artificial fault 41 is generated in the other device 2, an expected value generating means 5 generates an expected value of fault information to be subjected to logging by an operating system 21. Accordingly, when the specific artificial fault 41 is generated by the artificial fault generating means 4, a collating means 6 collates the fault information subjected to logging by the operating system 21 and the expected value generated by the expected value generating means 5, therefore, based on a result of collation by the collating means 6, a fault processing can be verified.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a failure processing function verification method in a multi-processing system, and more particularly to a test method for verifying the failure processing function of the entire system including an operating system.

In recent years, computer systems have been used in all fields of society, and their processing ability and reliability have been increasingly required. A multi-processing system in which a central processing unit, a memory and the like are multiplexed has been widely used in order to increase the processing capacity. When a failure occurs in a part of these multi-processing systems, a multi-processing system that emphasizes fault tolerance so that the system can continue operating even if the failed device is disconnected and the system performance is reduced. Widely used. Each device that constitutes the computer system has a function of detecting various errors, failures such as failures, and the operating system (OS) is
It has a function to log failure information in order to identify the location of the failure or the device and perform processing such as disconnecting the device from the system. Therefore, in such a multi-processing system, there is a demand for a method capable of accurately verifying a failure processing function including a failure detection and failure information collection function of the entire system including an OS in a short time with a small number of humans. .

[0003]

2. Description of the Related Art Conventionally, a processing device (C
An external maintenance support device provided for each PU) was used to test the system fault detection function. An external maintenance support device, for example, a service processor (SVP) is a CPU
Each device including a CPU in a computer system that has a function to set the hardware such as registers in each device that configures the system to a predetermined state and to read the state Therefore, a failure state is intentionally set, and as a result, the state information presented by the device is collected and dumped regardless of the operation of the OS, and the technician analyzes the collected information to detect a failure in the entire system. I was inspecting whether the function worked properly.

[0004]

According to the conventional method as described above, an external maintenance support device is used to generate a pseudo fault in a device in the system, fault information is collected, and a fault detection function is manually confirmed. As a result, (1) it requires an external maintenance support device to generate pseudo-faults and collects the information, and the system price becomes expensive. (2) The fault detection function of the entire system including the OS is verified. It is not practical because it cannot be done. (3) Since the collected fault information is manually inspected, there is a problem that it takes time and labor.

It is an object of the present invention to provide a failure processing verification method capable of inspecting a failure processing function in a multi-processing system in a practically suitable state in a short time and at low cost.

[0006]

FIG. 1 shows a block diagram of the principle of the present invention. In the figure, 21 is an operating system for logging device failure information, 3 is a disconnecting means for disconnecting a device group constituting the system into one specific processing device 1 and the rest of the other devices 2, and 4 is Pseudo fault generating means for generating a specific pseudo fault 41 in another device 2,
5 is, when a specific pseudo fault 41 occurs in another device 2,
Expected value creating means for creating an expected value of failure information to be logged by the operating system 21,
It is a collation unit for collating the fault information logged by the operating system 21 when the specific pseudo fault 41 is generated by the pseudo fault generation unit 4 with the expected value created by the expected value creation unit 5.

[0007]

According to the present invention, it is composed of a plurality of processing devices having a function of detecting a device failure and logging the failure information by the operating system 21, and a shared device shared by the plurality of processing devices. In the failure processing verification method for a multi-processing system, the disconnecting means 3 disconnects a group of devices constituting the system into one specific processing device 1 and the remaining other devices 2, and the pseudo-fault generating means 4 uses a specific dummy. The fault 41 is generated in the other device 2, and the expected value creating means 5 creates the expected value of the fault information to be logged by the operating system 21 when the specific pseudo fault 41 occurs in the other device 2, and the collating means. Reference numeral 6 denotes failure information logged by the operating system 21 when the specific failure 41 is generated by the failure generating means 4, and an expected value creation procedure. Since collates the expected value created by 5, based on the collation result of the collating means 6, it is possible to verify the failure processing of the multiprocessing system.

[0008]

2 is a system configuration diagram showing an embodiment of the present invention, FIG. 3 is a system configuration definition table, FIG. 4 is an access condition table, FIG. 5 is a failure setting table, and FIG. 6 is an OS logging table.

Throughout the drawings, the same reference numerals indicate the same or similar components. In FIG. 2, CPUs 1 to n are n processing devices each including a main memory, an input / output control device, and the like, and communicate with each other by sharing the shared memories SSM0 and SSM02. CPU1 to n
Also shares a plurality of input / output devices represented by the adapter device AD. CPU1 to n and shared memory SSM01
, And SSM02 via redundant buses # 0 and # 1, and the bus handler devices BH10 and BH11 are
When one of the buses is in use or is out of order, the other bus is used to control the CPUs 1 to n and the SSM01 and SSM02 to be connected for communication. Similarly, CPUs 1 to n
And the adapter device AD are duplicated buses # 0 and # 1
Bus handler devices BH20 and BH21
When one bus is in use or is out of order, the other bus is used to connect the CPUs 1 to n and the adapter device AD for communication.

Each of the CPUs 1 to n has a system configuration definition table (see FIG. 3).
Corresponding to I (implementation), NA (access prohibition), NI
By setting any of (unimplemented) and designating the availability as a system resource, the connection can be logically disconnected even if it is physically connected.
It is possible to arbitrarily configure the system for each n. Therefore, the CPU 1 can be logically separated from the other CPUs 2 to n by setting the system configuration definition table as shown in FIG.

Further, each of the CPUs 1 to n has a diagnostic command for executing a built-in diagnostic function in addition to a normal command. For example, by issuing a diagnostic command to another CPU, shared memory SSM01, SSM02, adapter device AD, etc., that function or part of the function is stopped.

In the system thus constructed, C
PU2-n execute normal operation under OS, CPU
1 causes the test program to be executed. The test program is CPU2 to n, shared memory SSM01, SSM0
2. Sequentially issuing a diagnostic command for causing a pseudo fault to other devices such as the adapter device AD. Then, for each pseudo failure due to the diagnostic command, the hardware actually detects the failure by comparing the failure information actually logged by the OS with the expected value obtained in advance, and the OS correctly logs the failure information. Verify whether to do.

FIG. 7 is a flowchart of the embodiment of the present invention. The operation of the embodiment of the present invention will be described with reference to the case where the shared memory SSM01 is used as the target device in which the pseudo fault occurs.
It will be described based on FIG. 7 and with reference to FIG. (1) One CPU in the system, for example, the CPU 1 is separated from other devices (CPUs 2 to n) and started up as a verification system for running a test program for artificially generating a failure. That is, as shown in FIG. 3 when the initial program is loaded, in the system configuration definition table held by the CPU 1, the C
NA for PU2 to CPUn (operating under OS)
By setting (prohibit access), access to the CPU2 to CPUn by the CPU1 is prohibited. Therefore, even if the CPU 1 and the CPUs 2 to CPUn are physically connected, they are logically separated and the verification system CPU 1 can be separated from the verification target systems CPU 2 to CPUn operating under the OS.

Next, CPUs 2 to CP operating under the OS
To disconnect Un from the verification system CPU1,
In the system configuration definition table of these CPUs, as shown in FIG. 3, by setting NI (not mounted) to the CPU 1 which is the verification system,
Access from Un to CPU1 is prohibited. Therefore, even if they are physically connected, the CPU 1 of the verification system seems to be unmounted from the CPU 2 to the CPUn of the system to be verified logically. (2) Start the test program in the CPU 1 of the verification system. (3) OS in CPU2 to CPUn of the system to be verified
To start. (4) In order to reliably generate a pseudo fault, the operator inputs information including the name, time, and address of the device accessed by the OS in chronological order from the time when the OS is started in this table. (See Figure 4)
Is created. (5) The test program issues a diagnostic command to the shared memory device SSM01 to be tested based on the access condition table created in (2) above, for example, 10
A pseudo fault (HALT) for instructing the operation stop is set at the address 00 for 200 ms. (6) SSM indicating the device name for which the pseudo fault is set in (5) above
01, HALT indicating the set contents in the failure, and 23: 59: 59: 100 milliseconds indicating the set time are stored in the disk device DK in the format of the failure setting table (see FIG. 5). (7) OS is SSM0 which is a shared memory device to be tested
Accessing 1 causes a HALT (fault) condition to occur. (8) The OS stores the failure information (SSM01 goes into HALT state at 23: 59: 59: 120 ms) in the disk device DK in the format of the OS logging table (see FIG. 6). (9) Above (6 ), Set by the test program and stored in the disk device DK (23: 59: 59: 100)
SSM01 HALTs within ~ 300 milliseconds),
In the above (8), the OS is collated with the failure information logged in the disk device DK (SSM01 is in the HALT state at 23: 59: 59: 120 milliseconds). If the collation result is valid, both the hardware failure detection function and the OS logging function can be verified.

[0015]

As described above, according to the present invention,
The devices that make up the multi-processing system are separated into one specific processing device (verification system) and the remaining other devices (systems to be verified), and when an artificial failure occurs in the system to be verified, it is logged by the operating system. The expected value of the expected failure information is created, the verification system causes a pseudo failure in the system to be verified, and the failure information actually logged by the operating system is compared with the created failure information of the expected value to perform multiprocessing. Since the failure processing of the system is verified, the failure processing function of the other apparatus is verified by one CPU instead of the external maintenance support device used conventionally, so that the failure processing of the system can be verified at low cost. Also, hardware and O
Since the fault information processed in cooperation with S is inspected, there is an effect that the fault handling function of the system can be verified in a state close to actual operation.

[Brief description of drawings]

FIG. 1 is a block diagram of the principle of the present invention.

FIG. 2 is a system configuration diagram showing an embodiment of the present invention.

[Figure 3] System configuration definition table

[Figure 4] Access condition table

[Fig. 5] Fault setting table

FIG. 6 OS logging table

FIG. 7 is a flowchart of an embodiment of the present invention.

[Explanation of symbols]

 CPU1 to n Processing device SSM01,02 Shared memory device BH10,11,20,21 Bus handler device AD adapter device DK disk device

Claims (3)

[Claims] 1. Multiprocessing comprising a plurality of processing devices having a function of detecting a device failure and logging the failure information by an operating system (21), and a shared device shared by the plurality of processing devices. In the system for failure verification of a system, the system is provided with a disconnecting means (3) for disconnecting a group of devices constituting the system into one specific processing unit (1) and the remaining other units (2), The specific pseudo device (1) is connected to the specific processing device (1) by another device.
Pseudo-fault generating means (4) that occurs in (2) and expected value of fault information that should be logged by the operating system (21) when the specific pseudo-fault (41) occurs in another device (2) And an expected value creating means (5) for creating the expected failure information, failure information logged by the operating system (21) when the specific pseudo failure (41) is generated by the pseudo failure generating means (4), and the expected information. A verification means (6) for verifying the expected value created by the value creation means (5) is provided, and the failure processing of the multiprocessing system is verified based on the verification result by the verification means (6). Fault handling verification method. 2. The fault processing verification method according to claim 1, wherein the operating system and the expected value creating means (5) respectively log fault information including an occurrence time and create an expected value. 3. The pseudo fault generation means (4) generates a pseudo fault by issuing a diagnostic command in synchronization with an access operation of the operating system (21). Fault handling verification method.