This is because powerpc's set_memory_encrypted makes an ultracall but it
does not exist on that processor.
x86's set_memory_encrypted/decrypted have
/* Nothing to do if memory encryption is not active */
if (!mem_encrypt_active())
return 0;
Probably powerpc should just do that too.
Thanks,
Nick
From: Sachin Sant <hidden> Date: 2021-07-29 04:22:02
On 28-Jul-2021, at 11:05 PM, Nathan Chancellor [off-list ref] wrote:
On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
quoted
linux-next fails to boot on Power server (POWER8/POWER9). Following traces
are seen during boot
[ 0.010799] software IO TLB: tearing down default memory pool
[ 0.010805] ------------[ cut here ]------------
[ 0.010808] kernel BUG at arch/powerpc/kernel/interrupt.c:98!
[ 0.010812] Oops: Exception in kernel mode, sig: 5 [#1]
…….
I noticed this with OpenSUSE's ppc64le config [1] and my bisect landed on
commit ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()"). That
Indeed. Thanks Nathan.
Bisect points to this commit. Reverting the commit allows the kernel to boot.
Thanks
-Sachin
From: Will Deacon <will@kernel.org> Date: 2021-07-29 16:13:42
On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
quoted
next-20210723 was good. The boot failure seems to have been introduced with next-20210726.
I have attached the boot log.
I noticed this with OpenSUSE's ppc64le config [1] and my bisect landed on
commit ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()"). That
series just keeps on giving...
Yes, but look how handy our new print is!
[ 0.010799] software IO TLB: tearing down default memory pool
[ 0.010805] ------------[ cut here ]------------
[ 0.010808] kernel BUG at arch/powerpc/kernel/interrupt.c:98!
Following Nick's suggestion, the diff below should help? I don't have a
relevant box on which I can test it though.
Will
--->8
@@ -73,6 +76,9 @@ int set_memory_encrypted(unsigned long addr, int numpages)intset_memory_decrypted(unsignedlongaddr,intnumpages){+if(!mem_encrypt_active())+return0;+if(!PAGE_ALIGNED(addr))return-EINVAL;
From: Konrad Rzeszutek Wilk <hidden> Date: 2021-07-29 17:09:01
On Thu, Jul 29, 2021 at 05:13:36PM +0100, Will Deacon wrote:
On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
quoted
On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
quoted
next-20210723 was good. The boot failure seems to have been introduced with next-20210726.
I have attached the boot log.
I noticed this with OpenSUSE's ppc64le config [1] and my bisect landed on
commit ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()"). That
series just keeps on giving...
Low-level across platform do that. And thank you for testing it and
finding this bug. Please let me know if the patch works so I can add it
in in the patch series.
Yes, but look how handy our new print is!
:)
quoted hunk
[ 0.010799] software IO TLB: tearing down default memory pool
[ 0.010805] ------------[ cut here ]------------
[ 0.010808] kernel BUG at arch/powerpc/kernel/interrupt.c:98!
Following Nick's suggestion, the diff below should help? I don't have a
relevant box on which I can test it though.
Will
--->8
@@ -73,6 +76,9 @@ int set_memory_encrypted(unsigned long addr, int numpages)intset_memory_decrypted(unsignedlongaddr,intnumpages){+if(!mem_encrypt_active())+return0;+if(!PAGE_ALIGNED(addr))return-EINVAL;
On 7/29/2021 9:35 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Jul 29, 2021 at 05:13:36PM +0100, Will Deacon wrote:
quoted
On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
quoted
On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
quoted
next-20210723 was good. The boot failure seems to have been introduced with next-20210726.
I have attached the boot log.
I noticed this with OpenSUSE's ppc64le config [1] and my bisect landed on
commit ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()"). That
series just keeps on giving...
Low-level across platform do that. And thank you for testing it and
finding this bug. Please let me know if the patch works so I can add it
in in the patch series.
That was not meant to sound as sarcastic as it did so my apologies for
that :(
Will's patch looks good to me in QEMU, I do not have a bare metal POWER
system to test it on.
Tested-by: Nathan Chancellor <nathan@kernel.org>
quoted
Yes, but look how handy our new print is!
:)
quoted
[ 0.010799] software IO TLB: tearing down default memory pool
[ 0.010805] ------------[ cut here ]------------
[ 0.010808] kernel BUG at arch/powerpc/kernel/interrupt.c:98!
Following Nick's suggestion, the diff below should help? I don't have a
relevant box on which I can test it though.
Will
--->8
@@ -73,6 +76,9 @@ int set_memory_encrypted(unsigned long addr, int numpages)intset_memory_decrypted(unsignedlongaddr,intnumpages){+if(!mem_encrypt_active())+return0;+if(!PAGE_ALIGNED(addr))return-EINVAL;
From: Sachin Sant <hidden> Date: 2021-07-30 05:18:20
On 29-Jul-2021, at 9:43 PM, Will Deacon [off-list ref] wrote:
On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
quoted
On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
quoted
next-20210723 was good. The boot failure seems to have been introduced with next-20210726.
I have attached the boot log.
I noticed this with OpenSUSE's ppc64le config [1] and my bisect landed on
commit ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()"). That
series just keeps on giving...
Yes, but look how handy our new print is!
[ 0.010799] software IO TLB: tearing down default memory pool
[ 0.010805] ------------[ cut here ]------------
[ 0.010808] kernel BUG at arch/powerpc/kernel/interrupt.c:98!
Following Nick's suggestion, the diff below should help? I don't have a
relevant box on which I can test it though.
Thanks for the fix. This fixes the reported problem for me.
Tested successfully on both PowerVM LPAR as well as bare metal environment.
Reported-by: Sachin Sant <redacted>
Tested-by: Sachin Sant <redacted>