[lfs-support] Booting LFS with systemd
hazeldebian at googlemail.com
Fri Jul 13 22:44:33 PDT 2018
On Fri, 13 Jul 2018 08:26:01 +0100
Ken Moffat <zarniwhoop at ntlworld.com> wrote:
> On Fri, Jul 13, 2018 at 12:47:50AM -0400, Michael Shell wrote:
> > I should have realized that since Hazel was working with the full git tree,
> > that he could easily revert any commit within git. Duh!
> > Hmmmm ... I think what I was thinking was that I didn't trust the results
> > of the bisection within git (because the identified problem code does not
> > even seem be active within Hazel's config, and Hazel said he was new to
> > the bisection process). So, I'm not so sure the commit that is believed
> > to be the offender really is the guilty party. I was thinking that Hazel
> > would take the 4.15 source tree (from the official release tarball) and
> > then manually backout the suspect commit - if that works/boots, then it
> > is virtually certain we found the problem area (as we didn't depend on
> > git).
Gentlemen, I have a confession to make. Over the past two days I have repeated the bisect (for safety) and it turns out that the original one was terminated prematurely. That's what happens when you have people blindly following instructions and not really knowing what they are doing!
The actual "guilty party" is the *next* commit -- which is why the one I reported before didn't seem relevant. Here is the final end:
# good: [872cbefd2d9c52bd0b1e2c7942c4369e98a5a5ae] x86/cpu/AMD: Add the Secure Memory Encryption CPU feature
git bisect good 872cbefd2d9c52bd0b1e2c7942c4369e98a5a5ae
# good: [7744ccdbc16f0ac4adae21b3678af93775b3a386] x86/mm: Add Secure Memory Encryption (SME) support
git bisect good 7744ccdbc16f0ac4adae21b3678af93775b3a386
# bad: [33c2b803edd13487518a2c7d5002d84d7e9c878f] x86/mm: Remove phys_to_virt() usage in ioremap()
git bisect bad 33c2b803edd13487518a2c7d5002d84d7e9c878f
# first bad commit: [33c2b803edd13487518a2c7d5002d84d7e9c878f] x86/mm:
Remove phys_to_virt() usage in ioremap()
When I do "bisect show" I get:
"Currently there is a check if the address being mapped is in the ISA range (is_ISA_range()), and if it is, then phys_to_virt() is used to perform the mapping. When SME is active, the default is to add pagetable mappings with the encryption bit set unless specifically overridden. The resulting pagetable mapping from phys_to_virt() will result in a mapping that has the encryption bit set. With SME, the use of ioremap() is intended to generate pagetable mappings that do not have the encryption bit set through the use of the PAGE_KERNEL_IO protection value.
Rather than special case the SME scenario, remove the ISA range check and usage of phys_to_virt() and have ISA range mappings continue through the remaining ioremap() path."
I gather that some remapping that used to be done isn't done any more and that's what my machine doesn't like.
I suppose I now need to find the patch and revert it by hand and see what that does. I plan to do that today. Thank you for all your help so far.
More information about the lfs-support