操作系统发生核心崩溃情况下读取完整核心日志的方法

摘要

本发明是一种操作系统发生核心崩溃情况下读取完整核心日志的方法，该方法应用于一终端装置上，该终端装置包括一中央处理单元及一存储器单元，该存储器单元与中央处理单元相电气连接，且至少包括一核心运作区、一核心缓冲区、一日志备份区及一用户数据区，其中核心运作区内储存有一系统核心，该中央处理单元能藉由系统核心执行一操作系统，且产生一核心日志，并将该核心日志分别储存至该核心缓冲区及该日志备份区中，当该中央处理单元被复位重置时，其会执行一核心模块初始化程序，并将日志备份区中的核心日志，导出储存至用户数据区。如此，由于该日志备份区自存储器单元中额外开辟，故不会受核心崩溃影响而毁损。

说明书

技术领域

本发明有关于在操作系统发生核心崩溃后，读取核心日志的方法，尤指一种中 央处理单元被进行复位重置后，即能完整导出核心日志的方法。

背景技术

由于Linux具有自由软件（Free Software）与开放原始码（Open Source）等特 性，意即，只要使用者或企业是遵循GNU通用公众授权条款（GNU General Public  License，简称GNU GPL或GPL）的内容，便能够自由地使用Linux核心（或称为 Linux内核）的所有底层原始码，亦能够自由地修改系统软件与再发布修改后的系 统软件。由于Linux能供使用者（企业或个人）自由地对其进行最大程度的定制， 因此，Linux能成为各种开放或封闭式系统的平台，且应用于中间件（Middleware） 或嵌入式系统（Embedded system）上，故，目前有众多电子产品（如：电脑、智 慧型手机、导航系统）的系统软件是采用Linux核心所开发设计完成，例如Android  系统即为其一代表性作品。

一般言，在Linux核心运行的过程中，若应用程序发生非致命的执行时期错误 （nonfatal runtime errors）时，Linux核心能对前述的错误情况予以处理，且允许应 用程序执行完毕后，再产生错误结果讯息，但当发生硬件错误（如：irq conflict、 bad block、high temperature），或是应用程序发生除零（Divide By Zero）、存储器访 问越界（Access Denied）、缓冲区溢位（Buffer Overflow）等不可恢复的错误（或 称，致命错误（fatal error））时，则可能会造成核心崩溃（KERNEL PANIC），令 Linux核心无法正常运行，进而发生当机情况。因此，使用者通常需读取核心日志 的内容，以能了解核心崩溃的发生原因，进而顺利解决问题。所谓的“核心日志” 是指，Linux核心于运行时，其会记录系统的执行过程资讯，并将这些执行过程资 讯保存在一个内部缓冲区中，记录内容大抵包括：事件发生的日期与时间、发生此 事件的主机名称或来源IP、启动此事件的服务名称或函式名称、该讯息的实际数 据内容…等，以供使用者能藉由“核心日志”的内容，得知终端装置的各个软、硬 件的工作状态。

承上所述，在未发生核心崩溃的情况下，使用者能使用“cat/proc/kmsg”命令 输出核心日志，以查看Linux核心的运行状况。但若系统发生核心崩溃的情况时， 则可能造成前述“cat/proc/kmsg”命令无法输出完整的核心日志，令使用者无法正 确地判断出发生核心崩溃的原因。因此，针对核心崩溃的情况，Linux核心本身提 供了panic机制与kdump机制，兹就前述两种机制简单说明如下：

（1）panic机制：当核心崩溃的情况发生时，由于Linux核心不知目前的程序 该如何执行下一步骤，因此，其会将此时所能获取到的所有资讯显示出来，但实际 上，显示内容多寡会因造成核心崩溃的各种原因有所差异。举例而言，当核心崩溃 的类型是hard panic，使用者能使用“/var/log/messages”命令取得堆迭追踪（stack  trace）讯息；又，使用者尚能搜索应用程序日志，以取得各个应用程序的运作过程； 最后，使用者能自行记录终端装置的屏幕上所显示的dump资讯。另，当核心崩溃 的类型是soft panic，Linux核心会产生一个包含核心符号（kernel symbols）数据的 dump资讯，该dump资讯会记录于/var/log/messages中，又，使用者能透过ksymoops 工具生成ksymoops档案，以将核心符号数据转换成可供判读的数据。

（2）kdump机制（即，核心崩溃转储机制）：当核心崩溃的情况发生时，会启 动kexec程序，将操作系统的当前核心（即，发生核心崩溃的核心，后续称前一个 核心）引导至另一个备份核心。此时，前一个核心运行时的存储器镜像内容，会被 保存至/proc/vmcore中，使用者能透过“cp”命令或“scp”命令，将vmcore档复 制至磁片上，并在重启操作系统后，透过分析工具对vmcore档进行分析，查找出 导致前一个核心发生核心崩溃的原因。

综上所述可知，无论是panic机制或kdump机制，均需先行对Linux核心进行 相关设定，且使用者亦需额外下达多个命令，才能取得核心日志，造成使用上的不 便利性。因此，如何设计出一种更为方便的输出核心日志的方法，令使用者不需对 系统核心进行繁复的额外设定，即成为相关业者的重要课题。

发明内容

有鉴于现有输出核心日志的方法，均需对系统核心进行相关设定，造成使用上 的困扰，尤其对于一些经验不足的使用者而言，更是有着极大的不便性，因此，发 明人经过长久努力研究与实验，终于开发设计出本发明的一种操作系统发生核心崩 溃情况下读取完整核心日志的方法，以期藉由本发明而能提供使用者一种更为方便 输出核心日志的方法，大幅提高使用上的便利性。

本发明的一个目的在于提供一种操作系统发生核心崩溃情况下读取完整核心 日志的方法，主要能降低输出核心日志的复杂度，且能保持核心日志的完整性，以 便于使用者能在操作系统的核心崩溃（KERNEL PANIC）后，藉由阅读核心日志 的内容而迅速地解决问题。该方法应用于一终端装置（如：电脑、智慧型手机）上， 该终端装置包括一中央处理单元及一存储器单元，该存储器单元系与该中央处理单 元相电气连接，且至少包括一核心运作区、一核心缓冲区、一日志备份区及一用户 数据区，其中该核心运作区内储存有一系统核心（System Kernel），该方法能使中 央处理单元藉由系统核心执行一操作系统，以驱动该终端装置上的其它硬件；然后， 在中央处理单元执行该操作系统的状态下，会针对执行过程的资讯，产生一核心日 志，并将该核心日志分别储存至该核心缓冲区及该日志备份区中，当该中央处理单 元被复位重置后，其会执行一核心模块（Kernel Object）初始化程序，并将该核心 日志输出至该用户数据区，该核心日志包括该中央处理单元被复位重置之前，运行 该系统核心的完整资讯。如此，使用者仅需对中央处理单元进行复位重置（如：透 过中央处理单元的重置脚位（Reset Pin）进行硬件重置），便能够将该核心日志导 出至该用户数据区，以便使用者能藉由分析该核心日志的内容，得知发生核心崩溃 的原因。

为便于对本发明目的、技术特征及其功效，做更进一步的认识与了解，兹举实 施例配合附图，详细说明如下：

附图说明

图1是本发明的终端装置的硬件方块图；

图2是本发明的存储器单元的分区示意图；

图3是本发明的日志备份区的示意图；

图4是本发明的核心模块初始化程序的脚本内容；及

图5是本发明的中央处理单元读取核心日志的流程图。

主要元件符号说明

终端装置          ……        1

中央处理单元      ……        10

存储器单元        ……        12

核心运作区        ……        121

系统核心          ……        122

核心缓冲区        ……        123

日志备份区        ……        125

数据读写标记区    ……        1251

数据起始区        ……        1253

数据结束区        ……        1255

实际数据区        ……        1257

用户数据区        ……        127

具体实施方式

本发明是一种操作系统发生核心崩溃情况下读取完整核心日志的方法，在一较 佳实施例中，请参阅图1所示，一终端装置1包括一中央处理单元10及一存储器 单元12，其中该终端装置1能够为个人电脑（Personal Computer，简称PC）、笔记 本型电脑（Notebook，简称NB）、智慧型手机（Smartphone）、导航装置（navigation  device）、平板电脑（Tablet computer）或个人数位处理器（Personal DigitalAssistant， 简称PDA）等。另，请参阅图1及2所示，该存储器单元12能够为一快闪存储器 （Flash Memory），并与该中央处理单元10相电气连接，以能接收该中央处理单元 10传来的数据，且能传送其内储存的数据至该中央处理单元10。该存储器单元12 至少包括一核心运作区121、一核心缓冲区123、一日志备份区125及一用户数据 区127（UserData）。

在此特别一提者，不同的操作系统（如：UNIX系统、Linux系统、FreeBSD 系统）运用至不同的终端装置时，会依实际需求规划不同的分区。以智慧型手机搭 配Android系统为例，依目前Android系统而言，其大致会划分为下列各个分区：

（1）hboot分区：主要作用为引导启动终端装置，以能检测终端装置1的硬件 讯息，并寻找操作系统所规划的各个分区；

（2）radio分区：主要作用为驱动通信硬件，以使终端装置能进行通信作业（如： 拨打电话、发送简讯）；

（3）recovery分区：主要为储存恢复操作系统所需的备份数据；

（4）boot分区：主要为系统核心的储存位置；

（5）system分区：主要为内建程序的储存位置；

（6）cache分区：主要为系统缓存区；

（7）userdata分区：主要用以储存使用者数据，

因此，复请参阅图1及2所示，本发明所述的各个分区，乃是使用上位名词叙 述各个分区的作用，其中核心运作区121、核心缓冲区123及用户数据区127，均 为已知分区，例如：核心运作区121能为hboot分区、recovery分区、boot分区与 system分区的统称，核心缓冲区123为cache分区，用户数据区127则为userdata 分区。其中核心运作区121主要是指系统核心正常运作时所需使用的多个分区，至 于核心缓冲区123与用户数据区127则是因本发明的方法中，需对该二分区123、 127进行另外步骤，故才未划分至核心运作区121中，合先说明。另，本发明的日 志备份区125并非是已知分区，而是在存储器单元12中额外开辟一专用内存区域， 因此，当操作系统发生核心崩溃（KERNEL PANIC）时，日志备份区125不会受 到核心崩溃影响而毁损。

复请参阅图1及2所示，其中该核心运作区121内储存有系统核心122（System  Kernel），该中央处理单元10能藉由该系统核心122执行一操作系统，以驱动该终 端装置1上的其它硬件（如：光碟机、显示卡、蓝牙模块…等），在中央处理单元 10执行该操作系统的状态下，其会针对执行过程的资讯，产生一核心日志，又， 该中央处理单元10会如同已知作法般，将核心日志储存至该核心缓冲区123中， 因此，若在Linux系统中，使用者便能使用“cat/proc/kmsg”命令，自核心缓冲区 123输出核心日志，以查看Linux核心的运行状况。此外，本发明的中央处理单元 10，尚会将核心日志储存至额外开辟的日志备份区125中，意即，本发明的核心日 志会同时存在于核心缓冲区123与日志备份区125中。

另，请参阅图1及3所示，该日志备份区125中包括一数据读写标记区1251、 一数据起始区1253、一数据结束区1255及一实际数据区1257，其中该数据读写标 记区1251设有一状态指标，该状态指标至少包括三种状态，第一是写入状态，第 二是读取状态，第三则是未知状态。所谓的未知状态是针对写入状态、读取状态而 言，在该实施例中，当状态指标的数值为“0xbeefbeef”代表写入状态，当状态指 标的数值为“0xfaceface”则代表读取状态，至于不属于前述数值者，便归属于未 知状态。当终端装置1第一次开机、或是经正常关机程序后再开机时，该状态指标 均会为未知状态，且中央处理单元10能依操作系统的使用需求，将状态指标设定 为写入状态或读取状态；当状态指标为写入状态时，中央处理单元10能将核心日 志写入至该实际数据区1257，且该核心日志在该实际数据区1257中的起始位置， 会被记露于数据起始区1253中，以形成一起始位置数值，又，该核心日志在该实 际数据区1257中的结束位置，则会被记露于数据结束区1255中，以形成一结束位 置数值；当状态指标为读取状态时，中央处理单元10仅能自该实际数据区1257 中读取出核心日志，且其会依起始位置数值及结束位置数值，自实际数据区1257 中读取符合这些位置数值的核心日志内容。

再者，复请参阅图1~3所示，当使用者第一次开启终端装置1时，或者是将正 常关机的终端装置1开启时，中央处理单元10会执行一核心模块（Kernel Object） 初始化程序程序，并读取状态指标，当其判断出该状态指标为未知状态后，会将状 态指标设定为写入状态，以能在后续执行操作系统时，于该实际数据区1257中写 入核心日志。当操作系统发生核心崩溃（KERNEL PANIC）时，使用者能对中央 处理单元10采用硬件重置（hard reset）的方式，即将中央处理单元10的重置脚（reset  PIN）短路，此时，该中央处理单元10会执行该核心模块初始化程序，并读取状 态指标，当其判断出该状态指标为写入状态后，即代表操作系统未经过正常关机程 序，状态指标才并非为未知状态。因此，中央处理单元10会将该状态指标设定为 读取状态，且自数据起始区1253与数据结束区1255中，读取起始位置数值与结束 位置数值，然后，该中央处理单元10便会根据起始位置数值与结束位置数值，自 实际数据区1257中读取出核心日志，并储存至用户数据区127，之后，中央处理 单元10会重新将状态指标设定为写入状态，以便后续执行操作系统时，能于日志 备份区125中写入核心日志。另，假设当中央处理单元10将该状态指标设定为读 取状态，但尚未完整读取出核心日志时，又再次发生核心崩溃，则中央处理单元 10经过硬件重置后，同样会再次执行该核心模块初始化程序。又，当其判断出该 状态指标为读取状态后，其会直接根据起始位置数值与结束位置数值，自实际数据 区1257中读取出核心日志，且在其将核心日志储存到用户数据区127后，会将状 态指标设定为写入状态。

请参阅图1~4所示，其中图4为本发明的核心模块初始化程序的部份脚本内容 与中文注解，其中“printk2glog.ko”为核心模块初始化程序的名称，但业者亦可依 自身需求更改该名称。另，“0x100000”为日志备份区125的容量大小， “0x2FE00000”则表示日志备份区125的起始地址，在该实施例中日志备份区125 的容量为1M位元（Byte），可随着微电子技术的精进，导致存储器单元12容量大 增的情况下，业者亦能够提高日志备份区125的容量。“glog.txt”为核心日志的名 称，在该实施例中，中央处理单元10会以每次读取4K位元的容量大小，依序读 取出实际数据区1257的核心日志的内容，至于最后生成的核心日志（即，glog.txt） 的大小，便是依起始位置数值及结束位置数值而定。在此声明者，由于本发明的日 志备份区125的容量大小为1M位元，若操作系统写入的核心日志容量超过1M位 元时，则最后写入的核心日志内容，会覆盖最早写入的核心日志内容，意即，起始 位置数值会等于结束位置数值+1，如此，即可避免起始位置数值等于结束位置数 值，造成中央处理单元10所输出的核心日志内容不正确。

承上所述，为能明确揭露前述的较佳实施例的整体方法，以下兹仅就本发明的 中央处理单元10执行核心模块初始化程序的主要处理流程，进行说明，请参阅图 1~3及5所示：

（301）执行核心模块初始化程序，进入步骤（302）；

（302）读取状态指标，进入步骤（303）；

（303）判断状态指标是否为未知状态，若是，进入步骤（304），若否，进入 步骤（305）；

（304）设定状态指标为写入状态，并针对执行操作系统过程的资讯，产生核 心日志，且将该核心日志分别储存至核心缓冲区123及日志备份区125中；

（305）判断状态指标是否为写入状态，若是，进入步骤（306），若否，进入 步骤（307）；

（306）设定状态指标为读取状态，进入步骤（307）；及

（307）读取日志备份区125中的核心日志，并将该核心日志储存至用户数据 区127，进入步骤（304）。

综上所述可知，复请参阅图1~3所示，当中央处理单元10被硬件重置后，此 时，状态指标不会恢复成未知状态，因此，中央处理单元10会自动地将日志备份 区125的核心日志，储存至用户数据区127中，故，使用者仅需自用户数据区127 中输出核心日志，便能够查阅中央处理单元10被硬件重置之前，操作系统的运作 情况，得知发生核心崩溃的原因。而不会如同已知方式（如：panic机制与kdump 机制）般，需透过复杂设定才能取得核心日志。另，诚如前述，由于本发明的日志 备份区125是在存储器单元12中额外开辟设置，并非是原有操作系统（如：Linux 系统）的已知分区，因此，在操作系统发生核心崩溃时，不会影响到日志备份区 125，故能保证核心日志的完整性。

再者，复请参阅图1~3所示，虽然前述实施例中，是以中央处理单元10被硬 件重置为例，但在其它实施例中，业者能够在操作系统上安装一监控程序（如： watchdog），当该监控程序发现操作系统出现异常时，其能传送一复位信号至中央 处理单元10，该中央处理单元10在接收到该复位信号后，便会执行前述步骤（301） ~（307）。故可知，无论是使用者直接对中央处理单元10进行硬件重置，或者是监 控程序对中央处理单元10传送复位信号，皆代表中央处理单元10被复位重置的情 况。因此，只要中央处理单元10被复位重置后，会执行执行核心模块初始化程序， 并由额外开辟设置的日志备份区125读取出核心日志，再将该核心日志储存至用户 数据区127，即应属本发明所述及的方法。

在此特别一提者，本发明的实施例所用语汇仅供叙述之用，不应视为本发明的 限制，熟悉本发明相关技术之人士当能在掌握本发明的主要技术特征后，自行利用 其他近似结构、装置及系统加以实现，从而达成本发明的目的，因此，本发明所主 张的权利范围，并不局限于此，凡熟悉该技术领域人士，依据本发明所揭示的技术 内容，可轻易思及的等效变化，均应属不脱离本发明的保护范畴，再者，虽然本发 明的实施例与附图中，乃绘制了分区格式内容与脚本内容，但仅为方便说明，并得 以供一般大众或本技术领域的从业人员，迅速领略本发明揭示内容的本质与要旨， 而并非仅限定为上述的记载内容或方式。