JP2814988B2 - Failure handling method - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a fault handling system, and more particularly, to a fault handling system in the event of a system controller (SCU) failure.

[0002]

2. Description of the Related Art Conventionally, in this type of fault handling system, SC
When a failure occurs in a portion having an error correction circuit in U, the processing is continued, and the reliability of the information processing device is improved.

However, if the fault location is a fixed fault, in an information processing apparatus having a plurality of SCUs, if the fault occurs frequently, the information processing device having a plurality of SCUs will continue to use the SCU due to performance degradation or fault information overflow. When a drivable intermittent fault occurs, the diagnostic processing device (referred to as “DGP”) counts the number of times, and the count value becomes equal to or more than a predetermined number within a predetermined time (this is referred to as “count over”). ) At the time of the SC
The process of disconnecting U and executing under the SCU has been attempted to be continuously executed by processor relief (rescue processing). At this time, the DGP sends the SCU
The SCU has been disconnected regardless of the operation state of an arithmetic processing unit (referred to as “EPU”) connected thereunder.

[0004]

As described above, in the conventional fault handling system, the separation of the faulty SCU is as follows.
Since the operation is performed irrespective of the operation state of the EPU under the SCU, if the SPU under the SCU is disconnected from the SCU during a non-retryable section while executing the software instruction, Since the process being executed by the EPU cannot be retried, the processor cannot be relieved, resulting in a process abort or a system crash.

FIG. 5 is a diagram showing a software instruction execution flow of the EPU for performing such a conventional failure processing. As shown in FIG. 5, a software instruction generally has a section that can be retried and a section that cannot be retried. The instruction can be retried at the start of the instruction, and cannot be retried by updating a shared resource. Become.

[0006] When the EPU is disconnected, as shown as "A" in FIG. 5, if the section is a retryable section, the executing "software instruction 2" can be retried. Processor relief can be performed on a healthy EPU, and a process running in the EPU can be continuously executed.

[0007] However, as shown by "B" in FIG. 5, if the section cannot be retried, it is impossible to perform processor relief, and the process being executed by the EPU cannot be continuously executed. It became possible, and it was considered a process abort. If the process is the core of the operating system (kernel),
Was causing a system crash.

For this reason, in the case of an intermittent failure of the SCU,
By waiting for the disconnection of the SCU until the completion of the execution of the software instruction, the EPU can perform processor relief, and the processor relief allows the process to be taken over by a healthy EPU, thereby enabling continuous operation without aborting the process.

Accordingly, the present invention has been made in view of the above circumstances, and an object of the present invention is to eliminate an abort of a process that is being executed by an EPU when an SCU is disconnected due to counting over of an intermittent failure. An object of the present invention is to provide a failure processing method that improves the reliability of an information processing device by enabling continuous operation.

[0010]

In order to achieve the above-mentioned object, according to the fault processing method of the present invention, a faulty SCU is separated by a predetermined number of intermittent faults occurring in a system control unit (hereinafter referred to as "SCU"). when dividing said by sending software instructions interrupt request to all of the arithmetic processing unit (hereinafter referred to as "EPU") under fault SCU, waiting until the end of the software instructions running on the EPU, the disorder under SCU The SCU is disconnected after all the EPUs are ready to be retried, and the processor relief process of the process executed by the EPU under the SCU is performed.

The outline of the present invention will be described below. According to the present invention, the SC due to an intermittent failure count over of the SCU
In the EPU disconnection accompanying the U disconnection, the SCU
This realizes a reliable continuous operation of the process executed by all the subordinate EPUs.

More specifically, when the count-up of the intermittent failure of the SCU occurs, the diagnostic processing unit (DGP) (reference numeral 7 in FIG. 1) does not immediately disconnect the EPU, but directly controls the subordinate of the failed SCU. A software instruction interruption request mechanism for waiting for the end of the software instruction being executed by the EPU (reference numeral 12 in FIG. 1), a software instruction interruption interrupt mechanism for retaining the software instruction interruption request (reference numeral 22 in FIG. 1), The interruption request is determined between software instructions, and the software instruction interruption completion notification is sent to the DGP.
(Symbol 7 in FIG. 1), and in the retryable state
Software instruction suspending mechanism for disconnection of U (Fig. 1
26).

[0013] The DGP does not disconnect the EPU until all the EPUs under the failed SCU can be retried.

That is, according to the present invention, when the SCU is disconnected due to the count-up of the intermittent failure, the EPU is waited for the interruption of the software instruction being executed, and the EPU is disconnected. This allows continuous operation without aborting the process. As a result, it is possible to effectively prevent serious damage such as a system down due to the occurrence of a hardware failure of the SCU.

[0015]

Embodiments of the present invention will be described in detail below with reference to the drawings. FIG. 1 is a diagram for explaining an embodiment of the present invention, and shows the overall configuration of a system in a block diagram. FIG. 2 is a detailed diagram of FIG.

Referring to FIGS. 1 and 2, arithmetic processing units (EPUs) 1, 2, 3, and 4 sequentially execute a process constituted by a group of software instructions. The system control processing units (SCUs) 5 and 6 include EPUs 1, 2, 3,
4. A memory request or the like is received from an input / output device (also referred to as “IOP”) or the like (not shown), and a read / write operation is performed to a main storage device (also referred to as “MMU”) (not shown). EPU1 and 2 are SCU5, EPU3 and 4 are SC
Connected to U6.

The diagnostic processing unit (DGP) 7 includes EPU, I
It has a failure detection mechanism such as OP, SCU, MMU, etc.
When a failure is detected, the failed device is disconnected.

Failure indication mechanism 15 in SCUs 5 and 6
Reference numeral 16 denotes a flag for displaying a fault type and a fault location when a fault occurs in the own SCU. The diagnostic path 30 is a path for transferring fault information of the SCU to the DGP 7.

SCU in diagnostic processing unit (DGP) 7
The failure detection mechanism 8 is provided for each SCU,
, The flags of the failure display mechanisms 15 and 16 of the corresponding SCU are monitored, and when the failure display mechanisms 15 and / or 16 are turned on, the failure type is determined. At this time, when the intermittent failure is recognized, the output is activated to activate the failure counter 9.

The fault counter 9 is provided for each SCU.
When activated, the counter value is incremented by +1 (increment), and this value is input to one input terminal of the comparator 10. As the threshold value 11, a value for determining how many times an intermittent failure of the SCU has occurred within a certain period of time to determine whether to disconnect the SCU is stored in advance, and is input to another input terminal of the comparator 10. .

This comparator 10 is also provided for each SCU, and compares the threshold value 11 with the value of the fault counter 9. If the two values are equal, the comparator 10 outputs a signal to activate the software instruction interruption request mechanism 12. (That is, the output of the comparator 10 becomes active).

The software instruction interruption request mechanism 12 activates all the EPUs under the faulty SCU by the activation from the comparator 10.
In response, the software instruction interruption request
When the software instruction interruption completion communication, which is the response, is received from all the EPUs under the failed SCU, the processor disconnecting mechanism 13 is activated.

The communication path 21 is a general-purpose communication path connecting the EPUs 1, 2, 3, 4 and the DGP 7.

Here, focusing only on the EPU 1, the communication processing unit 17 determines the type of communication transmitted from the DGP 7 via the communication path 21, and if it recognizes that the communication is a software instruction interruption request communication, the software instruction interruption interruption unit 22 , And outputs the software instruction interruption completion communication output from the software instruction interruption mechanism 26 to the communication path 21.

Software instruction interruption interrupt mechanism 22
Holds the software instruction interruption request from the DGP 7 when activated.

The software instruction interruption mechanism 26 sends a software instruction interruption completion notification to the communication processing unit 17 when the software instruction interruption request is held by the software instruction interruption interrupt mechanism 22 after the currently executing software instruction is completed. , An idle loop is performed without executing the next software instruction.

The processor disconnecting mechanism 13 disconnects the SCU and also disconnects the EPU when the SCU is released.

When the EPU is detached, the processor relief mechanism 14 transfers information such as software-visible (accessible by software instructions) registers in the frozen EPU to another sound EPU, thereby executing the operation of the process. It is a continuation.

Next, the operation of the embodiment of the failure processing system of the information processing apparatus shown in FIG. 1 will be described.

When a failure occurs in the SCU 5, the DGP
The SCU fault detection mechanism 8 in 7 recognizes that a fault has occurred in the SCU 5 by lighting (ON) in the fault display mechanism 15 and analyzes the type of fault and determines that the fault is an intermittent fault, and when the fault is detected, the fault counter 9 Count up.

When the counter value of the fault counter 9 is equal to the threshold value 11, that is, when it is determined that the fault is a fixed fault, the comparator 10 outputs the software instruction interrupt request mechanism 12 to activate it.

This software instruction interruption request mechanism 12
Transmits a software command interruption request message to the EPU1 and EPU2 under the failure SCU5 via the communication path 21. Here, focusing only on the EPU 1, the communication is received by the communication processing unit 17, and when it is determined that the communication is the software instruction interruption request communication, the software instruction interruption interruption mechanism 22 is activated.

