JP2013225217A - Multiprocessor system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a multiprocessor system capable of making fault analysis more efficient.SOLUTION: If a fault occurs in a CPU, a fault handling part determines how serious the fault is, collects fault data and analytic data according to the seriousness, and reports the fault to a fault processing part. The fault processing part checks whether a file system is available at the local processor or another processor, and then determines whether the collected data can be stored when the file system is available. When the data cannot be stored, an accessible file server is selected, a virtual file system is mounted, and the collected data is transmitted. After the collected data is stored, a CPU is reset.

Description

  The following embodiments relate to a multiprocessor system.

  Usually, a communication device such as a router is configured by mounting a substrate on which a processor or the like is mounted on a shelf. Since such a substrate is one unit as a configuration to be mounted on the shelf, it is hereinafter referred to as a substrate Unit.

  The conventional board Unit has a multiprocessor configuration with distributed functions. Incidentally, when a failure occurs in the board unit, it is required to analyze the failure and take measures. For this purpose, it is necessary to acquire data (failure data, analysis data, etc.) for analyzing the failure.

  WDT (Watch Dog Timeout) and other fault types are serious for the board unit in the main processor or sub-processor (conveniently divided into main and sub-processors for convenience, but not functionally different) Suppose a failure occurs. When fault data is collected, fault data, analysis data, and the like are stored in an area prepared for fault data collection in the file system or nonvolatile memory provided in the processor in which the fault has occurred. When the area cannot secure a sufficient capacity for the collected data in advance, only the minimum trouble data is selected and collected.

  If the sub-processor has a serious failure such as WDT, and the sub-processor does not have a file system, discard the fault data or use a processor with a file system (main processor Or other sub-processors). In fact, in embedded systems, there are many cases where a file system is not mounted on all processors due to cost.

  In the prior art, there is one that stores the contents of hardware for performing fault reproduction, fault detection, and status confirmation in a network server.

Japanese Patent Laid-Open No. 11-65898

Conventional technology cannot cope with the following problems.
(1) Since the capacity of the file system provided in the processor is small, when collecting only the minimum necessary data, it is possible that not all data effective for analysis is available.
(2) If the sub processor does not have a file system and the failure data is discarded, failure analysis becomes difficult.
(3) If the sub-processor does not have a file system and failure data is collected by a processor with a file system, the amount of collected data depends on the conditions of the file system on the processor side with the file system. It becomes the problem described in (1).

  In the following embodiments, a multiprocessor system capable of promoting the efficiency of failure analysis is provided.

  A multiprocessor system according to an aspect of the following embodiment is a multiprocessor system including a plurality of processors, and the processor includes a fault handling unit that collects data related to a fault according to the severity of the fault that has occurred. When the file server access unit for accessing an external file server and the file system is mounted on the own processor or another processor in the multiprocessor, it is determined whether or not data relating to the failure can be stored. Includes a failure processing unit that stores data related to the failure in the file system, and stores data related to the failure in the file server when the data cannot be stored.

  According to the following embodiments, it is possible to provide a multiprocessor system that can promote efficiency of failure analysis.

It is FIG. (1) explaining the 1st structural example of this embodiment. It is FIG. (2) explaining the 1st structural example of this embodiment. It is FIG. (3) explaining the 1st structural example of this embodiment. It is FIG. (4) explaining the 1st structural example of this embodiment. It is FIG. (5) explaining the 1st structural example of this embodiment. It is FIG. (6) explaining the 1st structural example of this embodiment. It is FIG. (7) explaining the 1st structural example of this embodiment. It is FIG. (8) explaining the 1st structural example of this embodiment. It is FIG. (9) explaining the 1st structural example of this embodiment. It is FIG. (10) explaining the 1st structural example of this embodiment. It is FIG. (11) explaining the 1st structural example of this embodiment. It is FIG. (12) explaining the 1st structural example of this embodiment. It is FIG. (13) explaining the 1st structural example of this embodiment. It is FIG. (14) explaining the 1st structural example of this embodiment. It is FIG. (15) explaining the 1st structural example of this embodiment. It is FIG. (16) explaining the 1st structural example of this embodiment. It is FIG. (17) explaining the 1st structural example of this embodiment. It is FIG. (18) explaining the 1st structural example of this embodiment. It is FIG. (1) explaining the 2nd structural example of this embodiment. It is FIG. (2) explaining the 2nd structural example of this embodiment. It is FIG. (The 3) explaining the 2nd structural example of this embodiment. It is FIG. (1) explaining the 3rd structural example of this embodiment. It is FIG. (2) explaining the 3rd structural example of this embodiment. It is FIG. (3) explaining the 3rd structural example of this embodiment. It is FIG. (1) explaining the case where this embodiment is applied to a concrete structure. It is FIG. (2) explaining the case where this embodiment is applied to a concrete structure. It is FIG. (3) explaining the case where this embodiment is applied to a concrete structure. It is FIG. (The 4) explaining the case where this embodiment is applied to a concrete structure. It is FIG. (5) explaining the case where this embodiment is applied to a concrete structure.

  In this embodiment, as a result of failure analysis in the failure handling unit, the failure type is a serious level that requires a reset of the CPU core such as Watch Dog Timeout (WDT), instruction exception, and memory exception. The failure data collection when a large amount of failure data is required is described.

  The board UNIT is a board on which a CPU and a memory are mounted. The board function is different for each required function. It is assumed that the board unit has a multiprocessor configuration in which functions are distributed.

  When a failure occurs in the main processor or sub processor, the failure handling unit performs failure analysis. Then, it is automatically determined whether or not the failure type is a serious level for the board unit (a serious failure that requires resetting the CPU core such as a WDT, an instruction exception, or a memory exception). Then, failure data and analysis data are collected in detail in the case of a serious level, and collection is not performed according to the situation in a minor case. When it can be determined that the failure type is a serious level, different failure data is automatically selected for each failure type, and data required for failure analysis that differs for each failure type (register information, memory information, call processing information) Is automatically selected. After collecting all the failure data and analysis data, reset the CPU. When collecting fault data and analysis data, whether the size of the information to be collected can be stored in the non-volatile memory in the board UNIT (non-volatile memory under its own processor and other processors) is automatically determined by inter-processor communication. judge. Only when the data cannot be stored, the sub processor selects a file system from the list of virtual file systems that can be configured, connects to an external file server, and collects and stores failure data.

  As described above, the failure data and the analysis data can be collected without depending on the limitation of the file system provided and the nonvolatile memory capacity.

  Therefore, it is possible to leave more failure information corresponding to the failure type as failure data.

  This makes it possible to leave more information as a failure log, making it easier to perform failure analysis and shortening the mean time to repair (MTTR) of the system.

1 to 18 are diagrams illustrating a first configuration example of the present embodiment.
In the first configuration example, a failure occurs in a sub processor other than the main processor, and the file system (or nonvolatile memory) is not provided in the sub processor, but is provided in the main processor. Indicates the case where the remaining file system is low.

  In FIG. 1, the board Unit 9 is composed of a sub processor 10 and a main processor 11. The distinction between the main processor 11 and the sub-processor 10 is convenient and may be the same processor. Here, it is assumed that a failure occurs in the sub processor 10. In the CPU 12 of the sub-processor 10, when the CPU core detects a failure, this is notified to the system failure interrupt unit 12. The system fault interrupt unit 12 issues an interrupt command, which is notified to the fault handling unit 14, the fault handling unit 14 is activated, and a fault analysis process as described later is performed. The failure handling unit 14 is also activated when a failure occurs in the execution of the program for realizing the function of the board unit, which is executed by the CPU. The Call processing unit 22 in FIG. 1 performs a calling process such as a subroutine of the main program, and activates the failure handling unit 14 when an abnormality occurs in the calling process. The failure analysis result of the failure handling unit 14 is notified to the failure processing unit 15. Since the sub processor 10 does not have a file system, the failure processing unit 15 inquires of the file system remaining amount check unit 19 of the main processor 11 about the remaining amount of the file system 20 of the main processor 11. When the remaining amount of the file system 20 is small and failure data cannot be stored, the failure processing unit 15 requests the virtual file system protocol processing unit 16 to access the file system of the file server 21. The virtual file system protocol processing unit 16 processes protocols such as NFS (Network File System) and VFS (Virtual File System). The access request processed by the virtual file system protocol processing unit 16 is notified to the file server 21 via the ETH (Ethernet) driver 17 and the physical interface PHY18. Thereby, the failure data and the like are stored in the file system of the file server 21. After storing the failure data or the like, the failure processing unit 15 resets the CPU 12.

  The system failure interrupt unit 13 activates the failure handling unit 14. The fault handling unit 14 performs a fault analysis and automatically determines a seriousness degree for determining a serious fault that requires a CPU reset. Data is collected if it is a serious level, and data is not collected if it is not serious. Furthermore, depending on the serious level of failure factor (by factors such as WDT, instruction exception, memory exception, etc.), the effective failure data is automatically selected for each, and the data required for each analysis by the serious level of failure factor ( Register information, memory information, call processing information). Then, the failure handling unit 14 activates the failure processing unit.

  FIG. 2 is a flowchart showing the operations of the system fault interrupt unit and the fault handling unit.

  When a failure is detected in the CPU, the system failure interrupt unit stores the program to be activated as a vector table based on the failure interrupt number. In step S11, the failure handling is performed using an index value that indicates the type of failure. Start the department. In addition to the activation from the system failure interrupt unit, the failure handling unit is also activated when a failure occurs in the call processing. In step S12, when an abnormality is detected in the call process, the fault handling unit is activated using an index value that indicates the fault type.

  In step S13, the fault handling unit automatically determines the severity of the fault. In step S14, it is determined whether or not to collect failure data according to the severity of the failure. Data is collected if the severity is high, and data is not collected if the severity is low. Here, activation of the fault handling unit from the system fault interrupt unit is determined as a serious failure, and activation from the Call processing unit is determined as a minor failure. Then, for both serious and minor obstacles, the severity is examined to determine whether data is collected. If it is determined in step S14 that failure data is not collected, the process proceeds to step S17. If it is determined in step S14 that failure data is to be collected, collection failure data automatic selection processing is performed in step S15, collection analysis data automatic selection processing is performed in step S16, and the process proceeds to step S17. In step S17, failure notification is sent to the failure processing unit together with the presence / absence of data collection, failure data type, and analysis data type. Details of steps S13, S15, and S16 will be described below.

