CN115292082A - Method and system for processing Assert downtime fault in BIOS starting process - Google Patents

Method and system for processing Assert downtime fault in BIOS starting process Download PDF

Info

Publication number
CN115292082A
CN115292082A CN202210992536.0A CN202210992536A CN115292082A CN 115292082 A CN115292082 A CN 115292082A CN 202210992536 A CN202210992536 A CN 202210992536A CN 115292082 A CN115292082 A CN 115292082A
Authority
CN
China
Prior art keywords
sram area
bios
sram
assert
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.)
Pending
Application number
CN202210992536.0A
Other languages
Chinese (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.)
Suzhou Inspur Intelligent Technology Co Ltd
Original Assignee
Suzhou Inspur Intelligent Technology 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 Suzhou Inspur Intelligent Technology Co Ltd filed Critical Suzhou Inspur Intelligent Technology Co Ltd
Priority to CN202210992536.0A priority Critical patent/CN115292082A/en
Publication of CN115292082A publication Critical patent/CN115292082A/en
Pending legal-status Critical Current

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/0766—Error or fault reporting or storing
    • G06F11/0787—Storage of error reports, e.g. persistent data storage, storage using memory protection
    • 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/079—Root cause analysis, i.e. error or fault diagnosis
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The application discloses a method and a system for processing an Assert crash fault in a BIOS starting process, wherein the method comprises the steps of firstly defining an SRAM area for storing BIOS debugging information, wherein the SRAM area is arranged on an independent controller outside a CPU; the BIOS defines the function name of the function to be printed; after the BIOS is started normally, accessing the SRAM area, and sequentially writing function names into the SRAM area; when an Assert downtime fault occurs, the independent controller collects data according to the SRAM area; and processing the Assert downtime fault according to the collected data. The system comprises: the device comprises an SRAM area definition module, a function name definition module, an SRAM area access module, a data collection module and a fault processing module. Through the method and the device, the efficiency of processing the Assert downtime fault can be effectively improved.

Description

Method and system for processing Assert downtime fault in BIOS starting process
Technical Field
The present application relates to the technical field of computer fault processing, and in particular, to a method and System for processing an Assert downtime fault during a BIOS (Basic Input Output System) startup process.
Background
In the BIOS starting process of a computer, assert downtime occurs for some reasons, and how to process Assert downtime fault so as to enable the computer to recover normal operation is an important technical problem.
At present, the method for processing Assert downtime generally prints the file name of the downtime location and the line number of the downtime location, and then locates a probable fault cause according to the file name and the location. When the context information of the function needs to be executed, the environment is built again, and a Debug (troubleshooting) mode is opened to reproduce the problem.
However, in the existing method for processing the Assert downtime, because the fault cause can only be roughly located, the information is too general, and the follow-up needs to be checked one by one according to the context information of the execution function, so that the fault processing efficiency is low. Especially when a general library function is called at the downtime position, it is difficult to determine where the library function is called. Further, when the context information of the execution function is determined, an operation such as setting up an environment is required, and it takes a long time to reproduce the function. Therefore, the current method for processing the Assert downtime has low fault processing efficiency.
Disclosure of Invention
The application provides a method and a system for processing an Assert downtime fault in a BIOS starting process, and aims to solve the problem that the fault processing efficiency is low due to the fact that the method for processing the Assert downtime in the prior art is adopted.
In order to solve the technical problem, the embodiment of the application discloses the following technical scheme:
a method for processing an Assert downtime fault in a BIOS starting process comprises the following steps:
defining an SRAM (Static Random-Access Memory) area for storing BIOS debugging information, wherein the SRAM area is arranged on an independent controller outside a CPU;
the BIOS defines a function name of a function to be printed;
after the BIOS is normally started, accessing an SRAM area, and sequentially writing the function names into the SRAM area;
when an Assert downtime fault occurs, the independent controller collects data according to the SRAM area;
and processing the Assert downtime fault according to the collected data.
Optionally, the method for the BIOS to access the SRAM area includes:
the BIOS accesses the SRAM area through an IO (Input/Output) mode; alternatively, the first and second electrodes may be,
the BIOS accesses the SRAM area by way of a shared memory.
Optionally, the defining an SRAM area for storing BIOS debugging information includes:
defining the size and the initial address of an SRAM area;
defining a data structure in an SRAM area;
data parsing rules for the SRAM regions are defined.
Optionally, after the BIOS is normally started, accessing the SRAM area, and sequentially writing the function names into the SRAM area, where the method includes:
after the BIOS is normally started, when a first function is executed, defining the serial number of the first function as 1, and writing the function name of the first function into a corresponding area;
when the next function is executed, the sequence number is increased by 1, and the function name of the next function is written into the corresponding area;
and when the SRAM area is full, the serial number is continuously increased by 1, and the corresponding function name is written in a covering manner from the initial address of the SRAM area until the BIOS is started.
Optionally, when an Assert down fault occurs, the independent controller collects data according to the SRAM area, including:
when an Assert downtime fault occurs, the independent controller locks the SRAM area according to the acquired overtime alarm information;
reading information in the SRAM area and outputting the information to a maintenance log;
and releasing the SRAM area after completely storing the information in the SRAM area.
Optionally, the independent controller includes and is not limited to: any one of BMC (Baseboard Management Controller), SIO (super input Output, super input Output chip, which provides a control processing function for a standard I/O interface on a motherboard), and EC (embedded Controller).
Optionally, the method is applied to an Intel platform, an X86 platform or an ARM platform supporting UEFI (Unified Extensible Firmware Interface) Firmware.
A system for handling an Assert downtime fault during a BIOS boot process, the system comprising:
the SRAM area definition module is used for defining an SRAM area for storing BIOS debugging information, and the SRAM area is arranged on an independent controller outside the CPU;
the function name definition module is arranged on the BIOS and used for defining the function name of the function to be printed;
the SRAM area access module is arranged on the BIOS and used for accessing the SRAM area after the BIOS is normally started and sequentially writing the function names into the SRAM area;
the data collection module is arranged on the independent controller and used for collecting data according to the SRAM area when the Assert downtime fault occurs;
and the fault processing module is used for processing the Assert downtime fault according to the collected data.
Optionally, the data collection module comprises:
the SRAM area control unit is used for locking the SRAM area according to the acquired overtime alarm information when the Assert downtime fault occurs;
the information reading and outputting unit is used for reading the information in the SRAM area and outputting the information to a maintenance log after the SRAM area is locked;
the SRAM area control unit is also used for releasing the SRAM area after completely storing the information in the SRAM area.
Optionally, the independent controller includes and is not limited to: any one of BMC, SIO and EC.
The technical scheme provided by the embodiment of the application can have the following beneficial effects:
the method comprises the steps of firstly defining an SRAM (static random access memory) area for storing BIOS debugging information, defining function names of functions to be printed by the BIOS, then accessing the SRAM area after the BIOS is normally started and sequentially writing the function names into the SRAM area, carrying out data collection by an independent controller according to the SRAM area when the interrupt crash fault occurs, and finally carrying out fault processing according to the collected data. In the embodiment, the SRAM area is defined, so that BIOS debugging information is recorded on an independent controller outside the CPU, and functions operated by the BIOS in the CPU starting process are recorded, so that a reliable basis is provided for subsequent fault processing, and the interrupt downtime fault processing efficiency is greatly improved. Moreover, in this embodiment, the function name of the function operated by the BIOS is written into the SRAM area, and when fault location is performed, which function is in operation and has a fault can be located according to the context of the currently executed function, so that the range of fault analysis is greatly reduced, accuracy of fault processing is improved, and fault processing efficiency is improved.
In addition, in the embodiment, when the SRAM area is defined, the size, the start address, the data structure, and the data analysis rule of the SRAM area are defined, and this method makes the data storage and the data call have a certain rule, which is beneficial to further improving the data processing efficiency and the reliability of the data storage, and further improving the efficiency of processing the Assert downtime fault.
The method in the embodiment can be applied to the field of servers, and can also be applied to a platform of UEFI firmware architecture: including the industrial control field and the consumer note field. The hardware platform supports both an Intel platform and an X86 platform or an ARM platform based on UEFI firmware. Therefore, the method in the embodiment has strong compatibility and universality and is convenient to popularize.
The present application further provides a system for processing an Assert downtime fault in a BIOS startup process, the system mainly includes: the device comprises an SRAM area definition module, a function name definition module, an SRAM area access module, a data collection module and a fault processing module. Through the SRAM area defining module, an SRAM area can be defined, BIOS debugging information is recorded on an independent controller outside the CPU, functions operated by the BIOS in the starting process of the CPU are recorded, and a reliable basis is provided for follow-up fault processing, so that the efficiency of processing the Assert downtime fault is greatly improved. Through SRAM regional access module, write in the function name of BIOS function in the SRAM region to carry out data collection in the SRAM region through data collection module, when carrying out fault location at last, can be according to the context of the current executive function to fix out specifically which function breaks down in service, thereby reduce the scope of failure analysis greatly, be favorable to improving the accuracy of fault processing, improve fault processing efficiency.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without creative efforts.
Fig. 1 is a schematic flowchart of a method for processing an Assert downtime fault in a BIOS startup process according to an embodiment of the present application;
fig. 2 is a schematic structural diagram of a system for processing an Assert downtime fault in a BIOS boot process according to an embodiment of the present disclosure.
Detailed Description
In order to make those skilled in the art better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
For a better understanding of the present application, embodiments thereof are explained in detail below with reference to the accompanying drawings.
Example one
Referring to fig. 1, fig. 1 is a schematic flowchart of a method for processing an Assert crash fault in a BIOS startup process according to an embodiment of the present application. As shown in fig. 1, the method for processing an Assert downtime fault in a BIOS startup process in this embodiment mainly includes the following steps:
s1: and defining an SRAM area for storing BIOS debugging information, wherein the SRAM area is arranged on an independent controller outside the CPU.
The independent controller for providing the storage information in this embodiment is independent of the CPU and does not rely on the internal storage of the CPU. The independent controller providing the SRAM area includes, but is not limited to, any one of BMC, SIO, and EC. If the server is adopted, the independent controller can adopt BMC; if the method is applied to the industrial control field, the independent controller can adopt SIO; if applied to the note art, the independent controller may employ an EC.
Specifically, step S1 includes the following processes:
s11: the size and starting address of the SRAM area are defined.
S12: data structures within the SRAM regions are defined.
S13: data parsing rules for the SRAM regions are defined.
Taking an independent controller BMC adopted in the server field as an example, the BIOS and the BMC negotiate a region SRAM for storing debug information of the BIOS, and the size of the region of the SRAM may be conditioned, for example, may be set to 1KB. The BMC provides a continuous SRAM area, determines the starting address of the SRAM area, and can write related data into the subsequent BIOS according to the starting address.
With continued reference to fig. 1, after the SRAM area is defined, step S2 is executed: the BIOS defines the function name of the function to be printed. The function to be printed in this embodiment is a function that the BIOS runs during the boot process of the CPU.
The data written by the BIOS according to the start address comprises two parts: sequence number and function name. The sequence number is used for indicating the execution sequence of the function, and the function name is used for indicating the function name of the function operated by the BIOS. According to steps S11 to S33, the SRAM data format in the present embodiment can be set as follows: the sequence number occupies 4 bytes, the function name occupies 46 bytes, and a set of valid data is 50 bytes.
S3: and after the BIOS is normally started, accessing the SRAM area, and sequentially writing the function names into the SRAM area.
The method for accessing the SRAM area by the BIOS in this embodiment may be implemented by an IO method, or by a method of sharing a memory. Specifically, step S3 includes the following processes:
s31: after the BIOS is normally started, when the BIOS executes the first function, the serial number of the BIOS is defined to be 1, and the function name of the first function is written into the corresponding area.
S32: and when the next function is executed, increasing the sequence number by 1, and writing the function name of the next function into the corresponding area.
S33: and after the SRAM area is fully written, the serial number is continuously increased by 1, and the corresponding function name is written in a covering manner from the initial address of the SRAM area until the BIOS is started.
According to the steps S31-S33, taking the example that the BIOS accesses the SRAM area in the IO mode, after the BIOS is started, the IO port is initialized firstly, then the BIOS interacts with the BMC in the IO mode, when a certain function body is executed, a sequence number is written firstly, the sequence number is defaulted to start from 1, and then the function name is written into the corresponding area; when the second function is executed, the serial number is added with 1 and then written in, and then the corresponding function name is written in; after the serial numbers are sequentially written to full, the serial numbers are continuously and automatically added with 1, and the writing is covered from the initial address of the SRAM area until the BIOS finishes one-time starting.
S4: and when the Assert downtime fault occurs, the independent controller collects data according to the SRAM area.
Specifically, step S4 includes the following processes:
s41: and when the Assert downtime fault occurs, the independent controller locks the SRAM area according to the acquired overtime alarm information.
The watchdog in the independent controller is usually set, when the Assert downtime fault occurs, the watchdog in the independent controller can trigger overtime alarm because the watchdog cannot be processed, and at the moment, the independent controller can lock the SRAM according to the acquired overtime alarm information, so that the misoperation of the CPU is avoided. At this time, since the SRAM area is locked, the SRAM area cannot be operated even if the CPU restarts.
S42: and reading the information in the SRAM area and outputting the information to a maintenance log.
After the SRAM area is locked, the independent controller starts to read the information in the SRAM area and outputs the information to the maintenance log.
S43: and releasing the SRAM area after completely storing the information in the SRAM area.
After releasing the SRAM area, the CPU can operate the SRAM area.
As can be seen from the foregoing steps S41 to S43, taking the independent controller as an example, when an Assert down occurs, the BMC does not sense the assertion, the CPU does not execute the code at this time, the watchdog of the BMC may trigger an timeout alarm because the watchdog cannot be processed, and after sensing that the watchdog is out of time, the BMC reads the relevant information in the SRAM area, outputs the relevant information to the maintenance log, and then performs a system restart operation. By the method, a user or a research and development personnel can know which function has the Assert down by checking the maintenance log, so that analysis work can be quickly carried out, and the fault processing efficiency is improved.
With continued reference to fig. 1, after the independent controller collects data according to the SRAM area, step S5 is performed: and processing the Assert downtime fault according to the collected data.
The method in the embodiment is not only used for the Intel platform, but also supports an X86 platform or an ARM platform adopting UEFI firmware, has a wide application range and is convenient to popularize and use.
Example two
Referring to fig. 2 on the basis of the embodiment shown in fig. 1, fig. 2 is a schematic structural diagram of a system for processing an Assert downtime failure during a BIOS startup process according to the embodiment of the present application. As shown in fig. 2, the system for processing an Assert downtime fault in a BIOS startup process in this embodiment mainly includes: the device comprises an SRAM area definition module, a function name definition module, an SRAM area access module, a data collection module and a fault processing module.
The SRAM area definition module is used for defining an SRAM area for storing BIOS debugging information, and the SRAM area is arranged on an independent controller outside the CPU; the function name definition module is arranged on the BIOS and used for defining the function name of the function to be printed; the SRAM area access module is arranged on the BIOS and used for accessing the SRAM area after the BIOS is normally started and sequentially writing function names into the SRAM area; the data collection module is arranged on the independent controller and used for collecting data according to the SRAM area when the Assert downtime fault occurs; and the fault processing module is used for processing the Assert downtime fault according to the collected data.
Further, the data collection module includes: an SRAM area control unit and an information reading and outputting unit. The SRAM area control unit is used for locking an SRAM area according to the obtained overtime alarm information when an Assert downtime fault occurs; the information reading and outputting unit is used for reading the information in the SRAM area and outputting the information to the maintenance log after the SRAM area is locked; and the SRAM area control unit is also used for releasing the SRAM area after completely storing the information in the SRAM area.
The independent controller in this embodiment includes, but is not limited to, any one of BMC, SIO, and EC. In particular according to different fields of application.
The working principle and the working method of the system for processing the Assert downtime fault in the BIOS starting process in this embodiment have been explained in detail in the embodiment shown in fig. 1, and the two embodiments may be referred to each other, which is not described herein again.
The previous description is only an example of the present application, and is provided to enable any person skilled in the art to understand or implement the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (10)

1. A method for processing an Assert downtime fault in a BIOS starting process is characterized by comprising the following steps:
defining an SRAM area for storing BIOS debugging information, wherein the SRAM area is arranged on an independent controller outside a CPU;
the BIOS defines the function name of the function to be printed;
after the BIOS is normally started, accessing an SRAM area, and sequentially writing the function names into the SRAM area;
when an Assert downtime fault occurs, the independent controller collects data according to the SRAM area;
and processing the Assert downtime fault according to the collected data.
2. The method of claim 1, wherein the method for the BIOS to access the SRAM area comprises:
the BIOS accesses the SRAM area through an IO mode; alternatively, the first and second electrodes may be,
the BIOS accesses the SRAM area by way of a shared memory.
3. The method according to claim 1, wherein the defining an SRAM area for storing BIOS debug information comprises:
defining the size and the initial address of an SRAM area;
defining a data structure in an SRAM area;
data parsing rules for the SRAM regions are defined.
4. The method according to claim 3, wherein after the BIOS is normally started, accessing an SRAM area and sequentially writing the function names into the SRAM area includes:
after the BIOS is normally started, when a first function is executed, defining the serial number of the first function as 1, and writing the function name of the first function into a corresponding area;
when the next function is executed, the sequence number is increased by 1, and the function name of the next function is written into the corresponding area;
and when the SRAM area is full, the serial number is continuously increased by 1, and the corresponding function name is written in a covering manner from the initial address of the SRAM area until the BIOS is started.
5. The method according to claim 1, wherein when the Assert downtime fault occurs, the independent controller collects data according to the SRAM area, and the method includes:
when an Assert downtime fault occurs, the independent controller locks the SRAM area according to the obtained overtime alarm information;
reading information in the SRAM area and outputting the information to a maintenance log;
and releasing the SRAM area after completely storing the information in the SRAM area.
6. The method of claim 1, wherein the independent controller includes, but is not limited to: any one of BMC, SIO and EC.
7. The method of claim 1, wherein the method is applied to an Intel platform, an X86 platform or an ARM platform supporting UEFI firmware.
8. A system for processing an Assert downtime fault in a BIOS starting process, the system comprising:
the SRAM area definition module is used for defining an SRAM area for storing BIOS debugging information, and the SRAM area is arranged on an independent controller outside the CPU;
the function name definition module is arranged on the BIOS and used for defining the function name of the function to be printed;
the SRAM area access module is arranged on the BIOS and used for accessing the SRAM area after the BIOS is normally started and sequentially writing the function names into the SRAM area;
the data collection module is arranged on the independent controller and is used for collecting data according to the SRAM area when an Assert downtime fault occurs;
and the fault processing module is used for processing the Assert downtime fault according to the collected data.
9. The system according to claim 8, wherein the data collection module comprises:
the SRAM area control unit is used for locking the SRAM area according to the acquired overtime alarm information when the Assert downtime fault occurs;
the information reading and outputting unit is used for reading the information in the SRAM area and outputting the information to a maintenance log after the SRAM area is locked;
the SRAM area control unit is also used for releasing the SRAM area after completely storing the information in the SRAM area.
10. The system according to claim 8 or 9, wherein the independent controller includes but is not limited to: any one of BMC, SIO and EC.
CN202210992536.0A 2022-08-18 2022-08-18 Method and system for processing Assert downtime fault in BIOS starting process Pending CN115292082A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210992536.0A CN115292082A (en) 2022-08-18 2022-08-18 Method and system for processing Assert downtime fault in BIOS starting process

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210992536.0A CN115292082A (en) 2022-08-18 2022-08-18 Method and system for processing Assert downtime fault in BIOS starting process

Publications (1)

Publication Number Publication Date
CN115292082A true CN115292082A (en) 2022-11-04

Family

ID=83830626

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210992536.0A Pending CN115292082A (en) 2022-08-18 2022-08-18 Method and system for processing Assert downtime fault in BIOS starting process

Country Status (1)

Country Link
CN (1) CN115292082A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117873771A (en) * 2024-03-11 2024-04-12 浪潮计算机科技有限公司 System downtime processing method, device, equipment, storage medium and server

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117873771A (en) * 2024-03-11 2024-04-12 浪潮计算机科技有限公司 System downtime processing method, device, equipment, storage medium and server
CN117873771B (en) * 2024-03-11 2024-06-07 浪潮计算机科技有限公司 System downtime processing method, device, equipment, storage medium and server

Similar Documents

Publication Publication Date Title
CN111767184A (en) Fault diagnosis method and device, electronic equipment and storage medium
US6880113B2 (en) Conditional hardware scan dump data capture
US7712084B2 (en) Method for monitoring a program execution using a debug logic
US6502208B1 (en) Method and system for check stop error handling
US7900090B2 (en) Systems and methods for memory retention across resets
US20030070115A1 (en) Logging and retrieving pre-boot error information
US11604711B2 (en) Error recovery method and apparatus
US20030126516A1 (en) Scalable CPU error recorder
US6725396B2 (en) Identifying field replaceable units responsible for faults detected with processor timeouts utilizing IPL boot progress indicator status
CN115292082A (en) Method and system for processing Assert downtime fault in BIOS starting process
US20020073359A1 (en) System and method for high priority machine check analysis
US11226755B1 (en) Core dump in a storage device
CN115827298A (en) Server startup fault positioning method and device, terminal and storage medium
CN115421960A (en) UE memory fault recovery method, device, electronic equipment and medium
WO2021202431A1 (en) Targeted repair of hardware components in a computing device
US20010049794A1 (en) Write protection software for programmable chip
JP2015130023A (en) Information recording device, information processor, information recording method and information recording program
US11900150B2 (en) Methods and systems for collection of system management interrupt data
CN116932334B (en) Abnormal reset monitoring method and device for multi-core micro control unit
CN116893928A (en) Supervision method, system, terminal and storage medium for fault memory
CN114416413A (en) Serial port storage system and method for operating system crash
CN117075977A (en) Method and device for starting processor, electronic equipment and storage medium
CN117215854A (en) Method, system, equipment and storage medium for testing AMT (automated mechanical transmission) of server
CN116741254A (en) Data storage method, device, equipment and medium
CN117632564A (en) Global health management method and system based on container and object model operating system

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