4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Young
[ Upstream commit 7f6f60a1ba52538c16f26930bfbcfe193d9d746a ]
earlyprintk=efi,keep does not work any more with a warning
in mm/early_ioremap.c: WARN_ON(system_state != SYSTEM_BOOTIN
Currently on arm64 ESRT memory does not appear to be properly blocked off.
Upon successful initialization, ESRT prints out the memory region that it
exists in like:
esrt: Reserving ESRT space from 0x0a4c1c18 to 0x0a4c1cf0.
But then by dumping /proc/iomem this region appears as par
If ESRT initialization fails due to an unsupported version, the
early_memremap allocation is never unmapped. This will cause an
early ioremap leak. So, make sure to unmap the memory allocation
before returning from efi_esrt_init().
Signed-off-by: Tyler Baicar
---
drivers/firmware/efi/esrt.c | 2
The ESRT memory region is being exposed as System RAM in /proc/iomem
which is wrong because it cannot be overwritten. This memory is needed
for kexec kernels in order to properly initialize ESRT, so if it is
overwritten it will cause ESRT failures in the kexec kernel. Mark this
region as nomap so t
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Young
[ Upstream commit 7f6f60a1ba52538c16f26930bfbcfe193d9d746a ]
earlyprintk=efi,keep does not work any more with a warning
in mm/early_ioremap.c: WARN_ON(system_state != SYSTEM_BOOTING
On Thu, Feb 22, 2018 at 06:11:14AM +, Luck, Tony wrote:
>> On Feb 21, 2018, at 21:52, Linus Torvalds wrote:
>>
>> Does the error return actually break real users? Not "I can do did
>> things and it acts differently" things, but actual users...
>
> Probably not. Peter Jones said that efibootmg
From: Yazen Ghannam
This series adds decoding for the IA32/X64 Common Platform Error Record.
Patch 1 fixes the IA32/X64 Processor Error Section definition to match
the UEFI spec.
Patches 2-8 add the new decoding. The patches incrementally add the
decoding starting from the top-level "Error Sect
From: Yazen Ghannam
Print the fields of the IA32/X64 Context Information structure.
Print the "Register Array" as raw values. Some context types are defined
in the UEFI spec, so more detailed decoded may be added in the future.
Based on UEFI 2.7 section N.2.4.2.2 IA32/X64 Processor Context
Info
From: Yazen Ghannam
Print the common fields of the Cache, TLB, and Bus check structures.The
fields of these three check types are the same except for a few more
fields in the Bus check structure. The remaining Bus check structure
fields will be decoded in a following patch.
Based on UEFI 2.7,
Ta
From: Yazen Ghannam
For easier handling, match the known IA32/X64 error structure GUIDs to
enums.
Also, print out the name of the matching Error Structure Type.
GUIDs taken from UEFI 2.7 section N.2.4.2.1 IA32/X64 Processor Error
Information Structure.
Cc: # 4.16.x
Signed-off-by: Yazen Ghanna
From: Yazen Ghannam
The IA32/X64 MS Check structure varies from the other Check structures
in the the bit positions of its fields, and it includes an additional
"Error Type" field.
Decode the MS Check structure in a separate function.
Based on UEFI 2.7 Table 260. IA32/X64 MS Check Field Descrip
From: Yazen Ghannam
Print the fields in the IA32/X64 Processor Error Info Structure.
Based on UEFI 2.7 Table 256. IA32/X64 Processor Error Information
Structure.
Cc: # 4.16.x
Signed-off-by: Yazen Ghannam
---
drivers/firmware/efi/cper-x86.c | 53 +
1 fi
From: Yazen Ghannam
The "Participation Type", "Time Out", and "Address Space" fields are
unique to the IA32/X64 Bus Check structure. Print these fields.
Based on UEFI 2.7 Table 259. IA32/X64 Bus Check Structure
Cc: # 4.16.x
Signed-off-by: Yazen Ghannam
---
drivers/firmware/efi/cper-x86.c | 4
From: Yazen Ghannam
Based on UEFI 2.7 Table 255. Processor Error Record, the "Local APIC_ID"
field is 8 bytes but Linux defines this field as 1 byte.
Fix this in the struct cper_sec_proc_ia definition.
Cc: # 4.16.x
Signed-off-by: Yazen Ghannam
---
include/linux/cper.h | 2 +-
1 file changed,
From: Yazen Ghannam
Recognize the IA32/X64 Processor Error Section.
Do the section decoding in a new "cper-x86.c" file and add this to the
Makefile depending on a new "UEFI_CPER_X86" config option.
Print the Local APIC ID and CPUID info from the Processor Error Record.
The "Processor Error Inf
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Young
[ Upstream commit 7f6f60a1ba52538c16f26930bfbcfe193d9d746a ]
earlyprintk=efi,keep does not work any more with a warning
in mm/early_ioremap.c: WARN_ON(system_state != SYSTEM_BOOTING
On Thu, Feb 22, 2018 at 6:08 PM, Ard Biesheuvel
wrote:
> On 22 February 2018 at 18:07, Linus Torvalds
> wrote:
>> On Thu, Feb 22, 2018 at 9:54 AM, Luck, Tony wrote:
>>> With the new "while/nap" change there would still be one message
>>> per second, but the number of callbacks suppressed should
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Dave Young
[ Upstream commit 7f6f60a1ba52538c16f26930bfbcfe193d9d746a ]
earlyprintk=efi,keep does not work any more with a warning
in mm/early_ioremap.c: WARN_ON(system_state != SYSTEM_BOOTIN
On 02/23/18 at 12:42pm, Tyler Baicar wrote:
> If ESRT initialization fails due to an unsupported version, the
> early_memremap allocation is never unmapped. This will cause an
> early ioremap leak. So, make sure to unmap the memory allocation
> before returning from efi_esrt_init().
>
> Signed-off
On 02/23/18 at 12:42pm, Tyler Baicar wrote:
> The ESRT memory region is being exposed as System RAM in /proc/iomem
> which is wrong because it cannot be overwritten. This memory is needed
> for kexec kernels in order to properly initialize ESRT, so if it is
> overwritten it will cause ESRT failures
20 matches
Mail list logo
