CN114064132B - 一种系统宕机恢复方法、装置、设备和系统 - Google Patents

一种系统宕机恢复方法、装置、设备和系统 Download PDF

Info

Publication number
CN114064132B
CN114064132B CN202111161066.5A CN202111161066A CN114064132B CN 114064132 B CN114064132 B CN 114064132B CN 202111161066 A CN202111161066 A CN 202111161066A CN 114064132 B CN114064132 B CN 114064132B
Authority
CN
China
Prior art keywords
downtime
identification
mcu
reset
memory area
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN202111161066.5A
Other languages
English (en)
Other versions
CN114064132A (zh
Inventor
刘宝瑞
耿树松
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ThunderSoft Co Ltd
Original Assignee
ThunderSoft Co Ltd
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 ThunderSoft Co Ltd filed Critical ThunderSoft Co Ltd
Priority to CN202111161066.5A priority Critical patent/CN114064132B/zh
Publication of CN114064132A publication Critical patent/CN114064132A/zh
Application granted granted Critical
Publication of CN114064132B publication Critical patent/CN114064132B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • 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/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • 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/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本公开涉及一种系统宕机恢复方法、装置、设备和系统。该方法应用于SOC芯片，包括：确定SOC芯片上的系统宕机的宕机类型，并根据宕机类型在第一内存区域更新对应的宕机标识；将宕机标识对应的转储文件和日志存储到第二内存区域；触发热复位之后，将转储文件和日志存储到宕机标识对应的第一非易失存储区域中；根据宕机标识向MCU发送复位请求信息；以及，在接收到MCU发送的上电复位信号时，进行系统宕机恢复。本发明提供的系统宕机恢复方法，在系统宕机恢复过程中不会造成日志丢失，便于对宕机原因进行分析；系统发生宕机时主动通知MCU，从而在最短时间内恢复正常使用，提高了系统健壮性，降低了系统的安全隐患，提升了用户体验。

Description

一种系统宕机恢复方法、装置、设备和系统
技术领域
本公开涉及一种系统宕机恢复方法、装置、设备和系统。
背景技术
现有技术中的车载系统大都是基于微控制单元(Micro Controller Unit，MCU)和系统级芯片(System On Chip，SOC)架构的系统，其中SOC芯片作为主处理器，负责包括车载娱乐系统和仪表系统的操作系统运行；而MCU芯片相当于操作系统的管家，负责控制整个操作系统的上下电、休眠、唤醒，监听SOC侧的心跳，监控车机是否异常，收发及路由CAN总线的信号，控制显示屏背光，资源仲裁处理及播放报时音(Chimes)。
在车载系统的实际应用中，由于MCU+SOC架构设计系统健壮性不足，如果SOC侧操作系统发生死机、冻屏、黑屏、无背光等宕机问题时，MCU在经过预设的一段时间没有监听到SOC侧的心跳时，会发出上电复位信号，强行复位操作系统。
发明内容
鉴于现有技术中存在的技术缺陷和技术弊端，本公开实施例提供克服上述问题或者至少部分地解决上述问题的一种系统宕机恢复方法、装置、设备和系统。
作为本公开实施例的第一方面，涉及一种系统宕机恢复方法，应用于SOC芯片，包括：
确定SOC芯片上的系统宕机的宕机类型，并根据所述宕机类型在第一内存区域更新对应的宕机标识；
将所述宕机标识对应的转储文件和日志存储到第二内存区域；
触发热复位之后，将所述转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中；
根据所述宕机标识向MCU发送复位请求信息；以及，
在接收到所述MCU发送的上电复位信号时，进行系统宕机恢复。
在一个或一些可选的实施例中，所述的系统宕机恢复方法中，触发热复位过程中，在将所述转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中之前，所述方法还包括：
判断所述系统是否发生宕机；
若否，清除所述第一内存区域中的宕机标识，并启动引导程序；
若是，启动所述引导程序，读取所述第一内存区域中的宕机标识，并根据所述宕机标识确定宕机类型，并清除所述第一内存区域中的宕机标识。
在一个或一些可选的实施例中，所述的系统宕机恢复方法中，所述宕机类型包括主系统崩溃；在系统宕机恢复之后，所述方法还包括：
在所述第一内存区域写入所述主系统崩溃对应的宕机标识。
在一个或一些可选的实施例中，所述的系统宕机恢复方法中，所述宕机类型包括资源泄漏；在触发热复位之前，所述方法还包括：
获取系统的资源使用数据，将所述资源使用数据与预设的资源配置阈值进行比较，并根据比较结果确定是否触发热复位。
在一个或一些可选的实施例中，所述的系统宕机恢复方法，还包括通过下述方式确定是否发生资源泄漏：
按照第一预设时间间隔周期性的获取系统运行数据；
根据当前获取的系统运行数据与至少一组在先获取的系统运行数据的比较结果，确定是否发生资源泄漏。
在一个或一些可选的实施例中，所述的系统宕机恢复方法中，所述宕机类型包括预设进程崩溃；在触发热复位之前，所述方法还包括：
在所述第一内存区域更新对应的宕机标识，并将所述宕机标识对应的转储文件和日志存储到第二内存区域之后，向所述预设进程发送重启指令；
判断所述预设进程在第二预设时间间隔内是否重启成功，若是，则触发热复位。
在一个或一些可选的实施例中，所述的系统宕机恢复方法，还包括通过下述方式确定预设进程是否崩溃：
判断在第三预设时间间隔内是否接收到所述预设进程发送的运行信息；
若否，确定所述预设进程崩溃。
在一个或一些可选的实施例中，所述的系统宕机恢复方法，所述宕机类型包括自复位子系统崩溃；在根据所述宕机标识向MCU发送宕机信息之前，所述方法还包括：
若所述宕机标识对应的宕机类型为自复位子系统崩溃，则根据所述宕机标识重新启动对应的自复位子系统；
判断所述自复位子系统在第四预设时间间隔内是否重启成功，若是，则不向所述MCU发送复位请求信息。
在一个或一些可选的实施例中，所述的系统宕机恢复方法，宕机类型包括非自复位子系统崩溃和/或客户端系统崩溃，在触发热复位之前，所述方法还包括：
接收所述非自复位子系统崩溃的消息和/或客户端系统崩溃的消息，触发所述主系统主动崩溃。
在一个或一些可选的实施例中，所述的系统宕机恢复方法中，在将所述转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中之后，还包括：
将所述第一内存区域中的宕机标识保存到第二非易失存储区域中，并记录保存时间信息。
在一个或一些可选的实施例中，所述的系统宕机恢复方法中，所述根据所述宕机标识向MCU发送复位请求信息，包括：
根据所述宕机标识通过中断请求向所述MCU发送复位请求信息；或，
根据接收的所述MCU发送的轮询请求，向所述MCU发送复位请求信息。
在一个或一些可选的实施例中，所述的系统宕机恢复方法，还包括：在系统发生宕机之前，按照第五预设时间间隔向所述MCU发送心跳信息；
以及，在所述MCU超过所述第五预设时间间隔未接收到所述心跳信息时，接收所述MCU发送的上电复位信号，并进行系统宕机恢复。
作为本公开实施例的第二方面，涉及一种系统宕机恢复装置，应用于SOC，包括：
标识模块，用于确定SOC芯片上的系统宕机的宕机类型，并根据所述宕机类型在第一内存区域更新对应的宕机标识；
存储模块，用于将所述宕机标识对应的转储文件和日志存储到第二内存区域；
转存模块，用于在触发热复位之后，将所述转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中；
宕机恢复模块，用于根据所述宕机标识向MCU发送复位请求信息；以及，
在接收到所述MCU发送的上电复位信号时，进行系统宕机恢复。
作为本公开实施例的第三方面，涉及一种SOC芯片，包括上述的系统宕机恢复装置。
作为本公开实施例的第四方面，涉及一种车载系统，包括MCU和上述的SOC芯片；
所述MCU，用于接收SOC芯片发送的复位请求信息，以及，向所述SOC芯片发送上电复位信号。
作为本公开实施例的第五方面，涉及一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述的系统宕机恢复方法。
作为本公开实施例的第六方面，涉及一种计算机设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述的系统宕机恢复方法。
本公开实施例至少实现了如下技术效果：
本发明实施例提供的系统宕机恢复方法，在系统运行发生宕机时，将宕机标识、转储文件和日志分别进行保存，在系统热复位时，根据宕机标识将转储文件和日志保存到非易失存储区域中，在系统宕机恢复过程中不会造成日志丢失，根据该转储文件和日志便于对宕机原因进行分析；并且根据该宕机标识主动向MCU发送请求信息，根据MCU的上电复位信号及时完成系统宕机恢复，系统发生宕机时不会被动的死等，而是主动通知MCU，从而系统能在最短时间内恢复正常使用，提高了系统健壮性，缩短了系统宕机恢复时间，降低了系统的安全隐患，提升了用户体验。
本公开的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本公开而了解。本公开的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所记载的结构来实现和获得。
下面通过附图和实施例，对本公开的技术方案做进一步的详细描述。
附图说明
附图用来提供对本公开的进一步理解，并且构成说明书的一部分，与本公开的实施例一起用于解释本公开，并不构成对本公开的限制。在附图中：
图1为现有技术中车载系统的结构示意图；
图2为现有技术中车载系统的系统运行流程示意图；
图3为现有技术中车载系统的系统运行流程示意图二；
图4为本公开提供的一种系统宕机恢复方法的流程示意图；
图5为本公开提供的一种车载系统的结构示意图；
图6为本公开提供的一种车载系统的系统运行流程示意图；
图7为本公开提供的一种Magic Number的设置示意图；
图8为本公开提供的另一种系统宕机恢复方法的流程示意图；
图9为本公开提供的一种系统宕机恢复装置的结构示意图；
图10为本公开提供的另一种系统宕机恢复装置的结构示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
由于在SOC因为各种原因造成死机、冻屏、黑屏、无背光等宕机类问题，此时，由于SOC已经失去响应，会对汽车的安全驾驶造成很大的隐患。并且在这种场景下，调试会非常困难。现有技术中SOC在被动等待MCU的上电复位信号进行复位操作系统时，等待的时间过长，并且，在宕机时很难抓到有效的日志，不能有效的分析操作系统的系统宕机原因，从而也就无法有针对性的解决宕机问题。以采用Hypervisor实现虚拟机的操作系统为例，该操作系统包括Host OS和Guest OS。该操作系统中常见的宕机类问题有：1、Host OS内核崩溃或卡死；2、Host OS上的重要进程发生崩溃，或者背光/显示相关的模块出现异常，造成显示异常；3、Host OS/Guest OS发生了严重的资源泄漏问题，导致系统卡死、黑屏、或是无法正常启动；4、Guest OS发生严重的崩溃或卡死。其中，Hypervisor是一种运行在物理服务器和操作系统之间的中间层软件，它可以允许多个操作系统和应用共享一套基础物理硬件，又称为虚拟机监视器(Virtual Machine Monitor)。Hypervisor运行的操作系统被称为HostOS，运行在Hypervisor提供的虚拟机上的操作系统被称为Guest OS。
参照图1所示，现有技术中的车载系统，MCU与SOC之间通过SPI方式通信，在该SOC上运行Host OS+Guest OS的操作系统，可以通过MCU来实现BCM的控制，而该Host OS上可以运行Cluster系统，该Host OS上可以运行IVI系统。参照图2所示，在首次系统启动时，通过MCU发送上电(Power-ON)信号，由SOC侧上电模块完成系统上电，在引导程序(Boot Loader)中判断系统未发生宕机，则通过该引导程序完成初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，由引导程序调用操作系统内核，执行操作系统的加载启动任务，完成开机。在系统启动完成后，系统会周期性的向MCU发送心跳。
其中，SPI为串行外设接口(Serial Peripheral Interface)，是一种高速的，全双工，同步的通信总线，并且在芯片的管脚上只占用四根线，节约了芯片的管脚，同时为PCB的布局上节省空间，提供方便，目前越来越多的芯片集成了这种通信协议。
在Host OS+Guest OS的操作系统中，如果Host OS的内核发生崩溃，整个仪表和中控都会黑屏，车机彻底无法正常工作，在热复位并停留在引导程序中，SOC既不会给MCU发任何心跳(Heart Beat)，也不会做保存日志的有效操作，只是被动的死等一段时间长度，通常为60s至600s的时间长度，由MCU强行复位整个系统。如果死等时间为120s，那么仪表和中控的黑屏现象会持续2分30秒左右，这对用户体验及安全造成极大隐患，并且，该MCU复位系统的方式为冷复位，系统会发生断电重启，系统宕机的日志(logs)都会丢失，因此，在系统复位之后，也无法对宕机原因进行有效分析；
如果Guest OS的内核发生崩溃，中控将会黑屏，仪表仍然正常，此时，Host OS将会抓取Guest OS的转储文件(Dump File)，抓取过程通常需要30分钟左右，在此过程中，中控会一直黑屏，并且，由于Host OS和Guest OS长时间进程间通信(Inter-ProcessCommunication，IPC)失败，在Host OS抓完转储文件以后，对Guest OS进行重启时，在重启过程中Guest OS可能会启动失败(比如，Guest OS反复重启或者Guest OS重启后中控依然黑屏，无背光)，这对用户体验及安全也会造成极大的隐患。由于现场破坏及日志缺失，因此，在系统复位之后，仅能基于从现场导出的转储文件进行分析，依然不能很好的得到系统宕机原因；
而如果是Host OS中发生关键进程崩溃，或背光/显示相关的模块异常，或是，HostOS或Guest OS发生资源泄漏等情况造成的系统宕机，在系统复位之前也会造成严重的安全隐患，并且，同样会发生系统复位之后现场日志丢失的情况。
参照图3所示，在系统发生资源泄漏的宕机问题时，需要Host OS或Guest OS自行处理，例如，Host OS中资源泄漏(包括内存资源泄漏、分区资源泄漏等)时，系统不会执行任何操作，直至系统主动崩溃；
在Guest OS中若发生内存资源泄漏，则会自行对系统中的程序进行消杀，选择性的进行文件转储；
在Guest OS中若发生内存资源泄漏，系统同样不会执行任何操作。而当系统发生关键进程崩溃时，在Host OS中只会进行文件转储，而不会触发系统复位；
当Guest OS发生崩溃时，由Host OS进行文件转储，并在文件转储完成后，进行Guest OS复位。
现有技术中的上述Host OS+Guest OS架构的操作系统中，SOC由MCU上电启动，每次启动到SOC的引导程序时，引导程序都会先确认本次启动是正常启动，或是，上一次的重启原因是发生系统宕机。如果确认是系统宕机，则系统会停在引导程序中，被动的死等MCU。在这种场景下，默认的设计是，SOC既不会给MCU发任何心跳，也不会做保存日志等有效的操作，只是被动的死等，直到被MCU强行复位，或是SOC的供电电源耗尽。此时装在该操作系统的车机会是长时间的黑屏，如果被MCU强行复位整个车载系统，则所有现场的日志都会丢失。
如果SOC的Host OS并未发生崩溃，而是发生了Guest OS崩溃，Host OS关键进程崩溃、严重资源泄漏、冻屏、黑屏等致命的问题，都是SOC自行处理的，或是没有处理机制，导致的后果同样是车载系统长时间无法工作，及现场logs的丢失。
综上，本发明的发明人认为，上述车载系统中主要存在下述技术问题：SOC侧发生系统宕机时，并未得到及时处理，而是MCU被动死等，并会造成现场logs丢失。且MCU死等时间过长，当系统发生严重故障时，SOC无法主动通知MCU，并把SOC的宕机类型告知MCU，导致MCU无法进行合理的处理。SOC侧的宕机类型很多，但是除了Host OS宕机会直接导致SOC重启并被引导程序捕获以外，其他宕机类型都不会被引导程序捕获并得到有效的处理，而是由SOC的Host OS或Guest OS自行处理，或者是不做任何处理。导致的后果是，一旦SOC侧发生严重问题，车载系统在驾驶过程中无法正常使用，并可能会造成现场logs丢失。
基于此，本发明提供一种系统宕机恢复方法、装置和系统，该方法能在系统宕机时保存关键日志，并能快速恢复系统。该方法不仅适用于支持虚拟机架构Host OS+Guest OS的操作系统、也同样适用于不支持虚拟机的操作系统架构。
实施例一
本发明实施例一提供一种系统宕机恢复方法，应用于SOC芯片，参照图4所示，包括：
S101：确定SOC芯片上的系统宕机的宕机类型，并根据所述宕机类型在第一内存区域更新对应的宕机标识；
S102：将所述宕机标识对应的转储文件和日志存储到第二内存区域；
S103：触发热复位之后，将所述转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中；
S104：根据所述宕机标识向MCU发送复位请求信息；以及，
在接收到所述MCU发送的上电复位信号时，进行系统宕机恢复。
本发明实施例提供的系统宕机恢复方法，在系统运行发生宕机时，将宕机标识、转储文件和日志分别进行保存，在系统热复位时，根据宕机标识将转储文件和日志保存到非易失存储区域中，在系统宕机恢复过程中不会造成日志丢失，根据该转储文件和日志便于对宕机原因进行分析；并且根据该宕机标识主动向MCU发送请求信息，根据MCU的上电复位信号及时完成系统宕机恢复，系统发生宕机时不会被动的死等，而是主动通知MCU，从而系统能在最短时间内恢复正常使用，提高了系统健壮性，缩短了系统宕机恢复时间，降低了系统的安全隐患，提升了用户体验。
本实施例中的系统可以是现有技术中的任一操作系统，例如车机的操作系统，包括车载(Telematics Box，T-box)系统、车载信息娱乐系统(In-Vehicle Infotainment，IVI)。本实施例对该系统的具体类型可以不作具体限定，只要能够采用上述系统宕机恢复方法即可。并且，本发明实施例中该系统的实现构架可以采用Android系统或Linux系统等现有技术中的操作系统构架，本发明实施例中对于系统构架的具体实现类型也可以不作具体限定。
以该系统为车载系统构架的操作系统为例，参照图5所示，本发明实施例中，假设该车载系统包括MCU和SOC，该系统应用于车载系统的SOC，该MCU与SOC之间采用SPI通信，并且在MCU和SOC之间设置值中断引脚IRQ，以便于系统发生宕机时，根据宕机标识通过中断请求(Interrupt Request，IRQ)主动向MCU发送复位请求信息。具体的，可以是，系统根据不同的宕机类型，在该第一内存区域中写入不同的宕机标识，将该宕机标识对应的转储文件和日志存储到第二内存区域；随后触发热复位并进入引导程序中。
本发明实施例中，该第一内存区域和该第二内存区域可以是同步动态随机存取内存(Synchronous Dynamic Random-Access Memory，简称SDRAM)的保留内存(ReservedMemory)区域。
本发明实施例中，系统在触发热复位时，系统中主系统的CPU和各个子系统的CPU以及各个CPU所共用的SDRAM均能够保持带电状态不会发生断电，不会发生数据丢失，从而在进入引导程序后，可以根据第一预设内存区域中存储的宕机标识确定系统的宕机类型，并根据不同的宕机类型，从第二内存区域中，导出转储文件和日志，并保存到第一非易失存储区域中，该第一非易失存储区域可以设置于系统的本地文件系统中文件区域或原始数据(Raw Data)区域中。随后，根据宕机标识主动的向MCU发送复位请求信息，在接收到所述MCU发送的上电复位信号时，进行系统宕机恢复，实现快速恢复整个系统。
本发明实施例中上述转储文件为系统发生宕机，程序发生异常中断而存储的运行程序的内存状况的核心文件(Core Dump)或错误记录文件(Wrong Dump)。本发明实施例中，系统宕机的类型可以有多种，每个不同宕机类型所对应的转储文件和日志也是不同的。例如，如果发生主系统崩溃，由于系统崩溃时产生的转储文件和日志很多，若全部保存需要花费几分钟，甚至几十分钟，所以在该第一内存区域中可以只保存能够调试和宕机原因分析的必要转储文件和关键的日志，以缩短系统宕机恢复的时间，而如果发生系统的进程崩溃，由于进程崩溃时产生的转储文件和日志很少，因此，在该第一内存区域中可以保存进程崩溃时产生的全部转储文件和日志。当然，也可以是根据调试和宕机原因分析的需求，预先确定在进程崩溃时需要保存的必要的部分转储文件和日志。本发明实施例中关于转储文件和日志的保存实现方式可以参照现有技术中的方式，本发明实施例中可以不作具体限定。
本发明实施例中所描述的系统的宕机类型可以包括主系统崩溃、资源泄漏、预设进程崩溃。其中，参照图6所示，假设该系统为Host OS+Guest OS的操作系统，则该系统的宕机类型还包括客户端系统崩溃，该主系统崩溃即该Host OS崩溃，该客户端系统崩溃即该Guest OS崩溃。
本发明实施例中，该系统的宕机类型还可以包括子系统崩溃，由于不同的子系统崩溃时，导致的结果不同，有的子系统崩溃，会触发主系统崩溃，而有的子系统崩溃时可以由主系统尝试自行复位，而不会触发主系统主动崩溃，因此，我们可以称这种会触发主系统崩溃的子系统为非自复位子系统，而将不会触发主系统主动崩溃的子系统称为自复位子系统，那么，子系统崩溃就可以包括自复位子系统崩溃和非自复位子系统崩溃。本发明实施例中，该系统所应用的操作平台不同，其所包括的子系统的数量和类型也不同，以高通平台的操作系统为例，其中，信任区(Trust Zone，TZ)系统、红帽软件包管理器(Red-Hat PackageManager，RPM)系统崩溃时，会触发主系统主动崩溃，而自动数字信号处理(AutomaticDigital Signal Processing，ADSP)系统、无线连接子系统(Wireless ConnectivitySubsystem，WCNSS)崩溃时，主系统可以自行处理，主动对崩溃的子系统进行复位，而不会主动触发主系统崩溃。
本发明实施例中所描述的资源泄漏可以包括显存资源泄漏、内存资源泄漏、直接内存访问资源(Direct Memory Access，DMA)泄漏、分区资源泄漏和句柄(Handle)资源泄漏中的至少一种。
本发明实施例中所描述的预设进程可以是系统运行中的关键进程，包括内存管理进程、显示管理进程和背光管理进程等。
参照图6所示，本发明实施例中在执行步骤S102触发热复位过程中，会先判断所述系统是否发生宕机，即首先判断系统是正常关机重启还是发生了宕机触发热复位，若是正常重启流程，则会在系统重启之前清除第一内存区域中的宕机标识，再启动引导程序BootLoader，按照正常关机重启的流程进行系统恢复，以避免在引导程序中读取到错误的宕机标识造成误判，触发错误的转储文件和日志存储以及造成按照系统宕机对系统进行恢复；若不是正常重启，而是发生宕机重启，则会在启动引导程序之后，读取第一内存区域中的宕机标识，并根据该宕机标识确定宕机类型，再清除第一内存区域中的宕机标识，并将系统宕机时的转储文件和日志存储到宕机标识对应的第一非易失存储区域中，接着，根据所述宕机标识向MCU发送复位请求信息；以及，在接收到所述MCU发送的上电复位信号时，进行系统宕机恢复。
本发明实施例中提供的上述系统在发生系统宕机时，如果是主系统(Host OS)崩溃，则在系统宕机时没有机会再将宕机标识写入该第一内存区域，因此，在系统宕机恢复之后，需要首先在该第一内存区域写入该主系统崩溃对应的宕机标识，从而在系统宕机类型为主系统崩溃时，触发热复位，由启动程序根据该宕机标识确认系统宕机类型及执行系统宕机恢复的过程。
本发明实施例中，主系统崩溃可以是指主系统自身崩溃、由于系统负载过高造成主系统卡死等主系统自身不能进行处理时的系统崩溃，此时主系统无法在该第一内存区域写入宕机标识。因此，可以设置在执行步骤S104完成系统宕机复位之后，即系统在正常运行过程中，按照预设的时间间隔定期向该第二内存区域存储日志，从而在系统触发热复位，启动引导程序时，根据宕机标识将该第二内存区域中保存下来的日志，保存到第一非易失存储区域中；并且，由于系统在发生崩溃时能够创建崩溃转储进程，完成转储文件的保存到第二内存区域，因此，在启动引导程序时，根据宕机标识还可以将该第二内存区域中保存下来的转储文件，保存到该第一非易失存储区域中。
本发明实施例中提供的上述系统在发生系统宕机时，如果宕机类型不是主系统崩溃，而是资源泄漏、预设进程崩溃、子系统崩溃或者客户端系统崩溃，此时，由于宕机时主系统尚在工作，因此，可以在确定宕机类型之后，将对应的宕机标识写入到该第一内存区域，从而在系统宕机类型为主系统崩溃时，触发热复位，由启动程序根据该宕机标识确认系统宕机类型为资源泄漏、预设进程崩溃、子系统崩溃或者客户端系统崩溃，进而执行系统宕机恢复的过程。
本发明实施例中，因为Magic Number(幻数或魔数)可以用来标记文件或者协议的格式，可以用作文件系统、数据结构、特殊属性的标志位，都用Magic Number作为标志。作为本发明实施例的一个具体实施方式，参照图7所示，也可以采用不同的Magic Number来表示不同的宕机标识，例如采用0xDEA0000作为主系统崩溃的宕机标识，采用0xAAA0001到0xAAA000N分别表示不同子系统崩溃的宕机标识，采用0xBAA0001到0xBAA000N分别表示不同预设进程崩溃的宕机标识，采用0xCCAA0001到0xCCAA000N分别表示不同资源泄漏的宕机标识，采用0xDDAA0000标识客户端系统崩溃的宕机标识。
本发明实施例中，通过下述方式确定是否发生资源泄漏：
按照第一预设时间间隔周期性的获取系统运行数据；
根据当前获取的系统运行数据与至少一组在先获取的系统运行数据的比较结果，确定是否发生资源泄漏。
在一个具体实施例中，可以是，比如，该系统运行数据包括SOC芯片中各CPU的运行数据、SDRAM的运行数据和Storage数据等，系统每间隔第一预设时间(例如5分钟或10分钟)获取一次系统运行数据，并进行分析，如果当前获取的系统运行数据与时间最近的至少一组系统运行数据相比较，资源占用量在不断上涨，就会判断系统发生了资源泄漏。
在系统发生资源泄漏时，在主系统崩溃之前，可以先将资源泄漏对应的宕机标识写入该第一内存区域，保存对应的转储文件和系统运行过程中产生的日志存储到第二内存区域，不直接触发热复位。而是执行步骤S102之前，即在触发热复位之前，获取系统的资源使用数据，将所述资源使用数据与预设的资源配置阈值进行比较，并根据比较结果确定是否触发热复位。
在一个具体实施例中，可以是在系统预制一个资源配置表，该资源配置表中预设设定了资源配置阈值，例如显存配置阈值、内存配置阈值等，在触发热复位之前，判断系统的当前资源使用量是否超过资源配置阈值。
以显存泄漏的场景为例，假设显存配置阈值为99％，如果检测到系统中发生了显存泄漏并且显存使用量未超过显存资源总量的99％，即显存使用量低于资源配置阈值，则此时系统应当将显存资源泄漏对应的宕机标识更新到第一内存区域，并将显存资源泄漏对应的系统运行中的日志保存到第二内存区域，而不必直接触发热复位；只有当显存使用量高于资源配置阈值，才触发热复位，以避免频繁进行系统重启，影响系统正常使用。
再以内存资源泄漏为例，由于内存资源泄漏可能会直接导致主系统中的进程申请不到内存而崩溃，从而会触发宕机或黑屏，如果检测到系统中发生了内存资源泄漏，并且内存使用量未超过内存资源总量的99％，即内存使用量低于资源配置阈值，则此时系统应当将内存资源泄漏对应的宕机标识更新到第一内存区域，并将内存资源泄漏对应的系统运行中的日志保存到第二内存区域，而不必直接触发热复位；只有当内存使用量高于资源配置阈值，才触发热复位，以避免频繁进行系统重启，影响系统中进程的正常运行。
本发明实施例中，资源泄漏为DMA资源泄漏、分区资源泄漏或句柄资源泄漏时的处理过程与上述显存资源泄漏和内存资源泄漏的处理过程相类似，本领域技术人员在实现本实施例过程中可以参照上述显存资源泄漏和内存资源泄漏的处理过程，在此，不再赘述。
本发明实施例中，可以通过下述方式确定预设进程是否崩溃：
判断在第三预设时间间隔内是否接收到所述预设进程发送的运行信息；
若否，确定所述预设进程崩溃。
在一个具体实施例中，可以是，在系统中实现一个看门狗进程，该看门狗进程可以通过一个数组结构管理所有预设进程。在该数据结构中的每个预设进程都应当在规定的第三预设时间间隔内喂狗。如果任一预设进程超过第三预设时间间隔没有喂狗，则通过该看门狗进程就可以确定该预设进程崩溃。
在系统发生预设进程崩溃时，在主系统崩溃之前，可以先将预设程序泄漏对应的宕机标识写入该第一内存区域，保存对应的转储文件和系统运行过程中产生的日志存储到第二内存区域，而不直接触发热复位。可以是，在是执行步骤S102之前，即在触发热复位之前，在第一内存区域更新对应的宕机标识，并将宕机标识对应的转储文件和日志存储到第二内存区域之后，向该预设进程发送重启指令；判断该预设进程在第二预设时间间隔内是否重启成功，若是，则不触发热复位。如果超过该第二预设时间间隔，该预设程序重启不成功，则表明系统发生了系统不能自行处理的严重宕机问题，则此时触发热复位。
本发明实施例中，上述自复位子系统和非自复位子系统应该分别设置不同的宕机标识，若系统的宕机类型为非自复位子系统崩溃时，在触发热复位之前，该非自复位子系统会主动发送崩溃通知信息，系统接收到该非自复位子系统崩溃的消息，会触发主系统主动崩溃，从而触发热复位。
本发明实施例中，若采用Magic Number作为宕机标识时，为了将非自复位子系统崩溃和主系统崩溃的宕机标识进行区分，可以将主系统崩溃对应的Magic Number按位与运算，生成新的Magic Number，将该新生成的Magic Number作为非自复位子系统崩溃对应的宕机标识。
在系统非自复位子系统崩溃时，将该新生成的Magic Number写入第一内存区域，在第二内存区域中保存对应的转储文件和日志，触发热复位，启动引导程序，进而，根据该新生成的Magic Number将该第二内存区域中保存下来的转储文件和日志，保存到第一非易失存储区域中。最后，根据所该新生成的Magic Number向MCU发送复位请求信息；以及，在接收到MCU发送的上电复位信号时，进行系统宕机恢复。
本发明实施例中，系统发生自复位子系统崩溃时，在主系统崩溃之前，可以先将自复位子系统崩溃对应的宕机标识写入该第一内存区域，保存对应的转储文件和系统运行过程中产生的日志存储到第二内存区域，触发热复位，将转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中，但不直接向MCU发送复位请求信息。可以是，在执行步骤S104之前，即在根据宕机标识向MCU发送复位请求信息之前，根据宕机标识重新启动对应的自复位子系统；判断自复位子系统在第四预设时间间隔内是否重启成功，若是，则不向MCU发送复位请求信息。如果超过该第四预设时间间隔，该自复位子系统重启不成功，则表明系统发生了系统不能自行处理的严重宕机问题，则此时向MCU发送复位请求信息。
本发明实施例中，若系统的宕机类型为客户端系统崩溃，在触发热复位之前，该客户端系统会主动发送崩溃通知信息，系统接收到该客户端系统崩溃的消息，则触发主系统主动崩溃，从而触发热复位。
本发明实施例中，为了便于对系统宕机原因进行分析，在将所述转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中之后，还可以将第一内存区域中的宕机标识保存到第二非易失存储区域中，并记录保存时间信息。例如通过时间戳标记该第二非易失存储区域中宕机标识的保存时间信息。
本发明实施例中，参照图5所示，通过在MCU与SOC之间设置中断引脚，当系统宕机时，通过中断请求向MCU发送复位请求信息仅为本发明实施例的一个具体实现方式，采用异步机制实现复位请求，不影响SOC侧系统的宕机现场的转储文件和日志的保存，能够保证系统宕机快速恢复，并且整个系统不能及时恢复及现场logs丢失。当然本发明实施例中也可以采用软件实现的同步机制实现复位请求，具体的，可以是，系统接收MCU发送的轮询请求，根据该轮询请求，向MCU发送复位请求信息。
当然本发明实施例中，向MCU发送复位请求信息的方式还可以采用现有技术中的其他方式实现，本发明实施例中，对此可以不作具体限定。
本发明实施例中，参照图6所示，该系统宕机恢复方法，还包括：在系统发生宕机之前，按照预设时间间隔向所述MCU发送心跳信息；
以及，在所述MCU超过第五预设时间间隔未接收到所述心跳信息时，接收所述MCU发送的上电复位信号，并进行系统宕机恢复。
本发明实施例中，为了保证系统宕机能够恢复，还可以在系统启动完成后，让系统会周期性的向MCU发送心跳，如超过第五预设时间间隔MCU未监听到心跳，则直接强行复位系统。
实施例二
基于同一发明构思，本公开实施例还提供了一种系统宕机恢复方法，应用于MCU，参照图8所示，包括：
S201：接收SOC芯片发送的复位请求信息；
S202：向所述SOC芯片发送上电复位信号。
本发明实施例中该应用于MCU的系统宕机恢复方法的具体处理过程，可以参照上述实施例一中提供的系统宕机恢复方法中关于MCU的执行过程的详细描述，本发明实施例中在此不再赘述。
实施例三
基于同一发明构思，本公开实施例还提供了一种系统宕机恢复装置，其特征在于，包括：
标识模块101，用于确定SOC芯片上的系统宕机的宕机类型，并根据所述宕机类型在第一内存区域更新对应的宕机标识；
存储模块102，用于将所述宕机标识对应的转储文件和日志存储到第二内存区域；
转存模块103，用于在触发热复位之后，将所述转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中；
宕机恢复模块104，用于根据所述宕机标识向MCU发送复位请求信息；以及，
在接收到所述MCU发送的上电复位信号时，进行系统宕机恢复。
在一个实施例中，该系统宕机恢复装置中，标识模块101，还用于判断所述系统是否发生宕机；
若否，清除所述第一内存区域中的宕机标识，并启动引导程序；
若是，启动所述引导程序，读取所述第一内存区域中的宕机标识，并根据所述宕机标识确定宕机类型，并清除所述第一内存区域中的宕机标识。
在一个实施例中，该系统宕机恢复装置，标识模块101，还用于在所述第一内存区域写入所述主系统崩溃对应的宕机标识。
在一个实施例中，所述宕机类型包括资源泄漏；该系统宕机恢复装置，还包括：
资源泄漏确定模块，用于获取系统的资源使用数据，将所述资源使用数据与预设的资源配置阈值进行比较，并根据比较结果确定是否触发热复位。
在一个实施例中，所述资源泄漏确定模块，还用于通过下述方式确定是否发生资源泄漏：
按照第一预设时间间隔周期性的获取系统运行数据；
根据当前获取的系统运行数据与至少一组在先获取的系统运行数据的比较结果，确定是否发生资源泄漏。
在一个实施例中，所述宕机类型包括预设进程崩溃；该系统宕机恢复装置，还包括：
进程崩溃确定模块，用于在所述第一内存区域更新对应的宕机标识，并将所述宕机标识对应的转储文件和日志存储到第二内存区域之后，向所述预设进程发送重启指令；
判断所述预设进程在第二预设时间间隔内是否重启成功，若是，则触发热复位。
在一个实施例中，所述进程崩溃确定模块，还用于通过下述方式确定预设进程是否崩溃：
判断在第三预设时间间隔内是否接收到所述预设进程发送的运行信息；
若否，确定所述预设进程崩溃。
在一个实施例中，所述宕机类型包括自复位子系统崩溃；该系统宕机恢复装置，还包括：
自复位子系统崩溃模块，用于在根据所述宕机标识向MCU发送宕机信息之前，根据所述宕机标识重新启动对应的自复位子系统；
判断所述自复位子系统在第四预设时间间隔内是否重启成功，若是，则不向所述MCU发送复位请求信息。
在一个实施例中，宕机类型包括非自复位子系统崩溃，该系统宕机恢复装置，还包括：
非自复位子系统崩溃模块，用于在触发热复位之前，接收所述非自复位子系统崩溃的消息，触发所述主系统主动崩溃。
在一个实施例中，所述宕机类型包括客户端系统崩溃；该系统宕机恢复装置，还包括：
客户端系统崩溃模块，用于在触发热复位之前，接收所述客户端系统崩溃的消息，触发所述主系统主动崩溃。
在一个实施例中，该系统宕机恢复装置，还包括：存储模块，用于在将所述转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中之后，将所述第一内存区域中的宕机标识保存到第二非易失存储区域中，并记录保存时间信息。
在一个实施例中，该系统宕机恢复装置，宕机恢复模块104，具体用于根据所述宕机标识通过中断请求向所述MCU发送复位请求信息；或，
根据接收的所述MCU发送的轮询请求，向所述MCU发送复位请求信息。
在一个实施例中，该系统宕机恢复装置，宕机恢复模块104，还用于在系统发生宕机之前，按照第五预设时间间隔向所述MCU发送心跳信息；
以及，在所述MCU超过所述第五预设时间间隔未接收到所述心跳信息时，接收所述MCU发送的上电复位信号，并进行系统宕机恢复。
实施例四
基于同一发明构思，本公开实施例还提供了一种系统宕机恢复装置，应用于MCU，包括：
接收模块201，用于接收SOC芯片发送的复位请求信息；
发送模块202，用于向所述SOC芯片发送上电复位信号。
实施例五
基于同一发明构思，本公开实施例还提供了一种SOC芯片，包括上述实施例三所描述的系统宕机恢复装置。
实施例六
基于同一发明构思，本公开实施例还提供了一种MCU，包括上述实施例四所描述的系统宕机恢复装置。
实施例七
基于同一发明构思，本公开实施例还提供了一种车载系统，包括上述实施例五所描述的SOC芯片和上述实施例六所描述的MCU。
基于同一发明构思，本公开实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述实施例一或上述实施例二所描述的系统宕机恢复方法。
基于同一发明构思，本公开实施例还提供了一种计算机设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述实施例一或上述实施例二所描述的系统宕机恢复方法。
由于这些方法、装置所解决问题的原理与前述消息处理系统相似，因此这些方法、装置的实施可以参见前述消息处理系统的实施，重复之处不再赘述。本领域内的技术人员应明白，本公开的实施例可提供为方法、系统、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本公开是参照根据本公开实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
最后应说明的是：以上实施例仅用以说明本公开的技术方案，而非对其限制；尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本公开各实施例技术方案的精神和范围。

Claims (17)

1.一种系统宕机恢复方法，应用于SOC芯片，其特征在于，包括：
确定SOC芯片上的系统宕机的宕机类型，并根据所述宕机类型在第一内存区域更新对应的宕机标识；
将所述宕机标识对应的转储文件和日志存储到第二内存区域；
触发热复位之后，将所述转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中；
根据所述宕机标识向MCU发送复位请求信息；以及，
在接收到所述MCU发送的上电复位信号时，进行系统宕机恢复。
2.如权利要求1所述的系统宕机恢复方法，其特征在于，触发热复位过程中，在将所述转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中之前，所述方法还包括：
判断所述系统是否发生宕机；
若否，清除所述第一内存区域中的宕机标识，并启动引导程序；
若是，启动所述引导程序，读取所述第一内存区域中的宕机标识，并根据所述宕机标识确定宕机类型，并清除所述第一内存区域中的宕机标识。
3.如权利要求2所述的系统宕机恢复方法，其特征在于，所述宕机类型包括主系统崩溃；在系统宕机恢复之后，所述方法还包括：
在所述第一内存区域写入所述主系统崩溃对应的宕机标识。
4.如权利要求3所述的系统宕机恢复方法，其特征在于，所述宕机类型包括资源泄漏；在触发热复位之前，所述方法还包括：
获取系统的资源使用数据，将所述资源使用数据与预设的资源配置阈值进行比较，并根据比较结果确定是否触发热复位。
5.如权利要求4所述的系统宕机恢复方法，其特征在于，还包括通过下述方式确定是否发生资源泄漏：
按照第一预设时间间隔周期性的获取系统运行数据；
根据当前获取的系统运行数据与至少一组在先获取的系统运行数据的比较结果，确定是否发生资源泄漏。
6.如权利要求3所述的系统宕机恢复方法，其特征在于，所述宕机类型包括预设进程崩溃；在触发热复位之前，所述方法还包括：
在所述第一内存区域更新对应的宕机标识，并将所述宕机标识对应的转储文件和日志存储到第二内存区域之后，向所述预设进程发送重启指令；
判断所述预设进程在第二预设时间间隔内是否重启成功，若是，则触发热复位。
7.如权利要求6所述的系统宕机恢复方法，其特征在于，还包括通过下述方式确定预设进程是否崩溃：
判断在第三预设时间间隔内是否接收到所述预设进程发送的运行信息；
若否，确定所述预设进程崩溃。
8.如权利要求3所述的系统宕机恢复方法，其特征在于，所述宕机类型包括自复位子系统崩溃；在根据所述宕机标识向MCU发送宕机信息之前，所述方法还包括：
若所述宕机标识对应的宕机类型为自复位子系统崩溃，则根据所述宕机标识重新启动对应的自复位子系统；
判断所述自复位子系统在第四预设时间间隔内是否重启成功，若是，则不向所述MCU发送复位请求信息。
9.如权利要求3所述的系统宕机恢复方法，其特征在于，宕机类型包括非自复位子系统崩溃和/或客户端系统崩溃，在触发热复位之前，所述方法还包括：
接收所述非自复位子系统崩溃的消息和/或客户端系统崩溃的消息，触发所述主系统主动崩溃。
10.如权利要求1-9任一项所述的系统宕机恢复方法，其特征在于，在将所述转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中之后，还包括：
将所述第一内存区域中的宕机标识保存到第二非易失存储区域中，并记录保存时间信息。
11.如权利要求1-9任一项所述的系统宕机恢复方法，其特征在于，所述根据所述宕机标识向MCU发送复位请求信息，包括：
根据所述宕机标识通过中断请求向所述MCU发送复位请求信息；或，
根据接收的所述MCU发送的轮询请求，向所述MCU发送复位请求信息。
12.如权利要求11所述的系统宕机恢复方法，其特征在于，还包括：在系统发生宕机之前，按照第五预设时间间隔向所述MCU发送心跳信息；
以及，在所述MCU超过所述第五预设时间间隔未接收到所述心跳信息时，接收所述MCU发送的上电复位信号，并进行系统宕机恢复。
13.一种系统宕机恢复装置，应用于SOC，其特征在于，包括：
标识模块，用于确定SOC芯片上的系统宕机的宕机类型，并根据所述宕机类型在第一内存区域更新对应的宕机标识；
存储模块，用于将所述宕机标识对应的转储文件和日志存储到第二内存区域；
转存模块，用于在触发热复位之后，将所述转储文件和日志存储到所述宕机标识对应的第一非易失存储区域中；
宕机恢复模块，用于根据所述宕机标识向MCU发送复位请求信息；以及，在接收到所述MCU发送的上电复位信号时，进行系统宕机恢复。
14.一种SOC芯片，其特征在于，包括权利要求13所述的系统宕机恢复装置。
15.一种车载系统，其特征在于，包括MCU和权利要求14所述的SOC芯片和；
所述MCU，用于接收SOC芯片发送的复位请求信息，以及，向所述SOC芯片发送上电复位信号。
16.一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如权利要求1-12任一项所述的系统宕机恢复方法。
17.一种计算机设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1-12任一项所述的系统宕机恢复方法。
CN202111161066.5A 2021-09-30 2021-09-30 一种系统宕机恢复方法、装置、设备和系统 Active CN114064132B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111161066.5A CN114064132B (zh) 2021-09-30 2021-09-30 一种系统宕机恢复方法、装置、设备和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111161066.5A CN114064132B (zh) 2021-09-30 2021-09-30 一种系统宕机恢复方法、装置、设备和系统

Publications (2)

Publication Number Publication Date
CN114064132A CN114064132A (zh) 2022-02-18
CN114064132B true CN114064132B (zh) 2023-07-21

Family

ID=80234014

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111161066.5A Active CN114064132B (zh) 2021-09-30 2021-09-30 一种系统宕机恢复方法、装置、设备和系统

Country Status (1)

Country Link
CN (1) CN114064132B (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116056163B (zh) * 2022-07-19 2023-10-20 荣耀终端有限公司 一种通信方法及相关设备
CN115098176B (zh) * 2022-07-25 2023-02-21 珠海普林芯驰科技有限公司 一种芯片启动引导和程序升级的方法及芯片架构
CN117950472A (zh) * 2022-10-21 2024-04-30 荣耀终端有限公司 复位方法和电子设备
CN116302646B (zh) * 2023-02-24 2024-03-29 荣耀终端有限公司 一种故障定位方法、系统、电子设备及存储介质
CN116701041B (zh) * 2023-07-27 2023-11-10 飞腾信息技术有限公司 一种内存数据保留方法、保留装置和相关设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108984332A (zh) * 2018-06-22 2018-12-11 郑州云海信息技术有限公司 一种定位服务器宕机故障的装置及方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7028056B1 (en) * 2000-04-14 2006-04-11 Microsoft Corporation Method and arrangements for generating debugging information following software failures
US6779132B2 (en) * 2001-08-31 2004-08-17 Bull Hn Information Systems Inc. Preserving dump capability after a fault-on-fault or related type failure in a fault tolerant computer system
CN100472471C (zh) * 2006-02-22 2009-03-25 联想(北京)有限公司 一种计算机操作系统故障现场信息获取的系统和方法
US8645763B2 (en) * 2011-09-12 2014-02-04 Microsoft Corporation Memory dump with expanded data and user privacy protection
GB2520712A (en) * 2013-11-28 2015-06-03 Ibm Data dump method for a memory in a data processing system
CN103744700A (zh) * 2013-12-23 2014-04-23 乐视致新电子科技（天津）有限公司 一种系统启动方法及电子设备
CN104281506B (zh) * 2014-07-10 2017-02-15 中国科学院计算技术研究所 一种文件系统的数据维护方法及系统
CN104331339B (zh) * 2014-11-20 2017-09-05 惠州Tcl移动通信有限公司 一种移动终端死机检测处理方法、系统及移动终端
US10229017B1 (en) * 2015-10-01 2019-03-12 EMC IP Holding Company LLC Resetting fibre channel devices for failover in high availability backup systems
WO2018076169A1 (zh) * 2016-10-25 2018-05-03 华为技术有限公司 终端设备开机失败的恢复方法和终端设备
CN107861830A (zh) * 2017-12-01 2018-03-30 深圳乐信软件技术有限公司 应用程序崩溃的检测方法、装置、存储介质及移动终端
CN108595330A (zh) * 2018-04-23 2018-09-28 北京潘达互娱科技有限公司 一种应用测试方法及装置
CN109189615A (zh) * 2018-09-04 2019-01-11 郑州云海信息技术有限公司 一种宕机处理方法和装置
CN110609778A (zh) * 2019-08-16 2019-12-24 苏州浪潮智能科技有限公司 一种保存服务器宕机日志的方法及系统
CN112667436A (zh) * 2020-12-22 2021-04-16 北京浪潮数据技术有限公司 一种服务器关机时的自动捕获分析方法、装置、设备及介质

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108984332A (zh) * 2018-06-22 2018-12-11 郑州云海信息技术有限公司 一种定位服务器宕机故障的装置及方法

Also Published As

Publication number Publication date
CN114064132A (zh) 2022-02-18

Similar Documents

Publication Publication Date Title
CN114064132B (zh) 一种系统宕机恢复方法、装置、设备和系统
US6697972B1 (en) Method for monitoring fault of operating system and application program
US9026860B2 (en) Securing crash dump files
US8489932B2 (en) Server system and crash dump collection method
US8601493B2 (en) Application controlling apparatus and storage medium which stores software for the apparatus
US20100162045A1 (en) Method, apparatus and system for restarting an emulated mainframe iop
JP5494298B2 (ja) 計算機装置，障害復旧制御プログラムおよび障害復旧制御方法
WO2016206514A1 (zh) 启动处理方法及装置
CN104809013B (zh) 一种嵌入式系统启动方法和装置
US10983825B2 (en) Processing for multiple containers are deployed on the physical machine
CN111858077A (zh) 一种存储系统中io请求日志的记录方法、装置及设备
CN115658113A (zh) 服务器自启动方法、装置、可读存储介质及电子设备
JP2002259130A (ja) 情報処理システムおよびその起動制御方法
CN112199240B (zh) 一种节点故障时进行节点切换的方法及相关设备
CN115168869A (zh) 基于多操作系统的车载系统及其控制方法
CN109358982B (zh) 硬盘自愈装置、方法以及硬盘
CN116266150A (zh) 一种业务恢复方法、数据处理单元及相关设备
CN115904793B (zh) 一种基于多核异构系统的内存转存方法、系统及芯片
CN115576734B (zh) 一种多核异构日志存储方法和系统
JP2007172096A (ja) 情報処理装置、および、その起動制御方法
CN114138534A (zh) 一种系统挂死故障的恢复和定位方法、装置、设备及存储介质
CN109062718B (zh) 一种服务器及数据处理方法
TWI461905B (zh) 可遠端當機復原的運算裝置、用於運算裝置之遠端當機復原之方法及電腦可讀取媒體
JP4633553B2 (ja) デバッグシステム、デバッグ方法およびプログラム
JP2785992B2 (ja) サーバプログラムの管理処理方式

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant