WO2012066622A1 - アクセス方法、およびマルチコアプロセッサシステム - Google Patents

アクセス方法、およびマルチコアプロセッサシステム Download PDF

Info

Publication number
WO2012066622A1
WO2012066622A1 PCT/JP2010/070319 JP2010070319W WO2012066622A1 WO 2012066622 A1 WO2012066622 A1 WO 2012066622A1 JP 2010070319 W JP2010070319 W JP 2010070319W WO 2012066622 A1 WO2012066622 A1 WO 2012066622A1
Authority
WO
WIPO (PCT)
Prior art keywords
access
application
core processor
cpu
processor system
Prior art date
Application number
PCT/JP2010/070319
Other languages
English (en)
French (fr)
Inventor
浩一郎 山下
宏真 山内
鈴木　貴久
康志 栗原
早川　文彦
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to EP10859635.4A priority Critical patent/EP2642399A1/en
Priority to CN201080070131.7A priority patent/CN103210381B/zh
Priority to PCT/JP2010/070319 priority patent/WO2012066622A1/ja
Priority to JP2012544021A priority patent/JP5541368B2/ja
Publication of WO2012066622A1 publication Critical patent/WO2012066622A1/ja
Priority to US13/894,022 priority patent/US9164823B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0721—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU]
    • G06F11/0724—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU] in a multiprocessor or a multi-core unit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3041—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is an input/output interface
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3485—Performance evaluation by tracing or monitoring for I/O devices

Definitions

  • the present invention relates to an access method for accessing a device to be monitored and a multi-core processor system.
  • a control device is provided in a multiple CPU and multiple I / O (Input / Output) sharing system, and a control signal is stored if the startup I / O is in operation.
  • I / O Input / Output
  • a technique of transmitting a dummy I / O after the operation is completed is disclosed (for example, see Patent Document 3 below).
  • Patent Document 1 and Patent Document 2 are intended for abnormality due to hardware failure.
  • a failure that occurs due to access to a device by software is determined to be normal by the techniques according to Patent Documents 1 and 2, and an abnormal state is overlooked.
  • the problematic application software (hereinafter referred to as an application) stalls while acquiring access rights to the shared device, and other applications have access rights to the shared device.
  • the state that cannot be obtained occurs.
  • stalls occurred in a chain, that is, other apps for which access rights could not be acquired.
  • it is necessary to determine which of the stalled applications is problematic software.
  • An object of the present invention is to provide an access method and a multi-core processor system capable of detecting an application stall caused by access to a shared device in order to solve the above-described problems caused by the prior art.
  • the disclosed access method activates a driver corresponding to the first CPU based on the start of execution of the first application, and measures the access time based on access to the peripheral device. When the access time exceeds a predetermined time, a detection signal for resetting the driver is output and writing to a register holding data to be written from the first CPU to the peripheral device is prohibited.
  • This access method and multi-core processor system have the effect of being able to detect application stalls that occur due to access to shared devices.
  • FIG. 3 is a block diagram illustrating functions of a device monitoring apparatus 103.
  • FIG. 4 is an explanatory diagram showing an operation during normal operation of the multi-core processor system 100.
  • FIG. 6 is an explanatory diagram showing an operation before an abnormal state occurs in the multi-core processor system 100.
  • FIG. 11 is an explanatory diagram showing an operation after occurrence of an abnormal state of the multi-core processor system 100.
  • FIG. 11 is an explanatory diagram illustrating a restoration operation from an abnormal state of the multi-core processor system 100.
  • 4 is a flowchart showing processing until an abnormal state of the multi-core processor system 100 is detected.
  • 4 is a flowchart showing a restoration process from an abnormal state of the multi-core processor system 100.
  • the multi-core processor system 100 includes shared devices 105_0 to 105_3.
  • the shared device 105_0 and the shared device 105_1 are connected to the bus 104 via the device monitoring apparatus 103_0, and the shared device 105_2 is connected to the bus 104 via the device monitoring apparatus 103_1.
  • the shared device 105_3 is directly connected to the bus 104.
  • the CPUs 101 # 0 to 101 # n include INT (Interrupt) terminals 106 # 0 to 106 # n, which are interrupt input terminals, respectively.
  • n is an integer of 0 or more.
  • the suffix “#n” indicates a symbol for the nth CPU.
  • the INT terminal 106 # n indicates that it is an interrupt input terminal included in the CPU # n.
  • the device monitoring apparatus 103_0 and the device monitoring apparatus 103_1 include the dummy register 107_0 and the dummy register 107_1, and can access the device response time DB 108_0 and the device response time DB 108_1.
  • the shared devices 105_0 to 105_3 include a control register 109_0 to a control register 109_3 that control the operation of the shared device 105.
  • the CPUs 101 # 0 to 101 # n are responsible for overall control of the multi-core processor system 100.
  • the multi-core processor system 100 is a multi-core processor system including a plurality of cores.
  • the multi-core processor system 100 may be a single-core processor system having one core.
  • the CPUs 101 # 0 to 101 # n include a cache memory and a register.
  • the device monitoring device 103_0 and the device monitoring device 103_1 are devices that monitor the shared device 105_0 to the shared device 105_3. Further, the device monitoring apparatus 103 sets the priority of the shared device 105 to be monitored, monitors the shared device 105 having a higher priority by one device monitoring apparatus 103 alone, and sets other shared devices 105 as 1 One device monitoring apparatus 103 may monitor all at once.
  • the multi-core processor system 100 is designed not to monitor the shared device 105_3 by the device monitoring apparatus 103.
  • the shared device 105_0 and the shared device 105_1 are defined as the shared device 105 whose control is relatively slow, and the monitoring priority is set to the middle.
  • the multi-core processor system 100 is designed such that the device monitoring apparatus 103_0 collectively monitors the shared device 105_0 and the shared device 105_1.
  • the device monitoring apparatus 103 is connected to the bus 104 and the shared device 105 to be monitored, and has the same number of control lines 110, control lines 112, data lines 111, and data lines 113 as the shared devices 105 to be monitored.
  • the device monitoring apparatus 103_0 includes a control line 110_0 and a data line 111_0 on the bus 104 side, a control line 112_0 and a data line 113_0 on the shared device 105_0 side corresponding to the shared device 105_0 that is the first monitoring target.
  • the device monitoring apparatus 103_0 includes a control line 110_1 and a data line 111_1 on the bus 104 side, a control line 112_1 on the shared device 105_1 side, and a data line 113_1 corresponding to the shared device 105_1 that is the second monitoring target.
  • the function of the device monitoring apparatus 103 will be described later with reference to FIG.
  • Shared device 105_0 and shared device 105_3 are peripheral devices used by CPU 101 # 0 to CPU 101 # 3. Specifically, a communication unit, a camera device, an audio device, a display, a keyboard, and the like.
  • a specific example of the shared device 105_2 that is set to have a high monitoring priority for the device monitoring apparatus 103 includes a communication unit.
  • Specific examples of the shared device 105_0 and the shared device 105_1 in which the monitoring priority for the device monitoring apparatus 103 is set to the middle include a camera device and an audio device.
  • the INT terminals 106 # 0 to 106 # n are interrupt input terminals that receive an interrupt signal from the device monitoring apparatus 103. Although not shown in FIG. 1, the INT terminals 106 # 0 to 106 # n also receive an interrupt signal from the shared device 105 or the like.
  • the dummy registers 107_0 to 107_2 hold information written to the control registers 109_0 to 109_2 by the CPUs 101 # 0 to 101 # n.
  • the dummy register 107_0 holds write information for the control register 109_0.
  • the dummy register 107 may hold write information corresponding to any bit of the control register 109 or may hold write information corresponding to some bits of the control register 109.
  • the device response time DB 108_0 and the device response time DB 108_1 are storage areas for storing the response time when written in the control register 109 of the shared device 105.
  • the entity of the device response time DB 108 — 0 and the device response time DB 108 — 1 may exist in the RAM, ROM, flash ROM connected to the bus 104 described above, or in a storage area that exists in the device monitoring apparatus 103. May be present.
  • the software of the multi-core processor system 100 includes an OS (Operating System) 121 # 0 to OS121 # n, a driver 122 # 0_0 to a driver 122 # n_1, and an application 123_0 to an application 123_5.
  • OS Operating System
  • OS 121 # 0 to OS121 # n are software for controlling CPU 101 # 0 to CPU 101 # n.
  • the OS 121 # 0 includes software such as a scheduler that determines an app to be assigned to the CPU 101 # 0 among the apps 123_0 and 123_1, a dispatcher that assigns the determined app to the CPU 101 # 0, and the like.
  • the OS 121 # 0 to OS121 # n perform exclusive control processing for the shared device 105.
  • the drivers 122 # 0_0 to 122 # n_1 are one of the functions provided by the OS 121 # 0 to OS121 # n, and are software for accessing the shared device 105.
  • the drivers 122 # 0_0 to 122 # n_1 are activated by calls from the applications 123_0 to 123_5, and access the corresponding shared device 105.
  • the driver 122 # 0_0, the driver 122 # 1_0,..., The driver 122 # n_0 is software that accesses the shared device 105_0.
  • the driver 122 # 0_1, the driver 122 # 1_1,..., The driver 122 # n_1 is software that accesses the shared device 105_1.
  • drivers 122 for the shared device 105_2 and the shared device 105_3 are also present in the OS 121 # 0 to OS 121 # n.
  • the CPU 101 # 0 to CPU 101 #n can access the single shared device 105 by calling the respective drivers 122.
  • the multi-core processor system 100 is designed so that access to one shared device 105 does not compete by exclusive control processing.
  • Application 123_0 to application 123_5 are software groups that provide services to users of the multi-core processor system 100.
  • the applications 123_0 to 123_5 are a music playback application, a game application, a camera application, and the like.
  • the applications 123_0 to 123_5 operate the shared devices 105_0 to 105_3 by calling the drivers 122 # 0_0 to 122 # n_1.
  • the app 123_3 is a music playback app and the shared device 105_1 is an audio device.
  • the application 123_0 calls the driver 122 # 1_1, operates the audio device, and realizes music reproduction.
  • FIG. 2 is a block diagram illustrating functions of the device monitoring apparatus 103.
  • the device monitoring apparatus 103 includes a setting unit 201_0, a setting unit 201_1, a time difference detection unit 202, an abnormality detection unit 203, an ACK output unit 204, a device control unit 205, a writing unit 206, and a timer 207.
  • the device monitoring apparatus 103 and the shared device 105 receive a clock input from the outside.
  • the CPU 101 # n detects a write request to the shared device 105_1, and sets the timer 207 to start measuring access time.
  • the setting unit 201_0 and the setting unit 201_1 may stop measuring the access time when a response signal for access is output from the shared device 105.
  • the response signal is an ACK (ACKnowledgement) signal.
  • the setting unit 201_0 detects access to the shared device 105_0
  • the setting unit 201_1 detects access to the shared device 105_1.
  • the set information is stored in a storage area such as a storage area of the device monitoring apparatus 103 or a setting register of the timer 207.
  • the ACK output unit 204 has a function of outputting a dummy ACK signal to the second CPU that has accessed the shared device 105 while the first CPU is accessing the shared device 105.
  • the dummy ACK signal has the same contents as the ACK signal.
  • the ACK output unit 204 outputs a dummy ACK signal to the CPU 101 # 1 that has accessed the shared device 105_1 while the CPU 101 # n is accessing the shared device 105_1.
  • the information that the dummy ACK signal has been output may be stored in the storage area of the device monitoring apparatus 103.
  • Timer 207 has a function of measuring access time. For example, the timer 207 measures the access time by counting an externally input clock from the access start time. The timer 207 starts and stops measurement by the setting unit 201_0 and the setting unit 201_1.
  • the application 123_3 is assumed to be a music playback application
  • the application 123_5 is assumed to be a game application that generates sound
  • the shared device 105_1 is assumed to be an audio device.
  • the application 123_3 performs music data decoding and DA conversion, and writes the conversion result to the control register 109_1 through the driver 122 # 1_1, thereby causing the shared device 105_1 to play music.
  • the application 123_5 causes the shared device 105_1 to reproduce sound by writing the sound data to the control register 109_1 through the driver 122 # n_1.
  • the user is in a state where a sound in which the audio data emitted from the application 123_5 and the music data emitted from the application 123_3 are combined is heard.
  • the device monitoring apparatus 103 when receiving a write request from the driver 122 # 1_1, the device monitoring apparatus 103 during normal operation writes the write target data to the control register 109_1 and also writes the write target data to the corresponding dummy register 107_1. .
  • the setting unit 201_1 sets the start of measuring the access time until a response signal corresponding to the write request by the timer 207 is generated.
  • the setting unit 201_1 sets the stop of access time measurement by the timer 207.
  • FIG. 4 is an explanatory diagram showing an operation before the abnormal state of the multi-core processor system 100 occurs.
  • the application 123_5 is stalled due to a failure.
  • the application 123_5 writes an invalid value to the shared device 105_1 via the driver 122 # n_1.
  • the application 123_5 may stall while acquiring the access right to the shared device 105_1 that is a shared resource of the multi-core processor system 100.
  • the shared device 105_1 does not have a failure, so the watchdog timer 102 cannot detect an abnormal state.
  • the driver 122 # n_1 is locked by the application 123_5.
  • the multi-core processor system 100 prevents such a state where no response signal is returned or access cannot be performed.
  • the setting unit 201_1 sets the measurement start of the timer 207 at the time of writing by the application 123_5.
  • FIG. 5 is an explanatory diagram showing an operation after the abnormal state of the multi-core processor system 100 occurs.
  • the application 123_5 writes the audio data to the audio data FIFO (First In, First Out), and sets a flag indicating completion of data set in the control register 109_1. This is the case.
  • the abnormality detection unit 203 When the time difference detection unit 202 detects that the elapsed time from the write request has exceeded 500 [microseconds], the abnormality detection unit 203 outputs a detection signal indicating an abnormal state to the watchdog timer 102. The abnormality detection unit 203 also notifies the INT terminal 106 of a detection signal indicating the abnormal state of the shared device 105_1. Note that the CPU 101 that has received the detection signal from the INT terminal 106 executes an interrupt handler that detects software that locks the driver 122 # n_1. The software detection request may be broadcasted to the INT terminals 106 # 0 to 106 # n, or may be transmitted only to the INT terminal 106 # 1 for the CPU 101 # 1 that has accessed.
  • the ACK output unit 204 transmits a dummy ACK signal to the CPU 101 # 1 to prevent the application 123_3 from being stopped.
  • the OS 121 detects a timeout without returning an ACK signal and abnormally terminates the application 123_3.
  • the timeout by the OS 121 takes several seconds or the OS 121 stalls without timing out.
  • the abnormal termination of the application 123_3 can be avoided by transmitting a dummy ACK signal.
  • the CPU 101 # n that has received the detection signal from the INT terminal 106 # n executes an interrupt handler that detects software that locks the driver 122 # n_1, and detects the application 123_5. After the detection, the CPU 101 # n forcibly terminates the detected application 123_5.
  • the writing unit 206 writes the data written in the dummy register 107_1 into the control register 109_1.
  • the response times of the shared device 105_0 and the shared device 105_1 are stored as 400 [microseconds] and 500 [microseconds] in the device response time DB 108_0 corresponding to the shared device 105 whose monitoring priority is intermediate, respectively. Has been.
  • the response time of the shared device 105_2 is stored as 10 [milliseconds] in the device response time DB 108_1 corresponding to the shared device 105 having a high monitoring priority.
  • the response time field may be freely changed by the user.
  • the device monitoring apparatus 103 Based on the function of the device monitoring apparatus 103 shown in FIG. 2 and the stored contents of the device response time DB 108 shown in FIG. 7, the device monitoring apparatus 103 performs restoration processing from the abnormal state. 8 and 9, the device monitoring apparatus 103 detects an abnormal state, and then shows a flowchart of the restoration process.
  • the application 123_5 is stalled by a write request to the shared device 105_1 of the application 123_5, and then the application 123_3 makes a write request to the shared device 105_1.
  • the application 123_5 and the driver 122 # n_1 are executed by the CPU 101 # n, and the application 123_3 is executed by the CPU 101 # 1.
  • the application 123_3 calls the driver 122 # 1_1.
  • the process of the driver 122 # 1_1 is the same as the driver 122 # n_1. Quote and explain.
  • FIG. 8 is a flowchart showing processing until an abnormal state of the multi-core processor system 100 is detected.
  • the application 123_5 opens the driver 122 # n_1 (step S801).
  • the opened driver 122 # n_1 acquires the access right to the shared device 105_1 (step S802).
  • the driver 122 # n_1 saves / restores the control register 109_1 (step S803).
  • the application 123_5 calls the driver 122 # n_1 to execute a write request for the control register 109_1 (step S804).
  • the called driver 122 # n_1 makes a write request to the control register 109_1 (step S805).
  • the device monitoring apparatus 103_0 that has received the write request sets the measurement start of the timer 207 by the setting unit 201_1 (step S806). Subsequently, the device monitoring apparatus 103_0 writes data serving as a write request to the dummy register 107_1 and the control register 109_1 (step S807).
  • the application 123_5 determines whether or not an abnormality has been detected (step S808). If an abnormality has occurred (step S808: Yes), the application 123_5 determines whether software recovery is possible (step S809). When software recovery is possible (step S809: Yes), the application 123_5 performs software recovery (step S810). When software recovery is impossible (step S809: No), the application 123_5 enters an abnormal state (step S811), and thereafter, the application 123_5 enters a stalled state.
  • the application 123_3 accesses the shared device 105_1 while the application 123_5 is stalled.
  • the application 123_3 opens the driver 122 # 1_1 (step S812).
  • the driver 122 # 1_1 is executed after the process of step S812, and the process of the driver 122 # 1_1 after the process of step S812 is the same as the processes of step S802 and step S803.
  • the application 123_5 has stalled while having the access right to the shared device 105_1, the application 123_3 cannot acquire the access right to the shared device 105_1. Therefore, the driver 122 # 1_1 cannot complete the saving / restoring of the control register 109_1, which is the process of step S803, and fails.
  • step S813 the application 123_3 calls the driver 122 # 1_1 to execute a write request for the control register 109_1 (step S813).
  • step S813 the driver 122 # 1_1 is executed, and as the process, the same process as the process of step S805 is executed.
  • step S814 The device monitoring apparatus 103_0 that has received a write request to the control register 109_1 from the driver 122 # 1_1 writes to the dummy register 107_1 (step S814). Note that in the process of step S814, the application 123_3 does not have the access right to the shared device 105_1, and thus the write request is not reflected in the control register 109_1.
  • FIG. 9 is a flowchart showing a restoration process from an abnormal state of the multi-core processor system 100.
  • the time difference detection unit 202 detects that the access time measured by the timer 207 exceeds the response time, and detects it as an abnormal state (step S901).
  • the device monitoring apparatus 103_0 causes the ACK output unit 204 to output a dummy ACK signal to the CPU 101 # 1 (step S902).
  • the CPU 101 # 1 normally executes the application 123_3 (step S903).
  • the device monitoring apparatus 103_0 After detecting the abnormal state, the device monitoring apparatus 103_0 outputs a detection signal to the watchdog timer 102 and the INT terminal 106 by the abnormality detection unit 203 (step S904).
  • the CPU 101 # n that has received the detection signal from the INT terminal 106 # n forcibly terminates the application 123_5 (step S905). Further, the driver 122 # n_1 releases the access right to the shared device 105_1 by the warm start of the OS 121 # n that has received the detection signal by the watchdog timer 102 (step S906).
  • the device monitoring apparatus 103_0 prohibits writing to the dummy register 107_1 by the abnormality detection unit 203 (step S907).
  • the device monitoring apparatus 103 instructs the shared device 105_1 to reset by the device control unit 205 (step S908).
  • the device monitoring apparatus 103_0 writes the contents of the dummy register 107_1 into the control register 109_1 by the writing unit 206 (step S909).
  • the device monitoring apparatus 103_0 cancels the prohibition of writing to the dummy register 107 (step S910).
  • the problematic application 123_3 accesses the shared device 105_1. Even if any application does not access the shared device 105_1 after the problematic application 123_5 is stalled, the multi-core processor system 100 can restore the abnormal state. When no app accesses the shared device 105_1, the device monitoring apparatus 103_0 does not perform the processes of step S814, step S902, and step S909.
  • the device monitoring device detects that the shared device is in an abnormal state when a predetermined time elapses without returning a response signal after the access start time by the driver from the CPU. Output a signal.
  • the multi-core processor system can detect a stall that occurs when the driver accesses the shared device.
  • the device monitoring apparatus may refer to a predetermined time from a memory that stores a response time that is a specification of the shared device.
  • the multi-core processor system can detect the abnormal state in accordance with the operation of the shared device having different response times.
  • the multi-core processor system may change the predetermined time according to a user instruction or the like.
  • the device monitoring apparatus stops comparing the predetermined time with the access time from the access start time.
  • the multi-core processor system can be prevented from being detected as an abnormal state when the shared device is operating normally.
  • the device monitoring apparatus may have a storage area for storing data written from the CPU to the shared device, and may prohibit the storage in the storage area when an abnormal state is detected.
  • the multi-core processor system can protect data that has become abnormal and has not been written to the shared device from being overwritten by another CPU or the like.
  • the device monitoring apparatus may hold the data written in the storage area before detecting an abnormal state even after detecting the abnormality.
  • the multi-core processor system can hold data that is in an abnormal state and has not been written to the control register of the shared device.
  • the device monitoring apparatus may write the data held in the storage area to the control register of the shared device after the driver is reset based on the detection signal.
  • the multi-core processor system can be restored from the abnormal state, and data generated by a problem-free application different from the application that has generated the abnormal state can be written to the shared device.
  • the device monitoring apparatus writes data held in the storage area to the shared device, and then from another application executed by another CPU different from the CPU that executed the application that caused the abnormal state. You may accept access to other shared devices.
  • the multi-core processor system can avoid a stall from occurring in a chain without causing another application to stall.
  • the OS detects that there is no response from the application as an abnormal state.
  • the abnormal state can be detected in a short time, which is the response time of the shared device, so that the abnormal state can be detected before the stall chain occurs, and the abnormal state also occurs for the user. The effect is that it is difficult to notice what has been done.
  • the problematic application since the problematic application is forcibly terminated and the other applications execute normally, the user does not have the illusion that the device is faulty. Easy to judge. As a result, if there is a failure report, the device does not have to be recovered, and the developer can respond by redistributing the problematic application. can do.
  • the device monitoring apparatus 103 described in the present embodiment is a PLD (Programmable) such as a standard cell or a specific application IC (hereinafter simply referred to as “ASIC”) such as a structured ASIC (Application Specific Integrated Circuit). It can also be realized by Logic Device. Specifically, for example, the function (setting unit 201 to timer 207) of the device monitoring apparatus 103 described above is function-defined by HDL description, and the HDL description is logically synthesized and given to the ASIC or PLD. 103 can be manufactured.
  • ASIC Application Specific Integrated Circuit

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

　共有デバイス１０５へのアクセスによって発生するアプリのストールを検出する。デバイス監視装置（１０３＿０）は、設定部（２０１＿０）、設定部（２０１＿１）によって、第１ＣＰＵによる共有デバイス（１０５＿１）へのアクセスに基づいて、タイマー（２０７）に対しアクセス時間の計測開始を設定する。タイマー（２０７）による計測開始後、デバイス監視装置（１０３＿０）は、アクセス時間が共有デバイス応答時間ＤＢ（１０８＿０）に格納されている所定時間を超えることを検出する。アクセス時間が所定時間を超えたことを検出後、デバイス監視装置（１０３＿０）は、異常検出部（２０３）によって、検出信号を出力する。

Description

アクセス方法、およびマルチコアプロセッサシステム
　本発明は、監視対象となるデバイスにアクセスするアクセス方法、およびマルチコアプロセッサシステムに関する。
　従来から、情報処理装置内外に接続されたデバイスを監視する装置として、ウォッチドッグタイマーや、ダイアグノーシス装置といった装置が存在する。これらの装置を利用し、周期的に各デバイスを点検し、デバイスの異常を検出する技術も存在する。また、バックアップシステムをメインシステムとは別に管理しておき、メインシステム内のデバイスの異常を検出した場合に、メインシステムとバックアップシステムを切り替える技術が存在する。
　また、異常が発生した際の技術として、複数のコアを含むマルチコアプロセッサシステムの入出力装置の付加装置を設け、起動ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）番号を記録するという技術が開示されている（たとえば、下記特許文献１を参照。）。また、異常発生後の復元の技術として、ＣＰＵの補助を行うコプロセッサ制御において、ハングアップを検出し、ハングアップしたコプロセッサをリセットするという技術が開示されている（たとえば、下記特許文献２を参照。）。
　また、デバイス間の応答時間を短縮させる技術として、複数ＣＰＵと、複数Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）共有システムにおいて制御装置を設け、起動Ｉ／Ｏが動作中であれば制御信号を記憶し、動作完了後、ダミーＩ／Ｏを送信するという技術が開示されている（たとえば、下記特許文献３を参照。）。
特開昭５５－１０８０２６号公報 特表２００７－５０７０３４号公報 特開平６－２０８５３６号公報
　上述した従来技術において、特許文献１、特許文献２にかかる技術では、ハードウェアの障害による異常を対象としていた。しかしながら、ソフトウェアによるデバイスへのアクセスにより発生する障害については、特許文献１、特許文献２にかかる技術では正常と判断されてしまい、異常状態を見落としてしまうという問題があった。
　また、異常状態を見落としてしまうと、マルチコアプロセッサシステムの場合、問題のあるアプリケーションソフトウェア（以下、アプリ）が共有デバイスへのアクセス権を取得したままストールし、他のアプリが共有デバイスへのアクセス権を取得できない状態が発生する。結果、アクセス権を取得できなかった他のアプリもストールするという、ストールが連鎖的に発生するという問題があった。また、ストールが連鎖的に発生した場合、ストールしたアプリのうち、何れのアプリが問題のあるソフトウェアであるのかを切り分けなければならないという問題があった。
　本発明は、上述した従来技術による問題点を解消するため、共有デバイスへのアクセスによって発生するアプリのストールを検出できるアクセス方法、およびマルチコアプロセッサシステムを提供することを目的とする。
　上述した課題を解決し、目的を達成するため、開示のアクセス方法は、第１アプリケーションの実行開始に基づいて第１ＣＰＵに対応するドライバを活性化し、周辺デバイスへのアクセスに基づいてアクセス時間の計測を開始し、アクセス時間が所定時間を超える場合にはドライバをリセットするための検出信号を出力するとともに、第１ＣＰＵから周辺デバイスに書き込まれるデータを保持するレジスタへの書き込みを禁止する。
　本アクセス方法、およびマルチコアプロセッサシステムによれば、共有デバイスへのアクセスによって発生するアプリのストールを検出できるという効果を奏する。
実施の形態にかかるマルチコアプロセッサシステム１００のハードウェアとソフトウェアを示すブロック図である。 デバイス監視装置１０３の機能を示すブロック図である。 マルチコアプロセッサシステム１００の通常運用時の動作を示す説明図である。 マルチコアプロセッサシステム１００の異常状態が発生する前の動作を示す説明図である。 マルチコアプロセッサシステム１００の異常状態が発生した後の動作を示す説明図である。 マルチコアプロセッサシステム１００の異常状態からの復元動作を示す説明図である。 デバイス応答時間ＤＢ１０８の記憶内容の一例を示す説明図である。 マルチコアプロセッサシステム１００の異常状態を検出するまでの処理を示すフローチャートである。 マルチコアプロセッサシステム１００の異常状態からの復元処理を示すフローチャートである。
　以下に添付図面を参照して、開示のアクセス方法、およびマルチコアプロセッサシステムの好適な実施の形態を詳細に説明する。
（マルチコアプロセッサシステム１００のハードウェアおよびソフトウェア）
　図１は、実施の形態にかかるマルチコアプロセッサシステム１００のハードウェアとソフトウェアを示すブロック図である。図１において、マルチコアプロセッサシステム１００は、ＣＰＵ１０１＃０～ＣＰＵ１０１＃ｎと、ウォッチドッグタイマー１０２と、デバイス監視装置１０３＿０、デバイス監視装置１０３＿１と、を含む。各部は、バス１０４によってそれぞれ接続されている。本実施の形態にかかるマルチコアプロセッサシステム１００は、携帯電話等といった、小型の端末装置を想定している。また、図１に図示していないが、バス１０４には、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ　Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、フラッシュＲＯＭといった、記憶装置が接続されている。
　また、マルチコアプロセッサシステム１００は、共有デバイス１０５＿０～共有デバイス１０５＿３を含む。共有デバイス１０５＿０、共有デバイス１０５＿１は、デバイス監視装置１０３＿０を経由してバス１０４と接続しており、共有デバイス１０５＿２は、デバイス監視装置１０３＿１を経由してバス１０４と接続している。共有デバイス１０５＿３は、直接バス１０４と接続している。
　また、ＣＰＵ１０１＃０～ＣＰＵ１０１＃ｎは、それぞれ、割込入力端子であるＩＮＴ（ＩＮＴｅｒｒｕｐｔ）端子１０６＃０～ＩＮＴ端子１０６＃ｎを含む。ここで、ｎは０以上の整数である。なお、接尾記号“＃ｎ”は、ｎ番目のＣＰＵに対する記号であることを示している。たとえば、ＩＮＴ端子１０６＃ｎは、ＣＰＵ＃ｎに含まれる割込入力端子であることを示している。
　続けて、デバイス監視装置１０３＿０、デバイス監視装置１０３＿１は、ダミーレジスタ１０７＿０、ダミーレジスタ１０７＿１を含み、デバイス応答時間ＤＢ１０８＿０、デバイス応答時間ＤＢ１０８＿１にアクセス可能である。また、共有デバイス１０５＿０～共有デバイス１０５＿３は、共有デバイス１０５の動作を制御する制御レジスタ１０９＿０～制御レジスタ１０９＿３を含む。
　ＣＰＵ１０１＃０～ＣＰＵ１０１＃ｎは、マルチコアプロセッサシステム１００の全体の制御を司る。ここで、マルチコアプロセッサシステム１００は、複数のコアを含むマルチコアプロセッサシステムとなる。また、マルチコアプロセッサシステム１００は、コアが１つであるシングルコアプロセッサシステムであってもよい。また、ＣＰＵ１０１＃０～ＣＰＵ１０１＃ｎは、キャッシュメモリやレジスタを含む。
　ウォッチドッグタイマー１０２は、ＣＰＵ１０１＃０～ＣＰＵ１０１＃ｎ、共有デバイス１０５＿０～共有デバイス１０５＿３などが停止していないかを監視する診断回路である。たとえば、ウォッチドッグタイマー１０２は、ＣＰＵ１０１、共有デバイス１０５等が、過電圧を受けて停止した際に、ＣＰＵ１０１、共有デバイス１０５等の異常を検出する。また、ウォッチドッグタイマー１０２は、デバイス監視装置１０３から、共有デバイス１０５の異常状態の通知を受ける。
　デバイス監視装置１０３＿０、デバイス監視装置１０３＿１は、共有デバイス１０５＿０～共有デバイス１０５＿３を監視する装置である。また、デバイス監視装置１０３は、監視対象となる共有デバイス１０５の優先度を設定し、優先度が高い共有デバイス１０５を１つのデバイス監視装置１０３単独で監視し、他の共有デバイス１０５群を、１つのデバイス監視装置１０３が一括して監視してもよい。
　具体的には、共有デバイス１０５＿２は、停止状態が好ましくないため、監視の優先度が高い。したがって、マルチコアプロセッサシステム１００は、共有デバイス１０５＿２に対してデバイス監視装置１０３＿１単独による監視を行うように設計されている。また、共有デバイス１０５＿３は、停止状態であってもマルチコアプロセッサシステム１００の動作に影響しなく、監視の優先度が低い。
　したがって、マルチコアプロセッサシステム１００は、共有デバイス１０５＿３に対してデバイス監視装置１０３による監視を行わないように設計されている。共有デバイス１０５＿０、共有デバイス１０５＿１は、比較的制御が緩慢な共有デバイス１０５として定義されており、監視の優先度が中間に設定されている。マルチコアプロセッサシステム１００は、共有デバイス１０５＿０、共有デバイス１０５＿１に対してデバイス監視装置１０３＿０が一括して監視を行うように設計されている。
　また、デバイス監視装置１０３は、バス１０４、監視対象の共有デバイス１０５と接続されており、監視対象の共有デバイス１０５と等しい数分となる制御線１１０、制御線１１２、データ線１１１、データ線１１３を有する。
　たとえば、デバイス監視装置１０３＿０は、１つ目の監視対象である共有デバイス１０５＿０に対応する、バス１０４側の制御線１１０＿０、データ線１１１＿０と、共有デバイス１０５＿０側の制御線１１２＿０、データ線１１３＿０を有する。さらに、デバイス監視装置１０３＿０は、２つ目の監視対象である共有デバイス１０５＿１に対応する、バス１０４側の制御線１１０＿１、データ線１１１＿１と、共有デバイス１０５＿１側の制御線１１２＿１、データ線１１３＿１を有する。なお、デバイス監視装置１０３の機能については、図２にて後述する。
　共有デバイス１０５＿０、共有デバイス１０５＿３は、ＣＰＵ１０１＃０～ＣＰＵ１０１＃３から利用される周辺デバイスである。具体的には、通信ユニット、カメラデバイス、オーディオデバイス、ディスプレイ、キーボード等である。また、デバイス監視装置１０３に対する監視の優先度が高く設定されている共有デバイス１０５＿２の具体例としては、通信ユニット等が挙げられる。デバイス監視装置１０３に対する監視の優先度が中間に設定されている共有デバイス１０５＿０、共有デバイス１０５＿１の具体例としては、カメラデバイス、オーディオデバイス等が挙げられる。
　ＩＮＴ端子１０６＃０～ＩＮＴ端子１０６＃ｎは、デバイス監視装置１０３からの割込信号を受信する割込入力端子である。また、図１にて図示していないが、ＩＮＴ端子１０６＃０～ＩＮＴ端子１０６＃ｎは、共有デバイス１０５等からも割込信号を受信する。
　ダミーレジスタ１０７＿０～ダミーレジスタ１０７＿２は、ＣＰＵ１０１＃０～ＣＰＵ１０１＃ｎによる制御レジスタ１０９＿０～制御レジスタ１０９＿２に対する書き込み情報を保持する。たとえば、ダミーレジスタ１０７＿０は、制御レジスタ１０９＿０に対する書き込み情報を保持する。なお、ダミーレジスタ１０７は、制御レジスタ１０９の何れのビットに対応する書き込み情報を保持してもよいし、制御レジスタ１０９の一部のビットに対応する書き込み情報を保持してもよい。
　なお、共有デバイス１０５には、制御レジスタ１０９以外の他のレジスタが存在し、他のレジスタもダミーレジスタ１０７の保持対象としてもよい。他のレジスタとはたとえば、共有デバイス１０５の動作状況が格納されているステータスレジスタ等である。
　デバイス応答時間ＤＢ１０８＿０、デバイス応答時間ＤＢ１０８＿１は、共有デバイス１０５の制御レジスタ１０９に書き込まれた際の応答時間を記憶する記憶領域である。なお、デバイス応答時間ＤＢ１０８＿０、デバイス応答時間ＤＢ１０８＿１の実体は、前述したバス１０４に接続されたＲＡＭ、ＲＯＭ、フラッシュＲＯＭに存在してもよいし、または、デバイス監視装置１０３内に存在する記憶領域に存在してもよい。
　続いて、マルチコアプロセッサシステム１００のソフトウェアとしては、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）１２１＃０～ＯＳ１２１＃ｎ、ドライバ１２２＃０＿０～ドライバ１２２＃ｎ＿１、アプリ１２３＿０～アプリ１２３＿５を含む。
　ＯＳ１２１＃０～ＯＳ１２１＃ｎは、ＣＰＵ１０１＃０～ＣＰＵ１０１＃ｎを制御するソフトウェアである。たとえば、ＯＳ１２１＃０には、アプリ１２３＿０、アプリ１２３＿１のうち、ＣＰＵ１０１＃０に割り当てるアプリを決定するスケジューラや、決定されたアプリをＣＰＵ１０１＃０に割り当てるディスパッチャ等といったソフトウェアが含まれる。また、ＯＳ１２１＃０～ＯＳ１２１＃ｎは、共有デバイス１０５に対する排他制御処理を行う。
　ドライバ１２２＃０＿０～ドライバ１２２＃ｎ＿１は、ＯＳ１２１＃０～ＯＳ１２１＃ｎの提供する機能の一つであり、共有デバイス１０５にアクセスするソフトウェアである。ドライバ１２２＃０＿０～ドライバ１２２＃ｎ＿１は、アプリ１２３＿０～アプリ１２３＿５からの呼び出しによって活性化し、対応する共有デバイス１０５にアクセスする。
　なお、図１では、ドライバ１２２＃０＿０、ドライバ１２２＃１＿０、…、ドライバ１２２＃ｎ＿０が共有デバイス１０５＿０にアクセスするソフトウェアである。同様に、ドライバ１２２＃０＿１、ドライバ１２２＃１＿１、…、ドライバ１２２＃ｎ＿１が共有デバイス１０５＿１にアクセスするソフトウェアである。また図１に図示していないが、共有デバイス１０５＿２、共有デバイス１０５＿３に対するドライバ１２２も、ＯＳ１２１＃０～ＯＳ１２１＃ｎ内に存在する。
　このように、ＣＰＵ１０１＃０～ＣＰＵ１０１＃ｎがそれぞれのドライバ１２２を呼び出すことで、１つの共有デバイス１０５に対してアクセスできる。同時のアクセスによる不具合を発生させないため、マルチコアプロセッサシステム１００は、排他制御処理によって、１つの共有デバイス１０５に対してアクセスが競合しないように設計されている。
　アプリ１２３＿０～アプリ１２３＿５は、マルチコアプロセッサシステム１００のユーザにサービスを提供するソフトウェア群である。具体的に、アプリ１２３＿０～アプリ１２３＿５は、音楽再生アプリ、ゲームアプリ、カメラアプリ等である。アプリ１２３＿０～アプリ１２３＿５は、ドライバ１２２＃０＿０～ドライバ１２２＃ｎ＿１を呼び出すことにより、共有デバイス１０５＿０～共有デバイス１０５＿３を操作する。たとえば、アプリ１２３＿３が音楽再生アプリ、共有デバイス１０５＿１がオーディオデバイスであると想定する。このとき、アプリ１２３＿０は、ドライバ１２２＃１＿１を呼び出して、オーディオデバイスを操作し、音楽再生を実現する。
　図２は、デバイス監視装置１０３の機能を示すブロック図である。デバイス監視装置１０３は、設定部２０１＿０、設定部２０１＿１、時差検出部２０２、異常検出部２０３、ＡＣＫ出力部２０４、デバイス制御部２０５、書込部２０６、タイマー２０７を含む。また、デバイス監視装置１０３、共有デバイス１０５は、外部からクロック入力を受けている。
　設定部２０１＿０、設定部２０１＿１は、ＣＰＵ１０１＃０～ＣＰＵ１０１＃ｎのうち、第１ＣＰＵによる共有デバイス１０５へのアクセスに基づいて、タイマー２０７に対しアクセス時間の計測開始を設定する機能を有する。アクセス時間とは、共有デバイス１０５へのアクセス時刻を開始時刻とし、共有デバイス１０５からのアクセスに対する応答信号が発生した時刻を終了時刻とした時間である。
　たとえば、設定部２０１＿１は、ＣＰＵ１０１＃ｎが共有デバイス１０５＿１に対する書き込み要求を検出し、タイマー２０７に対しアクセス時間の計測開始を設定する。また、設定部２０１＿０、設定部２０１＿１は、共有デバイス１０５から、アクセスに対する応答信号が出力された場合、アクセス時間の計測を停止してもよい。また、応答信号とは、ＡＣＫ（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ）信号である。なお、設定部２０１＿０は、共有デバイス１０５＿０に対するアクセスを検出し、設定部２０１＿１は、共有デバイス１０５＿１に対するアクセスを検出する。なお、設定された情報は、デバイス監視装置１０３の記憶領域、タイマー２０７の設定レジスタ、などの記憶領域に記憶される。
　時差検出部２０２は、アクセス時間が所定時間を超えることを検出する機能を有する。なお、所定時間とは、共有デバイス１０５の仕様となる応答時間であり、デバイス応答時間ＤＢ１０８に格納されている。たとえば、時差検出部２０２は、共有デバイス１０５＿１に対する書き込み要求の時刻を開始時刻とするアクセス時間が共有デバイス１０５＿１の応答時間５００［マイクロ秒］を超えたことを検出する。なお、検出結果は、デバイス監視装置１０３の記憶領域に記憶される。
　異常検出部２０３は、時差検出部２０２によってアクセス時間が所定時間を超えたことが検出された場合、検出信号を出力する機能を有する。検出信号としては、ウォッチドッグタイマー１０２に対して異常状態を示す検出信号と、ＩＮＴ端子１０６に対して異常状態を示す検出信号とがある。たとえば、異常検出部２０３は、共有デバイス１０５＿１の仕様となる応答時間５００［マイクロ秒］を超えた場合に、ウォッチドッグタイマー１０２とＩＮＴ端子１０６に対して検出信号を出力する。
　ＡＣＫ出力部２０４は、第１のＣＰＵが共有デバイス１０５にアクセス中に、共有デバイス１０５にアクセスしてきた第２のＣＰＵに対し、ダミーＡＣＫ信号を出力する機能を有する。ダミーＡＣＫ信号は、ＡＣＫ信号と同内容の信号である。たとえば、ＡＣＫ出力部２０４は、ＣＰＵ１０１＃ｎが共有デバイス１０５＿１にアクセス中に、共有デバイス１０５＿１にアクセスしてきたＣＰＵ１０１＃１に対し、ダミーＡＣＫ信号を出力する。なお、ダミーＡＣＫ信号を出力したという情報は、デバイス監視装置１０３の記憶領域に記憶されてもよい。
　デバイス制御部２０５は、第１のＣＰＵに対するアクセスの応答信号がない共有デバイス１０５に対し、リセットの指示を行う機能を有する。たとえば、デバイス制御部２０５は、ＣＰＵ１０１＃ｎに対するアクセスの応答信号がない共有デバイス１０５＿１に対し、リセットの指示を行う。なお、リセットの指示が行われたという情報は、デバイス監視装置１０３の記憶領域に記憶される。
　書込部２０６は、デバイス制御部２０５によって共有デバイス１０５がリセット完了した後、ダミーレジスタ１０７の内容を制御レジスタ１０９に書き込む機能を有する。たとえば、書込部２０６は、共有デバイス１０５＿１がリセット完了した後に、ダミーレジスタ１０７＿１の内容を制御レジスタ１０９＿１に書き込む。なお、書き込んだという情報は、デバイス監視装置１０３の記憶領域に記憶されてもよい。
　タイマー２０７は、アクセス時間を計測する機能を有する。たとえば、タイマー２０７は、アクセス開始時刻から、外部から入力されたクロックを計数することで、アクセス時間を計測する。また、タイマー２０７は、設定部２０１＿０、設定部２０１＿１によって計測開始、計測停止する。
　以下、デバイス監視装置１０３の機能を用いて、図３～図６にて、マルチコアプロセッサシステム１００が通常運用状態から、異常状態となり、さらに異常状態からの復元動作までの一連の動作について説明を行う。また、図３～図６では、アプリ１２３＿３を音楽再生アプリと想定し、アプリ１２３＿５を音声が発生するゲームアプリと想定し、共有デバイス１０５＿１をオーディオデバイスと想定する。
　図３は、マルチコアプロセッサシステム１００の通常運用時の動作を示す説明図である。通常運用時におけるマルチコアプロセッサシステム１００は、ＯＳ１２１＃０～ＯＳ１２１＃ｎがドライバ１２２＃０＿０～ドライバ１２２＃ｎ＿１を調停、切り替えながら動作している。
　具体的には、アプリ１２３＿３は、音楽データのデコードおよびＤＡ変換を行い、変換結果をドライバ１２２＃１＿１を通じて制御レジスタ１０９＿１に書き込むことにより、共有デバイス１０５＿１に音楽を再生させている。また、アプリ１２３＿５は、音声データをドライバ１２２＃ｎ＿１を通じて制御レジスタ１０９＿１に書き込むことにより、共有デバイス１０５＿１に音声を再生させている。ユーザには、アプリ１２３＿５から発せられる音声データと、アプリ１２３＿３から発せられる音楽データとが合わさった音が聞こえている状態である。
　通常運用時におけるデバイス監視装置１０３は、たとえば、ドライバ１２２＃１＿１からの書き込み要求を受けると、制御レジスタ１０９＿１に、書き込み対象のデータを書き込むとともに、対応するダミーレジスタ１０７＿１にも書き込み対象のデータを書き込む。書き込み要求を受けると、設定部２０１＿１は、タイマー２０７による書き込み要求に対応する応答信号が発生するまでのアクセス時間の計測開始を設定する。
　図３で示すマルチコアプロセッサシステム１００は通常運用時であるため、共有デバイス１０５＿１は、仕様である応答時間＝５００［マイクロ秒］以内に書き込み要求に対応する応答信号をＣＰＵ１０１＃１に送信する。応答信号となるＡＣＫ信号が共有デバイス１０５＿１から発生すると、設定部２０１＿１は、タイマー２０７によるアクセス時間の計測停止を設定する。
　図４は、マルチコアプロセッサシステム１００の異常状態が発生する前の動作を示す説明図である。図４で示すマルチコアプロセッサシステム１００では、アプリ１２３＿５が障害によりストールした状態を示している。障害の内容として、たとえば、アプリ１２３＿５が不正な値をドライバ１２２＃ｎ＿１を経由して共有デバイス１０５＿１に書き込んだ場合である。
　このとき、アプリ１２３＿５が、マルチコアプロセッサシステム１００の共有資源である、共有デバイス１０５＿１へのアクセス権を取得したままストールしてしまうことがある。なお、図４の状態では、共有デバイス１０５＿１が故障しているわけではないため、ウォッチドッグタイマー１０２では、異常状態を検出することができない。また、ドライバ１２２＃ｎ＿１は、アプリ１２３＿５によってロックされた状態である。
　もし、マルチコアプロセッサシステム１００がシングルコアプロセッサシステムであれば、アプリ１２３＿５のストールとともに、ＯＳ１２１がストールすることになる。コアが複数存在するマルチコアプロセッサシステム１００は、ＣＰＵ１０１ごとに独立したＯＳを動作させることにより、ストールの影響を最小限に食い止めることが可能である。しかし、ＣＰＵ１０１＃１上のアプリ１２３＿３が共有デバイス１０５＿１にアクセスを行おうとした場合、応答信号が返らない状態、または、アクセスが行えない状態となる。
　本実施の形態にかかるマルチコアプロセッサシステム１００は、このような、応答信号が返らない状態、または、アクセスが行えない状態を防ぐ。初めに、設定部２０１＿１は、アプリ１２３＿５による書き込み時に、タイマー２０７の計測開始を設定する。
　図５は、マルチコアプロセッサシステム１００の異常状態が発生した後の動作を示す説明図である。図５で示すマルチコアプロセッサシステム１００は、図４にて計測開始したタイマー２０７の経過時間が、デバイス応答時間ＤＢ１０８で設定されている応答時間＝５００［マイクロ秒］を超えた場合を示している。具体的には、マルチコアプロセッサシステム１００が図４で示す状態にて、アプリ１２３＿５が、音声データＦＩＦＯ（Ｆｉｒｓｔ　Ｉｎ、Ｆｉｒｓｔ　Ｏｕｔ）に音声データを書き込み、制御レジスタ１０９＿１にデータセット完了を意味するフラグを設定した場合である。このとき、共有デバイス１０５＿１の仕様として、共有デバイス１０５＿１は、フラグ設定から５００［マイクロ秒］にて受信完了を示すＡＣＫ信号を発行すると定められている場合を想定している。
　書き込み要求からの経過時間が５００［マイクロ秒］を超えたことが時差検出部２０２によって検出された場合、異常検出部２０３は、ウォッチドッグタイマー１０２に対して異常状態を示す検出信号を出力する。また、異常検出部２０３は、ＩＮＴ端子１０６に対しても、共有デバイス１０５＿１の異常状態を示す検出信号を通知する。なお、ＩＮＴ端子１０６から検出信号を受信したＣＰＵ１０１は、ドライバ１２２＃ｎ＿１をロックしているソフトウェアを検出する割込ハンドラを実行する。なお、ソフトウェアの検出要求は、ＩＮＴ端子１０６＃０～ＩＮＴ端子１０６＃ｎにブロードキャスト送信してもよいし、アクセスを行ったＣＰＵ１０１＃１に対するＩＮＴ端子１０６＃１のみに送信してもよい。
　また、ＣＰＵ１０１＃１に応答信号が返らない状態である場合、ＡＣＫ出力部２０４が、ダミーＡＣＫ信号をＣＰＵ１０１＃１に送信し、アプリ１２３＿３の停止を防ぐ。従来例にかかるマルチコアプロセッサシステム１００では、ＡＣＫ信号が返らずにＯＳ１２１がタイムアウトを検出し、アプリ１２３＿３を異常終了するという対応が取られていた。しかし、ＯＳ１２１によるタイムアウトが数秒かかる場合や、または、ＯＳ１２１がタイムアウトせずに、ストールする場合も存在していた。本実施の形態にかかるマルチコアプロセッサシステム１００では、ダミーＡＣＫ信号を送信することで、アプリ１２３＿３の異常終了を避けることができる。
　図６は、マルチコアプロセッサシステム１００の異常状態からの復元動作を示す説明図である。図６で示すマルチコアプロセッサシステム１００は、図５にて異常検出部２０３、ＡＣＫ出力部２０４が動作した後である。図５にて異常状態の通知を受けたウォッチドッグタイマー１０２が、ＣＰＵ１０１＃ｎのウォームスタート要求を通知する。ウォームスタート要求を受信したＣＰＵ１０１＃ｎはソフトリセットが行われる。また、ドライバ１２２＃ｎ＿１は、ロックが解除され、共有デバイス１０５＿１へのアクセス権を解放する。
　また、ＩＮＴ端子１０６＃ｎから検出信号を受信したＣＰＵ１０１＃ｎは、ドライバ１２２＃ｎ＿１をロックしているソフトウェアを検出する割込ハンドラを実行し、アプリ１２３＿５を検出する。検出後、ＣＰＵ１０１＃ｎは、検出されたアプリ１２３＿５を強制終了させる。
　また、デバイス制御部２０５が共有デバイス１０５＿１に対して、リセットを行った後に、書込部２０６がダミーレジスタ１０７＿１に書き込まれていたデータを制御レジスタ１０９＿１に書き込む。以上の動作により、マルチコアプロセッサシステム１００は、異常状態から復旧することになる。問題のあったアプリ１２３＿５が強制終了し、アプリ１２３＿３については正常に処理を続行することができる。
　図７は、デバイス応答時間ＤＢ１０８の記憶内容の一例を示す説明図である。デバイス応答時間ＤＢ１０８は、デバイス名、応答時間という２つのフィールドを含む。デバイス名フィールドには、共有デバイス１０５の名称が格納される。また、共有デバイス１０５が一意に特定できるＩＤ（ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）であってもよい。応答時間フィールドには、共有デバイス１０５の応答時間が格納される。
　たとえば、監視の優先度が中間の共有デバイス１０５に対応するデバイス応答時間ＤＢ１０８＿０には、共有デバイス１０５＿０、共有デバイス１０５＿１の応答時間が、それぞれ、４００［マイクロ秒］、５００［マイクロ秒］、と格納されている。また、監視の優先度が高い共有デバイス１０５に対応するデバイス応答時間ＤＢ１０８＿１には、共有デバイス１０５＿２の応答時間が、１０［ミリ秒］と格納されている。また、応答時間フィールドに関しては、ユーザによって自由に変更されてもよい。
　図２で示したデバイス監視装置１０３の機能、および図７で示したデバイス応答時間ＤＢ１０８の記憶内容に基づいて、デバイス監視装置１０３は、異常状態からの復元処理を行う。図８、図９にて、デバイス監視装置１０３は、異常状態を検出し、続けて復元処理のフローチャートを示す。
　また、図８、図９で示すフローチャートでは、アプリ１２３＿５の共有デバイス１０５＿１に対する書き込み要求によって、アプリ１２３＿５がストールし、その後、アプリ１２３＿３が共有デバイス１０５＿１に対して書き込み要求を行うことを想定する。また、アプリ１２３＿５、ドライバ１２２＃ｎ＿１は、ＣＰＵ１０１＃ｎによって実行され、アプリ１２３＿３は、ＣＰＵ１０１＃１によって実行される。なお、アプリ１２３＿３は、ドライバ１２２＃１＿１を呼び出すが、図８、図９では、ドライバ１２２＃１＿１の処理については、ドライバ１２２＃ｎ＿１と等しいため、図示せず、ドライバ１２２＃ｎ＿１の処理番号を引用して説明する。
　図８は、マルチコアプロセッサシステム１００の異常状態を検出するまでの処理を示すフローチャートである。アプリ１２３＿５は、ドライバ１２２＃ｎ＿１をオープンする（ステップＳ８０１）。オープンされたドライバ１２２＃ｎ＿１は、共有デバイス１０５＿１に対するアクセス権を取得する（ステップＳ８０２）。続けて、ドライバ１２２＃ｎ＿１は、制御レジスタ１０９＿１の退避・復元を行う（ステップＳ８０３）。
　制御レジスタ１０９＿１の退避・復元が行われた後、アプリ１２３＿５は、ドライバ１２２＃ｎ＿１を呼び出して、制御レジスタ１０９＿１の書き込み要求を実行する（ステップＳ８０４）。呼び出されたドライバ１２２＃ｎ＿１は、制御レジスタ１０９＿１に書き込み要求を行う（ステップＳ８０５）。
　書き込み要求を受信したデバイス監視装置１０３＿０は、設定部２０１＿１によって、タイマー２０７の計測開始を設定する（ステップＳ８０６）。続けて、デバイス監視装置１０３＿０は、ダミーレジスタ１０７＿１と制御レジスタ１０９＿１に書き込み要求となるデータを書き込む（ステップＳ８０７）。
　書き込み要求後、アプリ１２３＿５は、異常発生を検出したかを判断する（ステップＳ８０８）。異常が発生した場合（ステップＳ８０８：Ｙｅｓ）、アプリ１２３＿５は、ソフトウェアリカバリ可能か否かを判断する（ステップＳ８０９）。ソフトウェアリカバリ可能である場合（ステップＳ８０９：Ｙｅｓ）、アプリ１２３＿５は、ソフトウェアリカバリを実行する（ステップＳ８１０）。ソフトウェアリカバリ不可能である場合（ステップＳ８０９：Ｎｏ）、アプリ１２３＿５は、異常状態となり（ステップＳ８１１）、以後、アプリ１２３＿５はストールした状態となる。
　異常発生を検出していない場合（ステップＳ８０８：Ｎｏ）、アプリ１２３＿５は、ステップＳ８０４の処理に移行する。なお、ステップＳ８０８：Ｎｏとなった場合、共有デバイス１０５＿１よりＡＣＫ信号が送られるため、ステップＳ８０６で設定されたタイマー２０７の計測が停止する。ステップＳ８１０実行後も、アプリ１２３＿５は、ステップＳ８０４の処理に移行する。
　続けて、アプリ１２３＿５がストール中にアプリ１２３＿３による共有デバイス１０５＿１へのアクセスが行われる場合を想定する。アプリ１２３＿３は、ドライバ１２２＃１＿１をオープンする（ステップＳ８１２）。ステップＳ８１２の処理後、ドライバ１２２＃１＿１が実行されるが、ステップＳ８１２の処理後のドライバ１２２＃１＿１の処理は、ステップＳ８０２、ステップＳ８０３の処理と等しい。しかしながら、アプリ１２３＿５が共有デバイス１０５＿１に対するアクセス権を有したままストールしたために、アプリ１２３＿３は、共有デバイス１０５＿１に対するアクセス権を取得できない。したがって、ドライバ１２２＃１＿１は、ステップＳ８０３の処理である、制御レジスタ１０９＿１の退避・復元を完了できず、失敗することになる。
　続けて、アプリ１２３＿３は、ドライバ１２２＃１＿１を呼び出して、制御レジスタ１０９＿１の書き込み要求を実行する（ステップＳ８１３）。ステップＳ８１３の処理後、ドライバ１２２＃１＿１が実行され、処理としては、ステップＳ８０５の処理と同内容の処理が実行される。
　ドライバ１２２＃１＿１より制御レジスタ１０９＿１への書き込み要求を受けたデバイス監視装置１０３＿０は、ダミーレジスタ１０７＿１に書き込む（ステップＳ８１４）。なお、ステップＳ８１４の処理にて、アプリ１２３＿３は共有デバイス１０５＿１に対するアクセス権を有していないため、制御レジスタ１０９＿１に書き込み要求が反映されない。
　図９は、マルチコアプロセッサシステム１００の異常状態からの復元処理を示すフローチャートである。デバイス監視装置１０３＿０は、時差検出部２０２によって、タイマー２０７の計測によるアクセス時間が応答時間を超えたことを検出し、異常状態として検出する（ステップＳ９０１）。異常状態を検出後、デバイス監視装置１０３＿０は、ＡＣＫ出力部２０４によって、ダミーＡＣＫ信号をＣＰＵ１０１＃１に出力する（ステップＳ９０２）。ダミーＡＣＫ信号を受けたＣＰＵ１０１＃１は、アプリ１２３＿３を正常実行する（ステップＳ９０３）。
　また、異常状態を検出後、デバイス監視装置１０３＿０は、異常検出部２０３によって、検出信号をウォッチドッグタイマー１０２とＩＮＴ端子１０６に出力する（ステップＳ９０４）。
　ＩＮＴ端子１０６＃ｎより、検出信号を受信したＣＰＵ１０１＃ｎが、アプリ１２３＿５を強制終了する（ステップＳ９０５）。また、ドライバ１２２＃ｎ＿１は、ウォッチドッグタイマー１０２によって検出信号を受信したＯＳ１２１＃ｎのウォームスタートにより、共有デバイス１０５＿１に対するアクセス権を解放する（ステップＳ９０６）。
　続けて、デバイス監視装置１０３＿０は、異常検出部２０３によって、ダミーレジスタ１０７＿１に対する書き込みを禁止する（ステップＳ９０７）。書き込み禁止後、デバイス監視装置１０３は、デバイス制御部２０５によって、共有デバイス１０５＿１に対してリセットの指示を行う（ステップＳ９０８）。共有デバイス１０５＿１のリセット完了後、デバイス監視装置１０３＿０は、書込部２０６によって、ダミーレジスタ１０７＿１の内容を、制御レジスタ１０９＿１に書き込む（ステップＳ９０９）。書き込み後、デバイス監視装置１０３＿０は、ダミーレジスタ１０７に対する書き込み禁止を解除する（ステップＳ９１０）。
　なお、図８、図９に示したフローチャートでは、問題のあるアプリ１２３＿５がストールした後、問題のないアプリ１２３＿３が共有デバイス１０５＿１にアクセスしている。もし、問題のあるアプリ１２３＿５がストールした後に、何れのアプリも共有デバイス１０５＿１にアクセスしない場合でも、マルチコアプロセッサシステム１００は、異常状態を復元することができる。何れのアプリも共有デバイス１０５＿１にアクセスしない場合、デバイス監視装置１０３＿０は、ステップＳ８１４、ステップＳ９０２、ステップＳ９０９の処理を行わない。
　以上説明したように、アクセス方法、およびマルチコアプロセッサシステムによれば、ＣＰＵからドライバによるアクセス開始時刻以後、応答信号が返らずに所定時間が経過した場合、デバイス監視装置が共有デバイスの異常状態として検出信号を出力する。これにより、マルチコアプロセッサシステムは、ドライバが共有デバイスへのアクセスによって発生するストールを検出できる。
　また、デバイス監視装置は、所定時間について、共有デバイスの仕様となる応答時間を格納するメモリから参照してもよい。これにより、マルチコアプロセッサシステムは、応答時間の異なる共有デバイスの動作に合わせて、異常状態を検出できる。また、マルチコアプロセッサシステムは、ユーザの指示等により、所定時間を変更してもよい。
　また、デバイス監視装置は、共有デバイスからアクセスに対する応答信号が出力される場合には、所定時間とアクセス開始時刻からのアクセス時間との比較を停止する。これにより、マルチコアプロセッサシステムは、共有デバイスが正常に動作している場合に異常状態として検出してしまうことがないようにできる。
　また、デバイス監視装置は、ＣＰＵから共有デバイスに対して書き込まれるデータを保持する記憶領域を有し、異常状態を検出した場合に、記憶領域に対する保持を禁止してもよい。これにより、マルチコアプロセッサシステムは、異常状態となって共有デバイスに書き込まれなかったデータを、他のＣＰＵ等からによる上書きから保護することができる。
　また、デバイス監視装置は、異常状態を検出する前に記憶領域に書き込まれたデータを、異常検出後も保持していてもよい。これにより、マルチコアプロセッサシステムは、異常状態となって共有デバイスの制御レジスタに書き込まれなかったデータを保持することができる。
　また、デバイス監視装置は、検出信号に基づいてドライバがリセットされた後、記憶領域に保持していたデータを、共有デバイスの制御レジスタに書き込んでもよい。これにより、マルチコアプロセッサシステムは、異常状態から復元でき、異常状態を発生させたアプリとは異なる、問題のないアプリによって発生したデータを、共有デバイスに書き込ませることができる。
　また、デバイス監視装置は、記憶領域に保持していたデータを共有デバイスに書き込んだ後、異常状態を発生させたアプリを実行していたＣＰＵとは異なる他のＣＰＵによって実行される別のアプリからの共有デバイスへのアクセスを受け付けてもよい。これにより、マルチコアプロセッサシステムは、別のアプリがストールすることがなく、ストールが連鎖的に発生することを避けることができる。
　また、従来例にかかるマルチコアプロセッサシステムでは、ＯＳがアプリからの応答がないことを異常状態として検出していた。この場合、異常状態として検出できるまでに数秒かかってしまうため、ストールの連鎖が発生してしまい、また、ユーザの利便性が下がるといった問題があった。本実施の形態にかかるマルチコアプロセッサシステムでは、共有デバイスの応答時間という、短い時間で異常状態を検出できるため、ストールの連鎖が発生する前に異常状態を検出できるうえ、ユーザにも異常状態が発生したことを気づかれにくいという効果がある。
　また、従来例にかかるマルチコアプロセッサシステムでは、ストールが連鎖的に発生した場合に、ユーザが装置の故障と錯覚する可能性がある。錯覚した結果、設計者等が故障に対する対応が発生するという問題があった。装置の故障となった場合、故障の点検のために装置を回収することになり、対応にかかるコストが大きくなるという問題もあった。また、ソフトウェアによる異常発生は、様々な条件が重なったときに発生することもあり、異常状態の再現が困難であるという問題もあった。
　しかし、本実施の形態にかかるマルチコアプロセッサシステムでは、問題のあるアプリが強制終了し、他のアプリは正常実行するために、ユーザは装置の故障と錯覚せずにアプリに問題があるということを容易に判断できる。これにより、障害のレポートがあった場合、装置の回収をしなくてもよく、開発者は問題のあるアプリの再配布を行うことで対応できるため、マルチコアプロセッサシステは、対応にかかるコストを小さくすることができる。
　また、本実施の形態で説明したデバイス監視装置１０３は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣ（以下、単に「ＡＳＩＣ」と称す。）やＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ　Ｌｏｇｉｃ　Ｄｅｖｉｃｅ）によっても実現することができる。具体的には、たとえば、上述したデバイス監視装置１０３の機能（設定部２０１～タイマー２０７）をＨＤＬ記述によって機能定義し、そのＨＤＬ記述を論理合成してＡＳＩＣやＰＬＤに与えることにより、デバイス監視装置１０３を製造することができる。
　１０２　ウォッチドッグタイマー
　１０３　デバイス監視装置
　１０５　共有デバイス
　１０７　ダミーレジスタ
　１０８　デバイス応答時間ＤＢ
　１０９　制御レジスタ
　１１０、１１２　制御線
　１１１、１１３　データ線
　２０１　設定部
　２０２　時差検出部
　２０３　異常検出部
　２０４　ＡＣＫ出力部
　２０５　デバイス制御部
　２０６　書込部
　２０７　タイマー

Claims (9)

  1. 　第１アプリケーションの実行開始に基づいて第１ＣＰＵに対応するドライバを活性化し、
    　周辺デバイスへのアクセスに基づいてアクセス時間の計測を開始し、
    　前記アクセス時間が所定時間を超える場合には前記ドライバをリセットするための検出信号を出力するとともに、前記第１ＣＰＵから前記周辺デバイスに書き込まれるデータを保持するレジスタへの書き込みを禁止すること
    　を特徴とするアクセス方法。
  2. 　前記所定時間は、前記周辺デバイスの応答時間を格納するメモリから参照されること
    　を特徴とする請求項１に記載のアクセス方法。
  3. 　前記周辺デバイスから前記アクセスに対する応答信号が出力される場合には、前記所定時間と前記アクセス時間との比較を停止すること
    　を特徴とする請求項１または請求項２に記載のアクセス方法。
  4. 　前記レジスタは書き込みが禁止される前に書き込まれたデータを保持すること
    　を特徴とする請求項１乃至請求項３の何れか一の請求項に記載のアクセス方法。
  5. 　前記検出信号に基づいて前記ドライバがリセットされた後に前記レジスタに保持されるデータが前記周辺デバイスに書き込まれること
    　を特徴とする請求項１乃至請求項４の何れか一の請求項に記載のアクセス方法。
  6. 　前記レジスタのデータが前記周辺デバイスに書き込まれた後に、第２ＣＰＵによって実行される第２アプリケーションが前記周辺デバイスへアクセスすること
    　を特徴とする請求項５に記載のアクセス方法。
  7. 　第１アプリケーションを実行する第１ＣＰＵと、
    　前記第１アプリケーションによってアクセスされる周辺デバイスと、
    　を含み、
    　前記周辺デバイスに、タイマーと第１検出回路と第２検出回路とレジスタとを含む仮想レジスタを設定し、
    　前記タイマーは前記アクセスに応答してアクセス時間を計測し、
    　前記第１検出回路は前記アクセス時間と所定時間とを比較し、
    　前記第２検出回路は前記アクセス時間が前記所定時間を超えているときに検出信号を出力し、前記第１ＣＰＵから前記周辺デバイスに書き込まれるデータの前記レジスタへの書き込みを停止すること
    　を特徴とするマルチコアプロセッサシステム。
  8. 　前記検出信号に基づいて、前記第１ＣＰＵに対応するドライバがリセットされること
    　を特徴とする請求項７に記載のマルチコアプロセッサシステム。
  9. 　前記レジスタに保持されるデータが前記周辺デバイスに書き込まれること
    　を特徴とする請求項８に記載のマルチコアプロセッサシステム。
PCT/JP2010/070319 2010-11-15 2010-11-15 アクセス方法、およびマルチコアプロセッサシステム WO2012066622A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP10859635.4A EP2642399A1 (en) 2010-11-15 2010-11-15 Access method, and multi-core processor system
CN201080070131.7A CN103210381B (zh) 2010-11-15 2010-11-15 访问方法以及多核处理器系统
PCT/JP2010/070319 WO2012066622A1 (ja) 2010-11-15 2010-11-15 アクセス方法、およびマルチコアプロセッサシステム
JP2012544021A JP5541368B2 (ja) 2010-11-15 2010-11-15 アクセス方法、およびマルチコアプロセッサシステム
US13/894,022 US9164823B2 (en) 2010-11-15 2013-05-14 Resetting a peripheral driver and prohibiting writing into a register retaining data to be written into a peripheral on exceeding a predetermined time period

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/070319 WO2012066622A1 (ja) 2010-11-15 2010-11-15 アクセス方法、およびマルチコアプロセッサシステム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/894,022 Continuation US9164823B2 (en) 2010-11-15 2013-05-14 Resetting a peripheral driver and prohibiting writing into a register retaining data to be written into a peripheral on exceeding a predetermined time period

Publications (1)

Publication Number Publication Date
WO2012066622A1 true WO2012066622A1 (ja) 2012-05-24

Family

ID=46083588

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/070319 WO2012066622A1 (ja) 2010-11-15 2010-11-15 アクセス方法、およびマルチコアプロセッサシステム

Country Status (5)

Country Link
US (1) US9164823B2 (ja)
EP (1) EP2642399A1 (ja)
JP (1) JP5541368B2 (ja)
CN (1) CN103210381B (ja)
WO (1) WO2012066622A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018522357A (ja) * 2015-07-29 2018-08-09 メイコム コネクティビティ ソリューションズ，エルエルシーＭａｃｏｍ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｓｏｌｕｔｉｏｎｓ，Ｌｌｃ データリクエストに関連するクロックカウンタに基づくタイムアウト信号の生成
WO2018225641A1 (ja) * 2017-06-06 2018-12-13 日本電気株式会社 通信制御方法、記録媒体および通信制御装置
JP2020536306A (ja) * 2017-09-30 2020-12-10 ホアウェイ・テクノロジーズ・カンパニー・リミテッド システムサービスタイムアウト処理方法および装置

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9612893B2 (en) 2015-05-11 2017-04-04 Silicon Laboratories Inc. Peripheral watchdog timer
CN106407032A (zh) * 2016-09-18 2017-02-15 深圳震有科技股份有限公司 一种基于多核系统的硬件看门狗控制方法及系统
US10585755B2 (en) * 2016-11-29 2020-03-10 Ricoh Company, Ltd. Electronic apparatus and method for restarting a central processing unit (CPU) in response to detecting an abnormality
JP6645467B2 (ja) * 2017-03-28 2020-02-14 株式会社デンソー マイクロコンピュータ
JP6796040B2 (ja) * 2017-08-29 2020-12-02 日立オートモティブシステムズ株式会社 アクセス制御装置
US11263332B2 (en) * 2018-07-31 2022-03-01 International Business Machines Corporation Methods to discourage unauthorized register access
CN111274093B (zh) * 2020-01-23 2023-12-01 湖南快乐阳光互动娱乐传媒有限公司 一种应用程序的排序方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS55108026A (en) 1979-02-13 1980-08-19 Hitachi Ltd Common use system for input and output unit
JPH04273561A (ja) * 1991-02-28 1992-09-29 Nec Corp 入出力装置の占有制御方法および占有制御装置
JPH06208536A (ja) 1993-01-11 1994-07-26 Mitsubishi Electric Corp 配線設定装置
JP2001109646A (ja) * 1999-10-12 2001-04-20 Alps Electric Co Ltd ハードウェア初期化システム
JP2007507034A (ja) 2003-09-26 2007-03-22 エイティーアイ・テクノロジーズ，インコーポレイテッド コプロセッサを監視及びリセットするための方法及び装置
JP2008269335A (ja) * 2007-04-20 2008-11-06 Ricoh Co Ltd データ転送集積回路およびデータ転送装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2290891B (en) * 1994-06-29 1999-02-17 Mitsubishi Electric Corp Multiprocessor system
US20030140261A1 (en) * 2002-01-24 2003-07-24 Minoru Takasaki Control apparatus
US7146542B2 (en) * 2002-12-20 2006-12-05 Hewlett-Packard Development Company, L.P. Method and apparatus for diagnosis and repair of computer devices and device drivers
US7366944B2 (en) * 2005-01-14 2008-04-29 Microsoft Corporation Increasing software fault tolerance by employing surprise-removal paths
US7610445B1 (en) * 2005-07-18 2009-10-27 Palm, Inc. System and method for improving data integrity and memory performance using non-volatile media
US8001425B2 (en) * 2009-04-08 2011-08-16 Hewlett-Packard Development Company, L.P, Preserving state information of a storage subsystem in response to communication loss to the storage subsystem
JP4660604B2 (ja) * 2009-05-28 2011-03-30 株式会社東芝 情報処理装置および環境設定方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS55108026A (en) 1979-02-13 1980-08-19 Hitachi Ltd Common use system for input and output unit
JPH04273561A (ja) * 1991-02-28 1992-09-29 Nec Corp 入出力装置の占有制御方法および占有制御装置
JPH06208536A (ja) 1993-01-11 1994-07-26 Mitsubishi Electric Corp 配線設定装置
JP2001109646A (ja) * 1999-10-12 2001-04-20 Alps Electric Co Ltd ハードウェア初期化システム
JP2007507034A (ja) 2003-09-26 2007-03-22 エイティーアイ・テクノロジーズ，インコーポレイテッド コプロセッサを監視及びリセットするための方法及び装置
JP2008269335A (ja) * 2007-04-20 2008-11-06 Ricoh Co Ltd データ転送集積回路およびデータ転送装置

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018522357A (ja) * 2015-07-29 2018-08-09 メイコム コネクティビティ ソリューションズ，エルエルシーＭａｃｏｍ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｓｏｌｕｔｉｏｎｓ，Ｌｌｃ データリクエストに関連するクロックカウンタに基づくタイムアウト信号の生成
WO2018225641A1 (ja) * 2017-06-06 2018-12-13 日本電気株式会社 通信制御方法、記録媒体および通信制御装置
JP2018206105A (ja) * 2017-06-06 2018-12-27 日本電気株式会社 通信制御方法、プログラムおよび装置
JP7009786B2 (ja) 2017-06-06 2022-01-26 日本電気株式会社 通信制御方法、プログラムおよび装置
JP2020536306A (ja) * 2017-09-30 2020-12-10 ホアウェイ・テクノロジーズ・カンパニー・リミテッド システムサービスタイムアウト処理方法および装置
JP7006780B2 (ja) 2017-09-30 2022-01-24 ホアウェイ・テクノロジーズ・カンパニー・リミテッド システムサービスタイムアウト処理方法および装置
US11693701B2 (en) 2017-09-30 2023-07-04 Huawei Technologies Co., Ltd. System service timeout processing method, and apparatus

