1.. SPDX-License-Identifier: GPL-2.0 2 3==================== 4APEI Error INJection 5==================== 6 7EINJ provides a hardware error injection mechanism. It is very useful 8for debugging and testing APEI and RAS features in general. 9 10You need to check whether your BIOS supports EINJ first. For that, look 11for early boot messages similar to this one:: 12 13 ACPI: EINJ 0x000000007370A000 000150 (v01 INTEL 00000001 INTL 00000001) 14 15which shows that the BIOS is exposing an EINJ table - it is the 16mechanism through which the injection is done. 17 18Alternatively, look in /sys/firmware/acpi/tables for an "EINJ" file, 19which is a different representation of the same thing. 20 21It doesn't necessarily mean that EINJ is not supported if those above 22don't exist: before you give up, go into BIOS setup to see if the BIOS 23has an option to enable error injection. Look for something called WHEA 24or similar. Often, you need to enable an ACPI5 support option prior, in 25order to see the APEI,EINJ,... functionality supported and exposed by 26the BIOS menu. 27 28To use EINJ, make sure the following are options enabled in your kernel 29configuration:: 30 31 CONFIG_DEBUG_FS 32 CONFIG_ACPI_APEI 33 CONFIG_ACPI_APEI_EINJ 34 35The EINJ user interface is in <debugfs mount point>/apei/einj. 36 37The following files belong to it: 38 39- available_error_type 40 41 This file shows which error types are supported: 42 43 ================ =================================== 44 Error Type Value Error Description 45 ================ =================================== 46 0x00000001 Processor Correctable 47 0x00000002 Processor Uncorrectable non-fatal 48 0x00000004 Processor Uncorrectable fatal 49 0x00000008 Memory Correctable 50 0x00000010 Memory Uncorrectable non-fatal 51 0x00000020 Memory Uncorrectable fatal 52 0x00000040 PCI Express Correctable 53 0x00000080 PCI Express Uncorrectable non-fatal 54 0x00000100 PCI Express Uncorrectable fatal 55 0x00000200 Platform Correctable 56 0x00000400 Platform Uncorrectable non-fatal 57 0x00000800 Platform Uncorrectable fatal 58 ================ =================================== 59 60 The format of the file contents are as above, except present are only 61 the available error types. 62 63- error_type 64 65 Set the value of the error type being injected. Possible error types 66 are defined in the file available_error_type above. 67 68- error_inject 69 70 Write any integer to this file to trigger the error injection. Make 71 sure you have specified all necessary error parameters, i.e. this 72 write should be the last step when injecting errors. 73 74- flags 75 76 Present for kernel versions 3.13 and above. Used to specify which 77 of param{1..4} are valid and should be used by the firmware during 78 injection. Value is a bitmask as specified in ACPI5.0 spec for the 79 SET_ERROR_TYPE_WITH_ADDRESS data structure: 80 81 Bit 0 82 Processor APIC field valid (see param3 below). 83 Bit 1 84 Memory address and mask valid (param1 and param2). 85 Bit 2 86 PCIe (seg,bus,dev,fn) valid (see param4 below). 87 88 If set to zero, legacy behavior is mimicked where the type of 89 injection specifies just one bit set, and param1 is multiplexed. 90 91- param1 92 93 This file is used to set the first error parameter value. Its effect 94 depends on the error type specified in error_type. For example, if 95 error type is memory related type, the param1 should be a valid 96 physical memory address. [Unless "flag" is set - see above] 97 98- param2 99 100 Same use as param1 above. For example, if error type is of memory 101 related type, then param2 should be a physical memory address mask. 102 Linux requires page or narrower granularity, say, 0xfffffffffffff000. 103 104- param3 105 106 Used when the 0x1 bit is set in "flags" to specify the APIC id 107 108- param4 109 Used when the 0x4 bit is set in "flags" to specify target PCIe device 110 111- notrigger 112 113 The error injection mechanism is a two-step process. First inject the 114 error, then perform some actions to trigger it. Setting "notrigger" 115 to 1 skips the trigger phase, which *may* allow the user to cause the 116 error in some other context by a simple access to the CPU, memory 117 location, or device that is the target of the error injection. Whether 118 this actually works depends on what operations the BIOS actually 119 includes in the trigger phase. 120 121BIOS versions based on the ACPI 4.0 specification have limited options 122in controlling where the errors are injected. Your BIOS may support an 123extension (enabled with the param_extension=1 module parameter, or boot 124command line einj.param_extension=1). This allows the address and mask 125for memory injections to be specified by the param1 and param2 files in 126apei/einj. 127 128BIOS versions based on the ACPI 5.0 specification have more control over 129the target of the injection. For processor-related errors (type 0x1, 0x2 130and 0x4), you can set flags to 0x3 (param3 for bit 0, and param1 and 131param2 for bit 1) so that you have more information added to the error 132signature being injected. The actual data passed is this:: 133 134 memory_address = param1; 135 memory_address_range = param2; 136 apicid = param3; 137 pcie_sbdf = param4; 138 139For memory errors (type 0x8, 0x10 and 0x20) the address is set using 140param1 with a mask in param2 (0x0 is equivalent to all ones). For PCI 141express errors (type 0x40, 0x80 and 0x100) the segment, bus, device and 142function are specified using param1:: 143 144 31 24 23 16 15 11 10 8 7 0 145 +-------------------------------------------------+ 146 | segment | bus | device | function | reserved | 147 +-------------------------------------------------+ 148 149Anyway, you get the idea, if there's doubt just take a look at the code 150in drivers/acpi/apei/einj.c. 151 152An ACPI 5.0 BIOS may also allow vendor-specific errors to be injected. 153In this case a file named vendor will contain identifying information 154from the BIOS that hopefully will allow an application wishing to use 155the vendor-specific extension to tell that they are running on a BIOS 156that supports it. All vendor extensions have the 0x80000000 bit set in 157error_type. A file vendor_flags controls the interpretation of param1 158and param2 (1 = PROCESSOR, 2 = MEMORY, 4 = PCI). See your BIOS vendor 159documentation for details (and expect changes to this API if vendors 160creativity in using this feature expands beyond our expectations). 161 162 163An error injection example:: 164 165 # cd /sys/kernel/debug/apei/einj 166 # cat available_error_type # See which errors can be injected 167 0x00000002 Processor Uncorrectable non-fatal 168 0x00000008 Memory Correctable 169 0x00000010 Memory Uncorrectable non-fatal 170 # echo 0x12345000 > param1 # Set memory address for injection 171 # echo $((-1 << 12)) > param2 # Mask 0xfffffffffffff000 - anywhere in this page 172 # echo 0x8 > error_type # Choose correctable memory error 173 # echo 1 > error_inject # Inject now 174 175You should see something like this in dmesg:: 176 177 [22715.830801] EDAC sbridge MC3: HANDLING MCE MEMORY ERROR 178 [22715.834759] EDAC sbridge MC3: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010090 179 [22715.834759] EDAC sbridge MC3: TSC 0 180 [22715.834759] EDAC sbridge MC3: ADDR 12345000 EDAC sbridge MC3: MISC 144780c86 181 [22715.834759] EDAC sbridge MC3: PROCESSOR 0:306e7 TIME 1422553404 SOCKET 0 APIC 0 182 [22716.616173] EDAC MC3: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0) 183 184For more information about EINJ, please refer to ACPI specification 185version 4.0, section 17.5 and ACPI 5.0, section 18.6. 186