On Fri, 13 Jul 2018 08:26:01 +0100
Ken Moffat <[email protected]> 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.
--
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