3 and 4 are diagrams illustrating the automatic severity determination process.
FIG. 4 is a diagram illustrating an example of the severity determination table.

  When a failure occurs, a failure number is notified to the failure handling unit. This failure number is associated with an address where a program to be started is stored, and this address is called a vector address. The seriousness determination table is provided for system failures and minor failures. In the system failure severity determination table (1), a flag indicating whether or not failure data is collected and a numerical value indicating the failure severity are stored in advance using the vector address as an index. In the minor failure severity determination table (2), a failure type is used as an index, and a flag indicating whether or not failure data is collected and a numerical value indicating the failure severity are stored in advance.

  In the flowchart of FIG. 3, in step S20, it is determined whether the failure that has occurred is a system failure such as an exception interrupt from the system failure interrupt unit or a failure from the Call processing unit. A failure from the call processing unit is determined to be a minor failure.

  If it is determined in step S20 that there is a system failure such as an exception interrupt, in step S21, the system failure severity determination table ((1) in FIG. 4) is referred to using the received vector address as an index. In step S22, it is determined whether the failure data collection flag is ON. If it is determined in step S22 that the flag is ON, failure severity data is returned as a return value in step S23, and the process ends. If it is determined in step S22 that the flag is OFF, the failure severity data is set to 0 and returned as a return value in step S24, and the process ends.

  If it is determined in step S20 that the failure is a minor failure, in step S25, the minor failure seriousness determination table ((2) in FIG. 4) is referenced using the failure type as an index. In step S26, it is determined whether the failure data collection flag is ON. If it is determined in step S26 that the flag is ON, the severity data is returned as a return value in step S27, and the process ends. If it is determined in step S26 that the flag is OFF, in step S28, the severity data is set to 0 and returned as a return value, and the process ends.

5 and 6 are diagrams for explaining the collection failure data automatic selection process.
FIG. 6 is a diagram illustrating an example of a system failure collection failure data table. Here, an example of a table having a secondary table structure is shown, but a primary structure may be used. The table of (1) stores the vector address indicating the index of the table of (2) and the valid bit of the address using the severity data as an index. The valid bit of the address indicates whether or not the registered vector address is valid. The table (2) stores failure data and its valid bits using the vector address obtained in the table (1) as an index. The failure data is data indicating the content of the failure that has occurred.

  In the flowchart of FIG. 5, in step S30, it is determined whether the failure is a system failure or a minor failure. If it is determined in step S30 that a system failure has occurred, in step S31, the system failure collection failure data table shown in FIGS. 6A and 6B is referred to using the severity data and the vector address as indexes. If it is determined in step S30 that the fault is minor, in step S32, the minor fault collected fault data table is referenced using the severity data and the fault type as an index. FIG. 6 shows only the system failure collection failure data table, but in the case of a minor failure collection failure data table, the table (1) in FIG. 6 stores the failure type with the severity data as an index. It will be a thing. Similarly, the table of (2) in FIG. 6 stores failure data using the failure type as an index. In step S33, the collection failure data information is returned as a return value, and the process is terminated.

7 and 8 are diagrams for explaining the analysis data automatic selection process.
FIG. 8 is a diagram illustrating an example of a system failure analysis data table. Here, a table having a secondary table structure is shown, but a table having a primary structure may be used. The table of (1) in FIG. 8 stores the vector address which is the index of the table of (2) in FIG. 8 and the valid bit of the address, using the severity data as an index. The valid bit of the address indicates whether or not the registered vector address is valid. The table of (2) in FIG. 8 stores analysis data and its valid bits using the vector address obtained in the table of (1) of FIG. 8 as an index. The analysis data is data indicating what kind of hardware operation was performed in the failure that occurred. The analysis data is used for failure analysis.

  In FIG. 7, it is determined in step S35 whether the failure is a system failure or a minor failure. If it is determined in step S35 that there is a system failure, in step S36, the system failure analysis data table is referenced using the severity data and the vector address as an index. If it is determined in step S35 that the failure is minor, in step S37, the minor failure analysis data table is referred to using the severity data and the failure type as an index. FIG. 8 shows only the system failure analysis data table, but in the case of a minor failure analysis data table, the table (1) in FIG. 8 stores the failure type using the severity data as an index. Become. Similarly, the table of (2) in FIG. 8 stores analysis data using the failure type as an index. In step S38, the analysis data is returned as a return value, and the process ends.

  The failure processing unit calculates the collected data size from the information passed from the failure handling unit. In addition, it is determined whether a file system exists under its own processor, and if it exists, it is determined whether data can be collected based on the remaining amount. If the file system does not exist under its own processor, it is determined whether the file system exists under another processor, and if it exists, it is determined whether data can be collected. When there is a file system under another processor, the remaining amount of the file system under the other processor is determined by inter-processor communication in order to determine whether the remaining amount of the file system of the other processor is large enough to store data. Check. The check result is returned as a return value, and it is determined whether data can be collected. A file system is selected from the list data to which the virtual file system is connected from the list data with the highest priority. In addition, the system Call is used to mount the file system on the file server ahead of the LAN via the virtual file system protocol (NFS or VFS). The failure factor and the failure data are output to any one of the non-volatile memory under the own processor / non-volatile memory under the other processor / virtual file system. Wait until the cause of the failure and the output of the failure data are complete, then issue a reset signal to the CPU to reset it.

FIG. 9 is a flowchart showing the flow of processing of the failure processing unit.
When the failure processing unit is activated from the failure handling unit, the collected data size is calculated from the information passed from the failure handling unit in step S40. In step S41, an inquiry is made as to whether data can be stored in the non-volatile memory of its own processor or another processor. The remaining amount of the storage area of the file system of another processor is inquired by inter-processor communication.

  If it is determined in step S42 that data cannot be collected, a file server is selected from the file server connection destination list to which the virtual file system is connected in step S43, and the virtual file system is selected in step S44. Mount. In step S45, the failure factor, failure data, and failure analysis data are output to the virtual file system, and the process proceeds to step S46.

  If it is determined in step S42 that data can be collected, it is determined in step S48 whether the collection destination is the local processor or another processor. If it is determined in step S48 that the data is to be stored in its own processor, in step S49, the failure factor, failure data, and failure analysis data are output to the nonvolatile memory of the own processor. If it is determined in step S48 that the data is stored in another processor, in step S50, the failure factor, the failure data, and the failure analysis data are output to the non-volatile memory of the other processor. Whether to select the own processor or another processor in step S48 depends on the result of the process described in FIG.

  In step S46, it waits for the output of the failure factor, failure data, and failure analysis data to be completed, and in step S47, the CPU is reset.

  FIG. 10 is a flowchart of the self-processor / other processor non-volatile memory storable selection process.

  In step S55, it is determined whether or not the own processor has a file system. If it is determined in step S55 that there is no file, it is determined in step S56 whether the other processor has a file system. If YES in step S56, the remaining file system remaining capacity of other processors is checked by inter-processor communication in step S57. In step S58, it is determined whether there is a remaining amount. If it is determined in step S58 that there is no data, in step S59, a determination that data collection is impossible is returned as a return value, and the process is terminated. If it is determined in step S58 that the data is present, in step S60, a determination that data can be collected by another processor is returned as a return value, and the process ends.

  If it is determined in step S56 that there is no file system in another processor, in step S61, a determination that data collection is impossible is returned as a return value, and the process is terminated.

  If it is determined in step S55 that the processor has a file system, the input file size is compared with the remaining amount of the file system of the processor in step S62. In step S63, it is determined whether the remaining amount is sufficient. If it is determined in step S63 that the remaining amount is insufficient, a determination that data collection is impossible is returned as a return value in step S64, and the process ends. If it is determined in step S63 that the remaining amount is sufficient, in step S65, a determination that data can be collected by the own processor is returned as a return value, and the process ends.

  FIG. 11 is a flowchart of the remaining processor file system remaining amount check process (step S41 in FIG. 9).

  In step S70, a request for checking the remaining capacity of the file system is transmitted from the requesting processor to the requesting other processor through inter-processor communication. In step S71, the other processor receives a request for checking the remaining capacity of the file system. In step S72, the necessary file size is checked. In step S73, the other processor notifies the self processor of the check result through inter-processor communication. In step S74, the processor itself receives the result through inter-processor communication, and returns the result as a return value in step S75, and ends the process.

  12 and 13 are diagrams for explaining the virtual file system selection process (step S43 in FIG. 9).

  FIG. 13 is a diagram illustrating an example of the connection destination file server list of the virtual file system. Register the IP address and priority of the file server to connect to the list. A list of file servers to which these virtual file systems are connected is stored in the RAM in list format data that can be referred to by the CPU program. Several of the connection destinations in the list are prepared as system defaults. This data is loaded onto the RAM when the system is started up.