Also Published As

Publication number Publication date
US9164823B2 (en) 2015-10-20
CN103210381B (zh) 2015-11-25
JP5541368B2 (ja) 2014-07-09
CN103210381A (zh) 2013-07-17
EP2642399A1 (en) 2013-09-25
JPWO2012066622A1 (ja) 2014-05-12
US20130254598A1 (en) 2013-09-26

Similar Documents

Publication Publication Date Title
JP5541368B2 (ja) アクセス方法、およびマルチコアプロセッサシステム
US8892944B2 (en) Handling a failed processor of multiprocessor information handling system
US11068360B2 (en) Error recovery method and apparatus based on a lockup mechanism
US20110185153A1 (en) Simultaneous execution resumption of multiple processor cores after core state information dump to facilitate debugging via multi-core processor simulator using the state information
US8644136B2 (en) Sideband error signaling
JP2018116679A (ja) バスハング検出
EP3360044B1 (en) System and method for providing operating system independent error control in a computing device
US20150006978A1 (en) Processor system
JP2003511756A (ja) コンピュータにおいて故障分離および診断を改善する機構
US20140025903A1 (en) Multi-core processor system
US10318466B2 (en) Method and apparatus for handling outstanding interconnect transactions
US8880957B2 (en) Facilitating processing in a communications environment using stop signaling
JP5788611B2 (ja) リセット後の評価のためにリセットより前の状態を保存するための方法および装置
JP4644720B2 (ja) 制御方法、情報処理装置及びストレージシステム
US20040078649A1 (en) Computer system
CN108415788B (zh) 用于对无响应处理电路作出响应的数据处理设备和方法
JPH02205956A (ja) マルチプロセッサシステムにおけるデュアルポートメモリの故障診断装置
TW200846901A (en) Method for diagnosing system abnormality
JP6992295B2 (ja) 電子装置
JP3230798B2 (ja) 冗長システム
CN115132262A (zh) 一种快速ram检测方法、系统、检测设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10859635

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2012544021

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2010859635

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE