Fault processing method and device, and electronic device

Abstract

This disclosure provides a fault handling method, apparatus, and electronic device. The method includes: in response to the electronic device starting up, a unified and scalable firmware interface obtains a first fault file based on a fault file path; the first fault file includes at least a log file generated when the electronic device host fails; the unified and scalable firmware interface encrypts the first fault file and transmits the encrypted first fault file to a baseboard management controller; the baseboard management controller outputs the first fault file.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a fault handling method, apparatus and electronic device. Background Technology

[0002] The Baseboard Management Controller (BMC) is a key component for remote management and monitoring of servers. Fault files generated after a system failure in the electronic device host are crucial for fault analysis. Currently, the BMC lacks the capability to obtain these fault files; technicians must collect them on-site for in-depth analysis by the manufacturer. However, if the electronic device host system cannot boot, this collection process becomes extremely difficult or even impossible. Furthermore, the fault files lack protection, are easily lost or damaged, hindering rapid fault analysis and resolution, and failing to meet the actual needs of electronic device maintenance. Summary of the Invention

[0003] This disclosure provides a fault handling method, apparatus, and electronic device to at least solve the above-mentioned technical problems existing in the prior art.

[0004] According to a first aspect of this disclosure, a fault handling method is provided, comprising: In response to the startup of the electronic device, the Unified Extensible Firmware Interface (UEFI) obtains a first fault file based on the fault file path; the first fault file includes at least a log file generated when the host of the electronic device fails. The unified and extensible firmware interface encrypts the first fault file and transmits the encrypted first fault file to the baseboard management controller. The substrate management controller outputs the first fault file. The method in the above scheme further includes: Enable the function of obtaining fault files through the unified and extensible firmware interface, so that the unified and extensible firmware interface can obtain the first fault file during the startup process of the electronic device.

[0005] In the above scheme, the unified and extensible firmware interface obtains the first fault file based on the fault file path, including one of the following: During the startup process of the electronic device, in response to the activation of the function of obtaining fault files by the unified extensible firmware interface, the unified extensible firmware interface actively obtains the most recently generated fault file through the fault file path. During the operation of the electronic device, in response to the baseboard management controller detecting a host fault in the electronic device, the baseboard management controller sends a retrieval command to the unified extensible firmware interface. The unified extensible firmware interface responds to the retrieval command and retrieves the most recently generated fault file through the fault file path.

[0006] In the above scheme, if the first fault file is a recently generated fault file actively obtained by the Unified Extensible Firmware Interface through the fault file path during the startup process of the electronic device, the method further includes determining whether the first fault file is a fault file to be processed, specifically including: The unified and extensible firmware interface determines the hash value corresponding to the first fault file and sends the hash value corresponding to the first fault file to the baseboard management controller; The baseboard management controller determines the hash value corresponding to the second fault file; the second fault file is a fault file generated when the electronic device host experiences a historical fault. The baseboard management controller compares the hash value corresponding to the first fault file with the hash value corresponding to the second fault file; If the hash value corresponding to the first fault file is the same as the hash value corresponding to the second fault file, then the first fault file is determined to be a processed fault file. If the hash value corresponding to the first fault file is different from the hash value corresponding to the second fault file, then the first fault file is determined to be a fault file to be processed.

[0007] In the above scheme, the unified and extensible firmware interface encrypts the first fault file and transmits the encrypted first fault file to the baseboard management controller, including: In response to the first fault file being a fault file to be processed, the first fault file is encrypted based on a key, and the first fault file encrypted based on the key is transmitted to the baseboard management controller.

[0008] The method in the above scheme further includes: Determine the path of the fault file corresponding to the first fault file; The unified and extensible firmware interface accesses the system partition based on a file access driver, and obtains the first fault file from the system partition based on the fault file path.

[0009] The method in the above scheme further includes: Determine the key to encrypt the first faulty file.

[0010] In the above scheme, the step of outputting the first fault file based on the baseboard management controller includes one of the following: The encrypted first fault file is output based on the baseboard management controller; The first fault file, encrypted using the baseboard management controller and the key, is decrypted, and the first fault file is output based on the baseboard management controller.

[0011] According to a second aspect of this disclosure, a fault handling apparatus is provided, comprising: The first acquisition unit is configured to acquire a first fault file based on a unified extensible firmware interface and a fault file path in response to the startup of the electronic device; the first fault file includes at least a log file generated when the host of the electronic device fails. The transmission unit is used to encrypt the first fault file based on the unified extensible firmware interface, and transmit the encrypted first fault file to the baseboard management controller. The second acquisition unit is used to output the first fault file based on the baseboard management controller.

[0012] According to a third aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the methods of this disclosure.

[0013] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0014] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which: In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts.

[0015] Figure 1 A schematic diagram of a first optional flow of the data processing method provided in this embodiment of the present disclosure is shown; Figure 2 A schematic diagram of a second optional process for the fault handling method provided in this embodiment of the present disclosure is shown; Figure 3A schematic diagram of a third optional process for the fault handling method provided in this embodiment of the present disclosure is shown; Figure 4 A schematic diagram of a fourth optional process for the fault handling method provided in this embodiment of the present disclosure is shown; Figure 5 A schematic diagram of a fifth optional process for the fault handling method provided in this embodiment of the present disclosure is shown; Figure 6 A schematic diagram of a sixth optional process for the fault handling method provided in this embodiment of the present disclosure is shown; Figure 7 A schematic diagram of an optional structure of the fault handling apparatus provided in an embodiment of this disclosure is shown; Figure 8 A schematic diagram of the composition structure of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0016] To make the objectives, features, and advantages of this disclosure more apparent and understandable, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0017] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0018] In the following description, the terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this disclosure described herein can be implemented in an order other than that illustrated or described herein.

[0019] Unless otherwise defined, all technical and scientific terms used in this disclosure have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The terminology used in this disclosure is for the purpose of describing embodiments of this disclosure only and is not intended to be limiting of this disclosure.

[0020] It should be understood that in the various embodiments of this disclosure, the sequence number of each implementation process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this disclosure.

[0021] In related technologies, when an electronic device (such as a server) experiences a system failure, a failure file is generated. Optionally, the failure can be a crash, and the corresponding failure file is a crash file.

[0022] BMC cannot directly obtain fault files. It needs to collect First Failure Data Capture (FFDC) information through technicians and send it to the vendor for preliminary analysis. If the fault is determined to be a system crash, the on-site technicians will collect fault files for further analysis.

[0023] However, if the system fails to boot, the collection of fault files becomes extremely difficult. Furthermore, the process from the system crash of the electronic device to the collection by on-site technicians involves several steps, including mobile FFDC (Fault Data Conversion), sending to the manufacturer, analysis, and technicians commuting to the site, which takes a considerable amount of time. In addition, the collected fault files are not protected, and due to the system crash, there is even a possibility that the fault files cannot be collected at all.

[0024] In view of the deficiencies existing in the related technologies, this disclosure provides a fault handling method to at least solve some or all of the above-mentioned technical problems.

[0025] Figure 1 A schematic diagram of a first alternative flow of the data processing method provided in this disclosure embodiment is shown, and the steps will be described accordingly.

[0026] In step S101, in response to the startup of the electronic device, the Unified Extensible Firmware Interface obtains the first fault file based on the fault file path.

[0027] In some embodiments, in response to the startup of the electronic device, before the system of the electronic device is running, the UEFI obtains a first fault file based on a fault file path, the first fault file being a log file generated when the electronic device host fails; the electronic device host failure may be an electronic device host crash.

[0028] In some embodiments, the UEFI may proactively obtain the first fault file based on the fault file path; or it may respond to an acquisition instruction sent to the UEFI by the BMC and obtain the first fault file based on the acquisition instruction.

[0029] In some embodiments, the fault file path can be the path corresponding to the first fault file, which points to the New Technology File System (NTFS) of the Windows system partition, or it can be the Fourth Extended File System (EXT4) of the Linux system partition. That is, the first fault file is stored in NTFS or EXT4, and the UEFI has the ability to resolve NTFS and / or EXT4, and supports reading files in system partitions such as NTFS or EXT4.

[0030] In step S102, the unified extensible firmware interface encrypts the first fault file and transmits the encrypted first fault file to the baseboard management controller.

[0031] In some embodiments, after the UEFI obtains the first fault file, it encrypts the first fault file based on a key and sends the encrypted first fault file to the BMC to ensure the security of the transmission between the UEFI and the BMC.

[0032] In some embodiments, the key may be pre-agreed between UEFI and BMC.

[0033] In step S103, the substrate management controller outputs the first fault file.

[0034] In some embodiments, after the BMC obtains the encrypted first fault file from the UEFI, it decrypts the encrypted first fault file based on a key and outputs the first fault file.

[0035] In other embodiments, the BMC outputs the encrypted first fault file.

[0036] In specific implementation, the BMC can provide a web interface (Web Interface / Web UI) for users to download the first fault file or the encrypted fault file; or, the BMC can export the first fault file or the encrypted fault file through First Failure Data Capture (FFDC).

[0037] In this way, when the electronic device's host system crashes and fails to boot, UEFI can acquire and encrypt fault files, securely transmitting them to the BMC for user download, eliminating the need for on-site manual collection and significantly shortening the problem localization cycle. Logs are encrypted throughout the process, ensuring user data security while also improving collection efficiency, providing manufacturers with effective data for efficient system failure resolution.

[0038] Figure 2 A second alternative flowchart of the fault handling method provided in this disclosure embodiment is shown, and will be described according to each step.

[0039] Step S201: Enable the function of obtaining fault files through the unified and extensible firmware interface.

[0040] In some embodiments, when the UEFI fault file acquisition function is enabled, the UEFI can proactively acquire the first fault file based on the fault file path during each electronic device startup process.

[0041] In step S202, in response to the startup of the electronic device, the Unified Extensible Firmware Interface actively obtains the most recently generated fault file through the fault file path.

[0042] In some embodiments, when the UEFI fault file acquisition function is enabled, in response to the electronic device startup, the UEFI actively acquires a first fault file through the fault file path. The first fault file is a log file generated during the most recent host failure of the electronic device.

[0043] In step S203, the unified extensible firmware interface encrypts the first fault file and transmits the encrypted first fault file to the baseboard management controller.

[0044] The specific steps of step S203 are the same as those of step S102, and will not be repeated here.

[0045] In step S204, the substrate management controller outputs the first fault file.

[0046] The specific steps of step S204 are the same as those of step S103, and will not be repeated here.

[0047] In this way, during the power-on and operation of electronic devices, UEFI can proactively acquire and encrypt fault files, securely transmitting them to the BMC for user download, eliminating the need for on-site manual collection and significantly shortening the problem localization cycle. Logs are encrypted throughout the process, ensuring user data security while also improving collection efficiency, providing manufacturers with effective data for efficient system fault resolution.

[0048] Figure 3 A third optional flowchart of the fault handling method provided in the embodiments of this disclosure is shown, and the steps will be described accordingly.

[0049] Step S301: Enable the function of obtaining fault files through the unified and extensible firmware interface.

[0050] The specific steps of step S301 are the same as those of step S201, and will not be repeated here.

[0051] In step S302, in response to the startup of the electronic device, the Unified Extensible Firmware Interface actively obtains the most recently generated fault file through the fault file path.

[0052] The specific steps of step S302 are the same as those of step S202, and will not be repeated here.

[0053] Step S303: Determine whether the first fault file is a fault file to be processed.

[0054] In some embodiments, since the UEFI fault file acquisition function is enabled, the UEFI acquires fault files every time the electronic device boots up. These fault files include log files generated during the last host failure of the electronic device, which have not been acquired or processed; they may also include log files generated during the most recent host failure of the electronic device, which have been acquired and processed by the BMC.

[0055] If the first fault file is a file that has already been processed, then the process of UEFI encrypting the first fault file and transmitting it to BMC will increase the boot process of the electronic device and increase the processing burden of BMC. Therefore, UEFI needs to determine whether the first fault file is a fault file to be processed.

[0056] In practice, the UEFI determines the hash value corresponding to the first fault file and sends the hash value to the BMC. The BMC compares the hash values ​​of the first fault file and the second fault file with the hash values ​​of the log files (i.e., the second fault files) generated when the electronic device host experienced historical faults.

[0057] If the hash value of the first fault file is the same as the hash value of the second fault file, it means that the first fault file and the second fault file are the same, and the BMC has already obtained and processed them, so the first fault file is ignored; if the hash value of the first fault file and the hash value of the second fault file are different, it means that the first fault file is a newly generated fault file, and the BMC has not obtained or processed it, so step S304 is executed.

[0058] Step S304: The Unified Extensible Firmware Interface encrypts the first fault file and transmits the encrypted first fault file to the baseboard management controller.

[0059] In some embodiments, in response to the first fault file being a fault file to be processed, the UEFI encrypts the first fault file and transmits it to the BMC. The specific encryption and transmission process is the same as in step S102, and will not be repeated here.

[0060] In step S305, the substrate management controller outputs the first fault file.

[0061] The specific steps of step S305 are the same as those of step S103, and will not be repeated here.

[0062] In this way, during the power-on and operation of electronic devices, UEFI can proactively acquire and encrypt fault files, securely transmit them to the BMC for user download, eliminating the need for on-site manual collection and significantly shortening the problem localization cycle. Logs are encrypted throughout the process, ensuring user data security; simultaneously, hash verification avoids duplicate processing, improving collection efficiency and quickly providing manufacturers with effective data for efficient system fault resolution.

[0063] In some embodiments, if the electronic device host is not faulty, continuously enabling the UEFI fault file acquisition function means that steps S101 to S102, S202 to S203, or S302 to S305 need to be repeated every time the electronic device starts up; this increases the startup time of the electronic device and affects its normal use. Based on this, this disclosure also provides a fault handling method, in which, when the UEFI fault file acquisition function is disabled, the UEFI acquires a first fault file based on an acquisition instruction transmitted by the BMC. The acquisition instruction can be generated when a fault is detected in the electronic device host, or it can be an external instruction received based on the communication interface.

[0064] Figure 4 A fourth optional flowchart of the fault handling method provided in the embodiments of this disclosure is shown, and the steps will be described accordingly.

[0065] Step S401: The baseboard management controller monitors whether there is a host failure in the electronic device.

[0066] In some embodiments, during the operation of an electronic device, in response to the BMC detecting a fatal error or host hang, a host failure is confirmed and an acquisition command is sent to the UEFI.

[0067] In some embodiments, step S401 can be performed when UEFI fault file acquisition is enabled or disabled.

[0068] Step S402: In response to the acquisition command, the Unified Extensible Firmware Interface acquires the first fault file based on the fault file path.

[0069] In some embodiments, in response to the acquisition command, UEFI acquires a first fault file based on the fault file path.

[0070] In some embodiments, log files generated when an electronic device host fails are typically stored in NTFS and / or EXT4. This disclosure provides UEFI with the ability to parse NTFS and / or EXT4 file systems, enabling UEFI to read files in NTFS and / or EXT4.

[0071] In step S403, the UEFI sends the first fault file to the BMC.

[0072] In some embodiments, after obtaining the first fault file, the UEFI directly encrypts the first fault file based on the key and sends the encrypted first fault file to the BMC.

[0073] In other embodiments, the UEFI can determine the hash value of the first fault file and send the hash value of the first fault file to the BMC. The BMC determines whether the first fault file is a fault file to be processed based on the hash values ​​of the second fault file and the first fault file. If the first fault file is a fault file to be processed, it sends an instruction to the UEFI. In response to the instruction, the UEFI encrypts the first fault file based on the key and sends the encrypted first fault file to the BMC.

[0074] In step S404, the substrate management controller outputs the first fault file.

[0075] In some embodiments, after the BMC obtains the encrypted first fault file from the UEFI, it decrypts the encrypted first fault file based on a key and outputs the first fault file.

[0076] In other embodiments, the BMC outputs the encrypted first fault file.

[0077] In this way, when the system crashes or fails to boot, UEFI can acquire and encrypt fault files, and securely transmit them to the BMC for users to download, eliminating the need for on-site manual collection and significantly shortening the problem localization cycle. Logs are encrypted throughout the process to ensure user data security; hash verification avoids duplicate processing, improving collection efficiency and enabling the rapid provision of effective data to manufacturers for efficient system fault resolution.

[0078] Figure 5 A fifth optional flowchart of the fault handling method provided in this disclosure embodiment is shown, and will be described according to each step.

[0079] In some embodiments, before steps S101, S201, S301, and S401, the method further includes step S501: Step S501: Determine the path of the fault file corresponding to the first fault file.

[0080] In some embodiments, the storage location of the first fault file is determined, and the fault file path is determined based on the storage location; the fault file path can be a pre-set path, that is, the log files generated when the electronic device host fails are all stored by the electronic device in the system partition corresponding to the fault file path.

[0081] In some embodiments, the path corresponding to the first fault file accessed by UEFI is set to the fault file path, so that UEFI can obtain the first fault file through the fault file path.

[0082] In some embodiments, UEFI has the ability to resolve NTFS and / or EXT4 file systems, and UEFI can read files in NTFS and / or EXT4. Specifically, the UEFI can access the system partition corresponding to the faulty file path based on a file access driver.

[0083] In this way, by clearly defining the path of the faulty file and giving UEFI the ability to parse NTFS or EXT4, UEFI can directly locate and read the faulty file without relying on the host system or manual intervention, ensuring that logs can still be obtained stably after a failure; pre-configuring the path and access permissions improves the automation, reliability and compatibility of faulty file collection, laying the foundation for subsequent encrypted transmission.

[0084] Figure 6 A sixth optional flowchart of the fault handling method provided in this disclosure embodiment is shown, and the steps will be described accordingly.

[0085] Step S601: Enable the function of obtaining fault files through the unified and extensible firmware interface.

[0086] The specific steps of step S601 are the same as those of step S201, and will not be repeated here.

[0087] Step S602: Determine the path of the fault file corresponding to the first fault file.

[0088] The specific steps of step S602 are the same as those of step S501, and will not be repeated here.

[0089] Step S603: Determine the key for encrypting the first faulty file.

[0090] In some embodiments, a key for encrypting the first fault file is set and sent to UEFI and BMC.

[0091] In step S604, the baseboard management controller determines that there is a host fault in the electronic device.

[0092] In some embodiments, if the BMC detects a fatal error or detects that the electronic device host is suspended, it confirms that there is a host failure in the electronic device and executes step S606.

[0093] Step S605: The Unified Extensible Firmware Interface scans for fault files during the startup process of an electronic device.

[0094] In some embodiments, during the startup process of an electronic device, UEFI scans for fault files through the fault file path. If a fault file is found to exist, step S606 is executed; if no fault file is found to exist, step S605 is repeated.

[0095] Step S606: Determine whether the first fault file is a fault file to be processed.

[0096] The specific steps of step S606 are the same as those of step S303, and will not be repeated here.

[0097] Step S607: The Unified Extensible Firmware Interface encrypts the first fault file and transmits the encrypted first fault file to the baseboard management controller.

[0098] The specific steps of step S607 are the same as those of step S102, and will not be repeated here.

[0099] In step S608, the substrate management controller outputs the first fault file.

[0100] The specific steps of step S608 are the same as those of step S103, and will not be repeated here.

[0101] In this way, when the system crashes or fails to boot, UEFI can acquire and encrypt fault files, and securely transmit them to the BMC for users to download, eliminating the need for on-site manual collection and significantly shortening the problem localization cycle. Logs are encrypted throughout the process to ensure user data security; hash verification avoids duplicate processing, improving collection efficiency and enabling the rapid provision of effective data to manufacturers for efficient system fault resolution.

[0102] Figure 7 A schematic diagram of an optional structure of the fault handling apparatus provided in an embodiment of this disclosure is shown, and the details will be described in terms of each part.

[0103] In some embodiments, the fault handling device includes a first acquisition unit, a transmission unit, and a second acquisition unit.

[0104] The first acquisition unit is configured to acquire a first fault file based on a unified extensible firmware interface and a fault file path in response to the startup of the electronic device; the first fault file includes at least a log file generated when the host of the electronic device fails. The transmission unit is used to encrypt the first fault file based on the unified extensible firmware interface, and transmit the encrypted first fault file to the baseboard management controller. The second acquisition unit is used to output the first fault file based on the baseboard management controller.

[0105] In some embodiments, the fault handling apparatus further includes an enabling unit.

[0106] The enabling unit is used to enable the function of the unified and extensible firmware interface to obtain fault files, so that the unified and extensible firmware interface can obtain the first fault file during the startup process of the electronic device.

[0107] The first acquisition unit is specifically used for one of the following: During the startup process of the electronic device, in response to the activation of the function to obtain fault files through the unified and extensible firmware interface, the most recently generated fault file is actively obtained through the fault file path based on the unified and extensible firmware interface. During the operation of the electronic device, in response to the baseboard management controller detecting a host fault in the electronic device, the baseboard management controller sends a retrieval command to the unified extensible firmware interface, causing the unified extensible firmware interface to respond to the retrieval command and retrieve the most recently generated fault file through the fault file path.

[0108] In some embodiments, if the first fault file is a recently generated fault file actively obtained by the Unified Extensible Firmware Interface through the fault file path during the startup of the electronic device, the transmission unit is specifically used to: determine the hash value corresponding to the first fault file based on the Unified Extensible Firmware Interface, and send the hash value corresponding to the first fault file to the baseboard management controller. The hash value corresponding to the second fault file is determined based on the baseboard management controller; the second fault file is a fault file generated when the electronic device host experiences a historical fault. Based on the comparison of the hash value corresponding to the first fault file and the hash value corresponding to the second fault file by the baseboard management controller; If the hash value corresponding to the first fault file is the same as the hash value corresponding to the second fault file, then the first fault file is determined to be a processed fault file. If the hash value corresponding to the first fault file is different from the hash value corresponding to the second fault file, then the first fault file is determined to be a fault file to be processed.

[0109] The transmission unit is specifically configured to, in response to the first fault file being a fault file to be processed, encrypt the first fault file based on a key, and transmit the first fault file encrypted based on the key to the baseboard management controller.

[0110] The enabling unit is further configured to determine the fault file path corresponding to the first fault file; The unified and extensible firmware interface accesses the system partition based on a file access driver, and obtains the first fault file from the system partition based on the fault file path.

[0111] The enabling unit is also used to determine the key for encrypting the first fault file.

[0112] The second acquisition unit is used for one of the following: The encrypted first fault file is output based on the baseboard management controller; The first fault file, encrypted using the baseboard management controller and the key, is decrypted, and the first fault file is output based on the baseboard management controller.

[0113] According to embodiments of this disclosure, this disclosure also provides an electronic device and a readable storage medium.

[0114] Figure 8 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0115] like Figure 8 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the electronic device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0116] Multiple components in electronic device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of displays, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows electronic device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0117] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as fault handling methods. For example, in some embodiments, the fault handling method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the fault handling method described above may be performed. Alternatively, in other embodiments, the computing unit 801 may be configured to perform fault handling methods by any other suitable means (e.g., by means of firmware).

[0118] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0119] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0120] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0121] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0122] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0123] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0124] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0125] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means two or more, unless otherwise explicitly specified.

[0126] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A fault handling method, the method comprising: In response to the startup of an electronic device, the Unified Extensible Firmware Interface retrieves the first fault file based on the fault file path; The first fault file includes at least a log file generated when the electronic device host fails; The unified and extensible firmware interface encrypts the first fault file and transmits the encrypted first fault file to the baseboard management controller. The baseboard management controller outputs the first fault file.

2. The method according to claim 1, further comprising: Enable the function of obtaining fault files through the unified and extensible firmware interface, so that the unified and extensible firmware interface can obtain the first fault file during the startup process of the electronic device.

3. The method according to claim 1 or 2, wherein the unified extensible firmware interface obtains the first fault file based on the fault file path, including one of the following: During the startup process of the electronic device, in response to the activation of the function of obtaining fault files by the unified extensible firmware interface, the unified extensible firmware interface actively obtains the most recently generated fault file through the fault file path. During the operation of the electronic device, in response to the baseboard management controller detecting a host fault in the electronic device, the baseboard management controller sends a retrieval command to the unified extensible firmware interface. The unified extensible firmware interface responds to the retrieval command and retrieves the most recently generated fault file through the fault file path.

4. The method according to claim 3, wherein if the first fault file is a recently generated fault file actively obtained by the Unified Extensible Firmware Interface through the fault file path during the startup process of the electronic device, the method further includes determining whether the first fault file is a fault file to be processed, specifically including: The unified and extensible firmware interface determines the hash value corresponding to the first fault file and sends the hash value corresponding to the first fault file to the baseboard management controller; The baseboard management controller determines the hash value corresponding to the second fault file; The second fault file is a fault file generated when the electronic device host experiences a historical fault; The baseboard management controller compares the hash value corresponding to the first fault file with the hash value corresponding to the second fault file; If the hash value corresponding to the first fault file is the same as the hash value corresponding to the second fault file, then the first fault file is determined to be a processed fault file. If the hash value corresponding to the first fault file is different from the hash value corresponding to the second fault file, then the first fault file is determined to be a fault file to be processed.

5. The method according to claim 4, wherein the unified extensible firmware interface encrypts the first fault file and transmits the encrypted first fault file to the baseboard management controller, comprising: In response to the first fault file being a fault file to be processed, the first fault file is encrypted based on a key, and the first fault file encrypted based on the key is transmitted to the baseboard management controller.

6. The method according to claim 1, further comprising: Determine the path of the fault file corresponding to the first fault file; The unified and extensible firmware interface accesses the system partition based on a file access driver, and obtains the first fault file from the system partition based on the fault file path.

7. The method according to claim 1, further comprising: Determine the key to encrypt the first faulty file.

8. The method according to claim 7, wherein the baseboard management controller outputs the first fault file, comprising one of the following: The baseboard management controller outputs the encrypted first fault file; The baseboard management controller and the key are used to decrypt the encrypted first fault file and output the first fault file.

9. A fault handling apparatus, the apparatus comprising: The first acquisition unit is used to acquire the first fault file based on the unified extensible firmware interface and the fault file path in response to the startup of the electronic device. The first fault file includes at least a log file generated when the electronic device host fails; The transmission unit is used to encrypt the first fault file based on the unified extensible firmware interface, and transmit the encrypted first fault file to the baseboard management controller. The second acquisition unit is used to output the first fault file based on the baseboard management controller.

10. An electronic device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

Images