When the software instruction interruption interrupt mechanism 22 is activated and the software instruction interruption request is held, the software instruction interruption mechanism 26 transmits the software instruction interruption completion communication after the completion of the currently executing software instruction. , An idle loop is executed without executing the next software instruction.

As described above, the EPU disconnection in the idle loop state can be retried as in the case of "A" in FIG. 5, so that the processor relief always succeeds and the process is taken over by a healthy EPU. It is. The software command interruption completion communication is delivered to the DGP 7 through the communication processing mechanism 17 and the communication path 21.

The above operation is performed in EPU2 even in EPU2.
The same is done.

DGP7 is used for all EPUs under the failure SCU5.
Upon receiving the software instruction interruption completion communication from the CPU 1 or 2, the processor disconnecting mechanism 13 is activated, and the failed SCU is activated.
5 is cut off.

With the disconnection of the failed SCU 5, the subordinate EPUs 1 and 2 are also disconnected, and the processes executed in the EPUs 1 and 2 by the processor relief mechanism 14 are as follows.
Processor relief (rescue processing) is performed on a healthy EPU3 or EPU4. Here, since the processes executed in the EPUs 1 and 2 are all separated in the idle loop state as described above, the processor relief always succeeds.

FIG. 6 shows that the separation at "B" shown in FIG. 5 is improved from a non-retryable section to a retryable section by the method of the embodiment of the present invention.

As described above, when the SCU is disconnected due to the count-over of the intermittent fault, the process is aborted by waiting for the completion of the software instruction being executed in the EPU and disconnecting the EPU in a retryable state. And continuous operation becomes possible.

[0040]

DESCRIPTION OF THE PREFERRED EMBODIMENTS In order to explain the above-described embodiment of the present invention in more detail, an embodiment of the present invention will be described with reference to the drawings.

FIG. 3 is a block diagram showing a configuration of an information processing apparatus to which a failure processing system according to one embodiment of the present invention is applied, and FIG. 4 is a diagram showing details of FIG.

Referring to FIG. 3 and FIG. 4, when a failure occurs in the correctable sub-block (1) 40 inside the SCU 5, an EIF (error indication flip-flop) 15 is set.

The EIF 15 receives the DG via the diagnostic path 30
It is input to the SCU fault detection mechanism 8 in P7, and the detection mechanism 8 recognizes that an intermittent fault has occurred in the sub-block 1 (1) 40 of the SCU 5, and counts up the fault counter 9. A threshold value 37, which is the number of times that the SCU is regarded as a fixed failure due to frequent occurrence of intermittent failures, is stored in system setting information 35 such as a disk of the service processor. Is stored in

If the intermittent fault is set to be regarded as a fixed fault if it occurs three times in one hour, for example, the threshold value 37 in the system setting information 35 is set to "3" and the timer value 36 is set to "3". 1 hour ”. The timer 38 comprises a subtraction timer, and when its value becomes "0", the failure counter 9
Is cleared to “0”.

For this reason, in such a setting, "3" is stored in the threshold value storage register 11 and the number of fault occurrences counted up each time an intermittent fault occurs is stored in the fault counter 9; When the values of the two inputs are equal, that is, when three intermittent failures occur within one hour in the same SCU, the software instruction interruption request mechanism 1
The output signal is activated to activate the second signal.

The software instruction interruption requesting mechanism 12, which is the diagnostic control software 39, is connected to the EPU under the faulty SCU5.
Send software command interruption communication to 1 and 2, EP
Until the software instruction interruption completion communication is returned from U1, 2, the disconnection of the failed SCU 5 is waited for.

The software command interruption request communication transmitted from the DGP 7 is transmitted via the communication path 21 to the EPU 1, EP
Delivered to U2.

Focusing only on the EPU 1, the communication processing unit 17 sets the software instruction interruption display flag 31 of the software instruction interruption interruption mechanism 22 when judging that the arrived communication is the software instruction interruption request communication.

The software instruction interruption display flag 31
It is also a part of the request handler interrupt flag 32,
This is one of the factors for determining the request handler (request processing routine) 34 of the control firmware 33.

If any one of the request handler interrupt flags 32 is set, the request handler 34 determines the cause between the software instructions,
This is a part of the control firmware 33 that performs predetermined operation processing instructed by the control firmware prepared for each factor, and then shifts control to software execution again.

1 of the request handler interrupt flag 32
When the software instruction interruption display flag 31 is set, as described above, the software instruction is determined by the request handler 34 between the software instructions, and the software instruction interruption completion notification processing of the control firmware 33 is performed in a retryable state. The process moves to 26.