The priority is determined based on the following concept.
-At the time of default system fixed data (prepared by data in ROM program), give a priority of 0-10 (the smaller the number, the higher the priority).
When the system starts up, it is loaded onto the RAM to form list format data. Then, ping is sent from the IP address at the top of the list, and the server with the smaller number of hops is the closest server, and the list is rearranged from the one with the smaller “priority x hop number”. To be higher. The next highest priority can be selected by searching for data from the top of the list data.

  12, in step S80, the connection destination file server list table of the virtual file server is searched, and in step S81, the IP address is extracted from the head of the virtual file server connection destination file server list table. In step S82, a ping is sent to the acquired IP address to check whether a reply can be obtained. If the ping transmission is OK in step S83, the virtual file server with the IP address is set as the connection target in step S84. If the ping transmission is NG in step S83, the process returns to step S80.

  14 to 16 are diagrams for explaining a method of generating a connection destination file server list table of the virtual file server.

  FIG. 16 shows an example of fixed data of the IP address of the default file server. In FIG. 16, the IP address of the connection destination file server is listed, and the one with a high temporary priority is registered at the top of the list. Since this is a default list, it is created in advance at the time of designing the system, and is stored in a ROM or the like.

  In the flowchart of FIG. 14, in step S89, the fixed data of the IP address of the default file server list is read. In step S90, one fixed data of the default file server IP address is read from the head. In step S91, a ping is transmitted to the read IP address. In step S92, it is determined whether a reply can be normally obtained. If a reply cannot be obtained normally in step S92, the process returns to step S89. If a reply is normally obtained in step S92, the number of hops received as a result of the ping is acquired in step S93. In step S94, (data index value (temporary priority)) × (hop number value) = (main priority) is stored in the work area, and the process returns to step S89. When the processing from step S89 to step S94 is performed for the IP addresses in all the fixed data in the default list, in step S95, the virtual file server connection destinations are rearranged while rearranging the work area information in this priority order. Generate a file server list table.

  The operation process of FIG. 15 means a process of accepting an operation from the user. In FIG. 15, in step S96, the connection destination of the virtual file system to be added or changed is received by an operation from the user. In step S97, ping is transmitted to the accepted IP address. In step S98, it is determined whether a ping reply has been received normally. If the ping reply can be received normally, the number of hops is acquired from the ping result in step S99. In step S100, the IP address is stored in the work area as (data index value (temporary priority)) × (value of hop number) = (main priority), and the process proceeds to step S102. In step S98, if the ping reply cannot be received normally, in step S101, the user is notified (displayed) that the IP address cannot be added or changed, and the process proceeds to step S102. In step S102, the virtual file server connection destination file server list table is generated while the work area information is rearranged in the order of the priorities, and the process ends.

FIG. 17 is a diagram illustrating the overall operation of the first configuration example.
First, assume that a failure occurs in the CPU (1). Then, a system fault is notified to the fault handling unit via the system fault interrupt unit (2). The fault handling unit performs processing of a fault severity automatic determination unit, a collected fault data automatic selection unit, and a collected analysis data automatic selection unit, and notifies the fault processing unit of faults. In the failure processing unit (3), the collection size of failure data is calculated. Then, it is determined whether the own processor has a file system and whether another processor has a file system. When there is a file system in another processor (for example, main processor), the remaining amount of the file system of the other processor is checked by inter-processor communication. Assume that it is determined that there is not enough remaining capacity in the file system of another processor. Then, referring to the connection destination file server list data, the connection destination file server is selected from the list. Then, the virtual file system is mounted, and the failure factor, failure data, and failure analysis data are output to the virtual file system. Wait for the data output to complete and reset the CPU.

FIG. 18 is a sequence diagram illustrating a flow of a series of processes in the first configuration example.
When failure detection occurs in the CPU, the failure handling unit performs failure analysis, automatic determination of failure severity, automatic collection failure data selection, automatic collection analysis data selection, and sends failure notification to the failure processing unit. Note that the collection failure data automatic selection and the collection analysis data automatic selection branch different processes according to the severity and perform different processes.

  When receiving a failure notification, the failure processing unit inquires whether failure data or analysis data can be stored in the non-volatile memory of its own processor / other processor. The own processor / other processor non-volatile memory storage possibility determination unit determines whether the own processor has a file system and whether the other processor has a file system. In this case, assume that another processor has a file system. Then, the file system remaining amount check unit requests another processor (main processor) to check the remaining amount of the file system through inter-processor communication. The file system remaining amount check unit of the main processor receives the remaining amount check request, checks the necessary file size, obtains the remaining amount by accessing the nonvolatile memory, and notifies the own processor (sub processor) of the result. The sub processor's own processor / other processor non-volatile memory storage possibility determination unit determines whether the remaining amount is sufficient. In this case, it is assumed that the remaining amount is insufficient. Then, the failure processing unit is notified that the data cannot be collected. The failure processing unit refers to the connection destination file server list data, selects a file server from the list, mounts the virtual file system, and accesses the file system of the file server. Then, the failure factor, failure data, and analysis data are output to the file system of the file server, and the CPU is reset.

19 to 21 are diagrams illustrating a second configuration example of the present embodiment.
In the second configuration example, when a failure occurs in the main processor or sub processor and the own processor has a file system (or non-volatile memory), the remaining amount is small and the virtual file system is accessed. explain.

  19, the same components as those in FIG. 1 are denoted by the same reference numerals, and the description thereof is omitted.

In FIG. 19, the own processor is a main processor or a sub processor.
The system failure interrupt unit 13 receives the failure of the CPU 12 and activates the failure handling unit 14. The failure handling unit 14 performs failure analysis, and the failure processing unit 15 is activated based on the information. The own processor is provided with the file system 30, but the remaining amount is assumed to be small. Therefore, the file server is selected, the failure factor, failure data / failure analysis data are stored, and the CPU is reset.

FIG. 20 is a diagram illustrating an overall flow of the second configuration example.
First, assume that a failure occurs in the CPU (1). Then, a system fault is notified to the fault handling unit via the system fault interrupt unit (2). The fault handling unit performs processing of a fault severity automatic determination unit, a collected fault data automatic selection unit, and a collected analysis data automatic selection unit, and notifies the fault processing unit of faults. In the failure processing unit (3), the collection size of failure data is calculated. Then, it is determined whether the processor has a file system. If the own processor has a file system, the remaining amount of the file system of the own processor is checked. Assume that it is determined that there is no remaining capacity in the file system of its own processor. Then, referring to the connection destination file server list data, the connection destination file server is selected from the list. Then, the virtual file system is mounted, and the failure factor, failure data, and failure analysis data are output to the virtual file system. Wait for the data output to complete and reset the CPU.

FIG. 21 is a sequence diagram illustrating a flow of a series of processes in the second configuration example.
When a failure is detected in the CPU, the failure handling unit performs failure analysis, automatic determination of failure severity, automatic collection failure data selection, collection analysis data automatic selection (collection data automatic selection), and failure notification failure processing To the department. Note that the automatic selection of collected data branches different processes according to the severity and performs different processes.

  When receiving the failure notification, the failure processing unit inquires whether failure data, analysis data, or the like can be stored in the nonvolatile memory of the own processor. The file system remaining amount check unit requests its own processor to check the remaining amount of the file system. The file system remaining amount check unit of the own processor receives the remaining amount check request, acquires the remaining amount of the file system, and notifies the failure processing unit of the result. The failure processing unit determines whether the remaining amount is sufficient. In this case, it is assumed that the remaining amount is insufficient. The failure processing unit refers to the connection destination file server list data, selects a file server from the list, mounts the virtual file system, and accesses the file system of the file server. Then, the failure factor, failure data, and analysis data are output to the file system of the file server, and the CPU is reset.

22 to 24 are diagrams illustrating a third configuration example of the present embodiment.
In FIG. 22, the same components as those in FIG. 19 are denoted by the same reference numerals, and description thereof will be omitted.

  The third configuration example shows a case where a failure occurs in the main processor or sub processor, and the file system (or non-volatile memory) is not provided in the own processor and other processors.

  The system failure interrupt unit 13 receives the failure of the CPU 12 and activates the failure handling unit 14. The failure handling unit 14 performs failure analysis, and the failure processing unit 15 is activated based on the information. Select the file server, store the cause of failure, failure data, failure analysis data, and reset the CPU.

FIG. 23 is a diagram illustrating an overall flow of the third configuration example.
First, assume that a failure occurs in the CPU (1). Then, a system fault is notified to the fault handling unit via the system fault interrupt unit (2). The fault handling unit performs processing of a fault severity automatic determination unit, a collected fault data automatic selection unit, and a collected analysis data automatic selection unit, and notifies the fault processing unit of faults. In the failure processing unit (3), the collection size of failure data is calculated. Then, it is determined whether the own processor and the other processor have a file system. Assume that it is determined that there is no file system in the own processor and other processors. Then, referring to the connection destination file server list data, the connection destination file server is selected from the list. Then, the virtual file system is mounted, and the failure factor, failure data, and failure analysis data are output to the virtual file system. Wait for the data output to complete and reset the CPU.

FIG. 24 is a sequence diagram illustrating a flow of a series of processes of the third configuration example.
When a failure is detected in the CPU, the failure handling unit performs failure analysis, automatic determination of failure severity, automatic collection failure data selection, collection analysis data automatic selection (collection data automatic selection), and failure notification failure processing To the department. Note that the automatic selection of collected data branches different processes according to the severity and performs different processes.

  When receiving the failure notification, the failure processing unit determines whether the own processor or another processor has a file system. In this case, it is assumed that neither the own processor nor another processor has a file system. The failure processing unit refers to the connection destination file server list data, selects a file server from the list, mounts the virtual file system, and accesses the file system of the file server. Then, the failure factor, failure data, and analysis data are output to the file system of the file server, and the CPU is reset.

