Re: IPSec kernel oops on ppc64
From: Joy Latten <hidden>
Date: 2006-08-28 22:36:20
4 messages, 3 authors, 2006-08-30 · open the first message on its own page
From: Joy Latten <hidden>
Date: 2006-08-28 22:36:20
Joy Latten [off-list ref] wrote:quoted
I installed 2.6.17 + patch-2.6.18-rc4 + 2.6.18-rc4-mm2 onto two pSeries power 5 (ppc64 lpars) machines. I configured IPSec using the configuration listed below.Could you try straight 2.6.17? If that crashes too, then at least we can be sure that it isn't something new.
A straight 2.6.17 kernel does not crash and my pings work. A 2.6.17 + patch-2.6.18-rc4 does crash and my pings do not work. The above tests were done on a ppc64. I can try patch-2.6.18-rc1, etc... to see which one it stops working on to narrow it down. Regards, Joy
From: David Miller <davem@davemloft.net>
Date: 2006-08-28 23:36:13
From: Joy Latten <redacted> Date: Mon, 28 Aug 2006 17:25:15 -0500
I can try patch-2.6.18-rc1, etc... to see which one it stops working on to narrow it down.
If you could do this in the meanwhile, it would help us out a lot. Thanks.
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2006-08-29 01:31:37
On Mon, Aug 28, 2006 at 05:25:15PM -0500, Joy Latten wrote:
A straight 2.6.17 kernel does not crash and my pings work. A 2.6.17 + patch-2.6.18-rc4 does crash and my pings do not work. The above tests were done on a ppc64.
Thanks for that info. This does sound like a bug. Could you please generate a dump of the stack/register contents and a disassembly of the code around the crash? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} [off-list ref] Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2006-08-30 11:42:55
Hi: Thanks to some excellent info from Joy, I've trakced the problem down to a broken implementation of memmove on ppc64, which in turn is due to a broken memcpy. Both memmove and memcpy need to return the destination pointer as per the C standard. The ppc64 version of memcpy returns a pointer to the last byte copied instead. Since memmove degenerates into memcpy in some cases, this makes it broken as well. Something like the following patch should fix the problem. Be warned that I know absolutely nothing about ppc assembly so don't come back to me if this patch eats your disk :) BTW, I spotted a couple of typos in memcpy_64.S/copyuser_64.S where "cmpldi cr1,..." became "cmpldi r1,...". So please fix that up while you ppc64 guys are at it. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} [off-list ref] Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
diff --git a/arch/powerpc/lib/memcpy_64.S b/arch/powerpc/lib/memcpy_64.S
index fd66acf..9e8d9e7 100644
--- a/arch/powerpc/lib/memcpy_64.S
+++ b/arch/powerpc/lib/memcpy_64.S@@ -11,6 +11,7 @@ #include <asm/ppc_asm.h> .align 7 _GLOBAL(memcpy) + std r3,-8(r1) mtcrf 0x01,r5 cmpldi cr1,r5,16 neg r6,r3 # LS 3 bits = # bytes to 8-byte dest bdry
@@ -53,7 +54,8 @@ _GLOBAL(memcpy) 2: bf cr7*4+3,3f rotldi r9,r9,8 stb r9,0(r3) -3: blr +3: ld r3,-8(r1) + blr .Lsrc_unaligned: srdi r6,r5,3
@@ -167,4 +169,5 @@ _GLOBAL(memcpy) 3: bf cr7*4+3,4f lbz r0,0(r4) stb r0,0(r3) -4: blr +4: ld r3,-8(r1) + blr