Software instruction interruption completion notification processing 26
Communicates the software instruction interruption completion communication via the communication processing mechanism 17 to the DGP 7 waiting for the process of disconnecting the failed SCU 5 to notify that the interruption of the software instruction has been completed in the EPU under the failed SCU.
After issuing it to P7, it enters an idle loop that is in a retryable state and prepares for disconnection of the EPU by DGP7.

As described above, when all the software instruction interruption completion messages from the EPUs 1 and 2 under the failed SCU 5 are received, the software instruction interruption requesting mechanism 12 activates the processor disconnecting mechanism 13 to disconnect the failed SCU 5 and Of the software visible registers of the subordinate EPUs 1 and 2 associated with the above, and the disconnection processing.

The processor relief mechanism 14 takes over the frozen contents of the separated EPUs 1 and 2 to the healthy EPU 3 or EPU 4 and performs the continuous operation of the process.

In the above embodiment, the number of SCUs included in the information processing apparatus is two, and the number of EPUs connected under the SCU is two. Needless to say, it is applicable.

[0056]

As described above, according to the present invention,
At the time of SCU disconnection due to intermittent failure count over,
By enabling the continuous operation without aborting the process, it is possible to effectively prevent serious damage such as a system down due to a hardware failure of the SCU.

This is because, in the present invention, the EPU is disconnected after waiting for the interruption of the software instruction being executed in the EPU and making it retryable.

[Brief description of the drawings]

FIG. 1 is a block diagram showing an embodiment of the present invention.

FIG. 2 is a diagram showing FIG. 1 in detail.

FIG. 3 is a block diagram showing an embodiment of the present invention.

FIG. 4 is a diagram showing FIG. 3 in detail.

FIG. 5 is a diagram showing a software instruction execution flow according to a conventional failure handling method.

FIG. 6 is a diagram showing a software instruction execution flow according to the fault handling method of the present invention.

[Explanation of symbols]

1, 2, 3, 4 arithmetic processing unit (EPU) 5, 6 system control processing unit (SCU) 7 diagnostic processing unit (DGP) 8 SCU failure detection mechanism 9 failure counter 10 comparator 11 threshold (threshold storage register) 12 software Instruction interruption request mechanism 13 Processor disconnection mechanism 14 Processor relief mechanism 15, 16 Fault indication mechanism (EIF) 17, 18, 19, 20 Communication processing mechanism 21 Communication path 22, 23, 24, 25 Software instruction interruption interrupt mechanism 26, 27, 28, 29 Software instruction interruption mechanism 30 Diagnostic pass 31 Software instruction interruption display flag 32 Request handler interrupt flag 33 Control firmware 34 Request handler 35 System setting information 36 Timer value 37 Threshold 38 Timer 39 Control software 40 Block (1) 41 sub-block (2) 42 sub-blocks (3) 43 sub-blocks (4) 44 sub-blocks (5) 45 sub-block (6)

──────────────────────────────────────────────────続 き Continued on the front page (58) Field surveyed (Int.Cl. ⁶ , DB name) G06F 11/14 310 G06F 11/20 310

Claims (2)

(57) [Claims] A system controller (hereinafter, referred to as "SCU") generates a faulty SC by a predetermined number of intermittent faults.
When disconnecting the U is performed, all of said subordinate disorders SCU
By sending a software instruction interruption request to all the arithmetic processing units (hereinafter referred to as “EPU”), it waits until the software instruction being executed in the EPU is completed,
Disconnecting the SCU after setting all the EPUs under the failed SCU to be in a retryable state, and performing a processor relief process of a process executed by the EPU under the SCU. . 2. A software instruction being executed in all EPUs under a failed SCU when a count value of a counter for monitoring an SCU failure and counting the intermittent failure of the SCU exceeds a predetermined threshold value. And the EPU restarts
In order to wait until a trial is possible , a software instruction suspend request is issued to all Es under the failed SCU.
A diagnostic processing unit for sending to the PU, the EPU notifies the diagnostic processing unit of the completion of the software instruction interruption after the execution of the software instruction based on the software instruction interruption request, and
By performing an idle loop without performing the preparation, disconnection in a retryable state is prepared, and the diagnostic processing unit performs all the EPs under the failed SCU.
When the U is ready to retry, the failed SCU is allocated.
A fault processing method, wherein the process is separated from the lower EPU and the process executed by the EPU under the faulty SCU is controlled to be continuously executed by a healthy EPU.