On Wed, 30 Oct 2024 at 19:26, Gregory Price <gourry@xxxxxxxxxx> wrote: > > On Wed, Oct 30, 2024 at 05:13:14PM +0000, Usama Arif wrote: > > > > > > On 30/10/2024 05:25, Jiri Slaby wrote: > > > On 25. 10. 24, 15:27, Usama Arif wrote: > > >> Could you share the e820 map, reserve setup_data and TPMEventLog address with and without the patch? > > >> All of these should be just be in the dmesg. > > > efi: EFI v2.6 by American Megatrends > > Tossing in another observation - the AMI EFI we've been working with has been > > EFI v2.8 by American Megatrends > or > EFI v2.9 by American Megatrends > > We have not seen this particular behavior (cold boot corruption issues) on top > of these version. Might be worth investigating this issue. > > you may also want to investigate this patch set: > > https://lore.kernel.org/all/20240913231954.20081-1-gourry@xxxxxxxxxx/ > > which I believe would have caught your "eat all memory" sign extention issue. > > This is queued up for v6.13 i think - but possibly 1/4 deserves a stable mark. > To me, it does not seem obvious at all that the TPM code is the culprit here. The firmware produces a corrupted memory attributes table now that the EFI stub uses ACPI reclaim memory for the TPM event log, but to me, it smells like a firmware issue, not an issue in the EFI stub. (Pool allocations can trigger page allocations, affecting the layout of the EFI memory map). So let's keep an open mind here, and not stare ourselves blind on the TPM event log code.