25 to 29 are diagrams for explaining a case where the present embodiment is applied to a specific configuration.
With reference to FIG. 25 to FIG. 27, a description will be given of a case where a file system is not provided in the sub processor when a WDT occurs in the sub processor and a file system having a sufficient capacity exists in the main processor.

In FIG. 25, when the WDT is generated in the sub processor 10, the WDT driver 40 generates an interrupt indicating the generation of the WDT. Also, failure type analysis and failure collection data automatic judgment are performed. An OS (Operating System) 41 notifies an interrupt from the WDT driver 40 to the data collection processing unit 42 via an interrupt handler. The data collection processing unit 42 is activated from the OS 41 via an interrupt handler and sequentially performs the following processing.
(1) Accepting an interrupt request (2) Inter-processor communication for checking the remaining file system of the main processor 11 is performed to check whether there is enough size to store the failure data.
(3) Select a high priority file server list data to which the virtual file system is connected.
(4) Mount the file system on the file server ahead of the LAN via the virtual file system protocol (NFS or VFS) using the system call.
(5) Save all WDT factors and failure data on the virtual file system. (6) Reset the CPU.

  The communication driver 43 is a driver (such as a PCI (Peripheral Component Interconnect) bus driver, an interrupt driver) for communicating with the main processor 11. When there is an inquiry, the size check processing unit 44 on the main processor side checks the usable size of the file system and performs processing for notifying the sub processor 10 of the result. The virtual file system protocol 45 is a protocol such as NFS (Network File System) or VFS (Virtual File System). The ETHER NET driver (ETH driver) 46 is a driver for performing communication by Ethernet (registered trademark), and is a driver that controls the PHY 47 and is controlled by the virtual file system protocol. The PHY 47 is a physical device that connects to a server via a LAN. The LAN 48 connects the file server 49 and the board unit 9. The file server 49 is a server virtually connected to the board unit 9.

  A WDT is generated in the sub processor, and a hangup notification (WDT interrupt) is detected by the WDT driver. When a WDT occurs in the processor, the WDT driver generates a User interrupt that has the meaning of generating a WDT. The OS processing is to notify the data collection processing unit of a User interrupt from the WDT driver via an interrupt handler. The data collection processing unit accepts an interrupt request.

  The data collection processing unit communicates with the main processor by the PCI communication processing of FIGS. If there is still enough size to save the failure data in the file system of the main processor, all the WDT factors and failure data on the sub processor side are transmitted and stored by PCI communication to the file system under the main processor. Then, reset the CPU and restart the sub processor.

  FIG. 26 is a diagram for explaining PCI communication processing for checking the remaining amount of the file system.

  In step S110, the sub processor (assuming that a failure has occurred) starts PCI communication, and in step S111, the communication type of the PCI space is written in the register. Here, a file size check is written. In step S116, a communication trigger for the PCI space is written to a register in the PCI transmission A-> B direction. The main processor polls the communication area in step S112, and recognizes the communication trigger in step S113. In step S114, the communication request is recognized and a PCI interrupt is generated. In step S123, the communication request is read. In step S115, the remaining amount of the file system is checked. In step S118, the PCI space communication result is written in the register, and in step S119, the PCI space communication trigger is written in the PCI transmission B-> A direction register. Here, the result is data indicating that data can be collected. The sub processor starts polling of the communication area in step S117, and recognizes a communication trigger from the main processor in step S120. In step S121, the communication request is recognized and a PCI interrupt is generated. In step S122, the PCI communication result is read, and the process ends.

FIG. 27 is a diagram for explaining PCI communication when writing WDT factors, failure data, and the like.
In step S130, the sub processor starts PCI communication. In step S131, the sub processor writes the communication type of the PCI space in the register. Here, writing to write the file is performed. In step S132, a PCI space communication trigger is written to a PCI transmission A-> B direction register. In step S133, the file size and the file are written to the PCI space transmission register. The main processor polls the communication area in step S134, and recognizes a communication trigger in step S135. In step S136, the communication request is recognized and a PCI interrupt is generated. In step S137, the communication request is read. In step S138, the contents of the file corresponding to the file size are read and written to the own file system. In step S139, the PCI space communication result is written to the register, and in step S140, the PCI space communication trigger is written to the PCI transmission B-> A direction register. In step S141, the sub-processor starts polling the communication area, and recognizes a communication trigger in step S142. In step S143, the communication request is recognized and a PCI interrupt is generated. In step S144, the PCI communication result is read, and the process ends.

  Next, a description will be given of a case where a file system is not provided in the sub processor and a file system having a sufficient capacity does not exist in the main processor when a WDT occurs in the sub processor.

  The WDT is generated in the sub processor and the hangup notification (WDT T.O interrupt) is detected by the WDT driver. When a WDT occurs in the processor, the WDT driver generates a User interrupt that has the meaning of generating a WDT. The OS processing is to notify the data collection processing unit of a User interrupt from the WDT driver via an interrupt handler. The data collection processing unit accepts an interrupt request. The data collection processing unit communicates with the main processor by the PCI communication process of FIG. If there is not enough size to store the failure data, the list data to which the virtual file system is connected is selected from the list data with higher priority. Next, the system Call is used to mount the file system on the file server ahead of the LAN via the virtual file system protocol (NFS or VFS). If the return value of the system call is normal and the mount is successful, save all WDT factors and failure data in the file system. The CPU is reset and the virtual file is unmounted at the same time.

  FIG. 28 is a diagram for explaining PCI communication when a file remaining amount inquiry is made. FIG. 28 is the same as FIG. 26, and the same steps are denoted by the same step numbers and the description thereof is omitted.

  In FIG. 28, the result of checking the remaining amount of the file system in step S115 indicates that the remaining amount is not sufficient, and the fact that data cannot be collected is written in the register as a communication result.

  Next, a case where a file system provided in the main processor cannot secure a sufficient capacity for collected data when a WDT occurs in the main processor will be described with reference to FIG.

  In FIG. 29, the same components as those in FIG. 25 are denoted by the same reference numerals, and the description thereof will be omitted.

  The data collection processing unit 42 is started from the OS via an interrupt handler, checks the remaining capacity of its own file system, and checks whether there is enough size to store the failure data. If there is not enough storage space, select the file server list data to which the virtual file system is connected from the one with higher priority, use the system call, and via the virtual file system protocol (NFS or VFS) Mount the file system on the destination file server from the LAN. Then save all WDT factors and failure data on the virtual file system and reset the CPU.

  A WDT occurs in the main processor, and a hangup notification (WDT T.O interrupt) is detected by the WDT driver. When a WDT occurs in the processor, the WDT driver generates a User interrupt that has the meaning of generating a WDT. The OS notifies a user interrupt from the WDT driver to the data collection processing unit via an interrupt handler. The data collection processing unit accepts an interrupt request. After that, it checks its own file system remaining capacity and checks whether there is enough size to store the failure data. If there is still enough size to store the fault data, store the fault data in the file system under its own processor and reset the CPU. If there is not enough size to store the failure data, the one with higher priority is selected from the file server list data to which the virtual file system is connected.

  Next, the system Call is used to mount the file system on the file server ahead of the LAN via the virtual file system protocol (NFS or VFS). If the return value of the system call is normal and the mount is successful, save all WDT causes and failure data to the file system and reset the CPU. The virtual file is also unmounted by CPU reset.

10 Sub-processor 11 Main processor 12 CPU
13 System fault interrupt unit 14 Fault handling unit 15 Fault processing unit 16, 45 Virtual file system protocol processing unit 17, 46 ETH driver 18, 47 PHY
19 File system remaining amount check unit 20, 30 File system 21, 49 File server 22 Call processing unit 40 WDT driver 41 OS
42 Data Collection Processing Unit 43 Communication Driver 44 Size Check Processing Unit 48 LAN

Claims (9)

A multiprocessor system having a plurality of processors,
The processor
Depending on the severity of the failure that occurred, a failure handling unit that collects data about the failure,
A file server access unit for accessing an external file server;
When a file system is mounted on the own processor or another processor in the multiprocessor system, it is determined whether data relating to the failure can be stored. If the data can be stored, the data relating to the failure is stored in the file system. If the data cannot be stored, a failure processing unit that stores data related to the failure in the file server;
A multiprocessor system comprising:   The multiprocessor system according to claim 1, wherein the failure having a severity level for collecting data related to the failure is a failure that requires a CPU reset.   The multiprocessor system according to claim 2, wherein the CPU is reset after the failure processing unit stores data related to the failure in the file system or the file server.   2. The multiprocessor according to claim 1, wherein the failure processing unit stores data relating to the failure in the file server when the file system is not installed in a local processor or another processor. 3. system.   The multiprocessor system according to claim 1, wherein the failure processing unit inquires whether or not the other processor has a capacity for storing data related to the failure using inter-processor communication.   The multiprocessor system according to claim 1, wherein the data relating to the failure includes failure data according to a failure factor, a failure type, and analysis data used for failure analysis.   The multiprocessor system according to claim 1, wherein the file system is provided in a nonvolatile memory mounted on the processor. A failure information storage method in a multiprocessor system provided with a plurality of processors each having a file server access unit for accessing an external file server,
The processor
Depending on the severity of the failure that occurred, collect data about the failure,
When a file system is mounted on the own processor or another processor in the multiprocessor system, it is determined whether data relating to the failure can be stored. If the data can be stored, the data relating to the failure is stored in the file system. If the data cannot be stored, the data related to the failure is stored in the file server.
A failure information storage method characterized by the above.   10. The failure information storage method according to claim 9, wherein when the file system is not installed in the own processor or the other processor, the data relating to the failure is stored in the file server.

Images