** Description changed: [Impact] When an ARM-specific platform error (CPER) comes occurs, the kernel will emit an error with an opaque hex error type. The user would then need to consult the UEFI specification to decode it. It is far easier for the kernel to do the decoding itself, and just tell the user what the problem is. [Test Case] On a server that supports EINJ, generate a fake CE (thanks to Tyler Baicar for this example): modprobe einj echo 0x12345000 > /sys/kernel/debug/apei/einj/param1 echo $((-1 << 12)) > /sys/kernel/debug/apei/einj/param2 echo 5 > /sys/kernel/debug/apei/einj/param3 echo 0x3 > /sys/kernel/debug/apei/einj/flags echo 0x1 > /sys/kernel/debug/apei/einj/error_type echo 1 > /sys/kernel/debug/apei/einj/error_inject In the output, look for a decoded message. Without this fix, you'll see: [ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f [ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000 But with the fix, you'll see: [ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f [ 388.094317] {2}[Hardware Error]: transaction type: Generic [ 388.094322] {2}[Hardware Error]: operation type: Generic read (type of instruction or data request cannot be determined) [ 388.094326] {2}[Hardware Error]: cache level: 3 [ 388.094330] {2}[Hardware Error]: processor context not corrupted [ 388.094333] {2}[Hardware Error]: the error has been corrected [ 388.094337] {2}[Hardware Error]: PC is imprecise [ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000 [Fix] These upstream fixes add ARM decoding support: c6d8c8ef1d0d94fdae9f5d72982963db89f9cdad efi: Move ARM CPER code to new file 301f55b1a9177132d2b9ce8a90bf0ae4b37bb850 efi: Parse ARM error information value [Regression Risk] + The code changed is specific to ARM, and has been tested there. There's a small change to arch-independent code, but it just involves renaming an array and adding the obviously correct const attribute.
-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1770244 Title: Decode ARM CPER records in kernel Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: In Progress Bug description: [Impact] When an ARM-specific platform error (CPER) comes occurs, the kernel will emit an error with an opaque hex error type. The user would then need to consult the UEFI specification to decode it. It is far easier for the kernel to do the decoding itself, and just tell the user what the problem is. [Test Case] On a server that supports EINJ, generate a fake CE (thanks to Tyler Baicar for this example): modprobe einj echo 0x12345000 > /sys/kernel/debug/apei/einj/param1 echo $((-1 << 12)) > /sys/kernel/debug/apei/einj/param2 echo 5 > /sys/kernel/debug/apei/einj/param3 echo 0x3 > /sys/kernel/debug/apei/einj/flags echo 0x1 > /sys/kernel/debug/apei/einj/error_type echo 1 > /sys/kernel/debug/apei/einj/error_inject In the output, look for a decoded message. Without this fix, you'll see: [ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f [ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000 But with the fix, you'll see: [ 388.094304] {2}[Hardware Error]: error_info: 0x0000000004c6007f [ 388.094317] {2}[Hardware Error]: transaction type: Generic [ 388.094322] {2}[Hardware Error]: operation type: Generic read (type of instruction or data request cannot be determined) [ 388.094326] {2}[Hardware Error]: cache level: 3 [ 388.094330] {2}[Hardware Error]: processor context not corrupted [ 388.094333] {2}[Hardware Error]: the error has been corrected [ 388.094337] {2}[Hardware Error]: PC is imprecise [ 388.094341] {2}[Hardware Error]: physical fault address: 0x0000000012345000 [Fix] These upstream fixes add ARM decoding support: c6d8c8ef1d0d94fdae9f5d72982963db89f9cdad efi: Move ARM CPER code to new file 301f55b1a9177132d2b9ce8a90bf0ae4b37bb850 efi: Parse ARM error information value [Regression Risk] The code changed is specific to ARM, and has been tested there. There's a small change to arch-independent code, but it just involves renaming an array and adding the obviously correct const attribute. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1770244/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp