[lfs-support] Booting LFS with systemd
list1 at michaelshell.org
Tue Jul 10 17:37:47 PDT 2018
On Tue, 10 Jul 2018 08:01:13 +0100
Hazel Russman <hazeldebian at googlemail.com> wrote:
> Just to say that I've now tried the "acpi=copy_dsdt" boot option (without
> using my corrective initrd) and it doesn't stop the 4.15 kernel from
> panicking on my main machine.
Looking again at what you've posted, and the bug report you filed after
you bisected the kernel:
I'd say it is *not* an acpi problem even though it appears that way.
You said that you do not have CONFIG_AMD_MEM_ENCRYPT set.
If CONFIG_NUMA is enabled, what happens if you disable it?
(In "Processor type and features" > "Numa Memory Allocation and
Now, are you sure the problem is strictly related to the commit
i.e., if you revert that patch, and only that patch, in your
kernel, the files affected are:
does the problem then go away?
If reverting the change does *not* fix the problem, then what
about the other two changes you mentioned?:
> Bisecting: 2 revisions left to test after this (roughly 1 step)
> [9af9b94068fb1ea3206a700fc222075966fbef14] x86/cpu/AMD: Handle SME reduction in physical address size
> Bisecting: 0 revisions left to test after this (roughly 1 step)
> [33c2b803edd13487518a2c7d5002d84d7e9c878f] x86/mm: Remove phys_to_virt() usage in ioremap()
> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> [7744ccdbc16f0ac4adae21b3678af93775b3a386] x86/mm: Add Secure Memory Encryption (SME) support
You can reverse a patch via the -R option
patch -p1 -R -i patchfile
If that works, then it is almost certainly *not* an ACPI problem, but rather
a memory management issue that seems to affect the ACPI system.
Since you are not using an AMD system, the AMD SME patch must have changed
something in the intel code, and that might not be too tough to narrow in
That would be something to report to the kernel memory management people.
More information about the lfs-support