Messages in this thread | | | From | Wolfgang Walter <> | Subject | Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes | Date | Fri, 8 Aug 2008 12:36:54 +0200 |
| |
Am Donnerstag, 7. August 2008 18:23 schrieb Wolfgang Walter: > Am Mittwoch, 6. August 2008 22:14 schrieb Suresh Siddha: > > On Wed, Aug 06, 2008 at 10:33:25AM -0700, Wolfgang Walter wrote: > > > Hello Herbert, > > > > > > I think I finally found the problem. > > > > > > Here a short description again: all our routers with a via C3 using > > > padlock for AES-encryption are crashing with 2.6.26 while they work > > > fine with 2.6.25. Not using padlock (i.e. using the i386 assembler > > > version of AES) they just work fine. > > > > Both the padlock version or asm version don't use FP/math registers, > > right? It is interesting that you don't see the problem with asm version > > but see the problem with padlock version. > > > > Does disabling CONFIG_PREEMPT in 2.6.26 change anything? And also, > > Didn't check that yet as I'm still running my modified 2.6.26. It now runs > almost one day flawlessly. > > But yesterday I tried the following patch on top of a vanilla 2.6.26: > > ======================================================= > diff -ur ../linux-2.6.26/drivers/crypto/padlock-aes.c > ./drivers/crypto/padlock-aes.c --- > ../linux-2.6.26/drivers/crypto/padlock-aes.c 2008-07-15 11:29:32.000000000 > +0200 +++ ./drivers/crypto/padlock-aes.c 2008-08-07 17:46:55.000000000 > +0200 @@ -16,6 +16,7 @@ > #include <linux/interrupt.h> > #include <linux/kernel.h> > #include <asm/byteorder.h> > +#include <asm/i387.h> > #include "padlock.h" > > /* Control word. */ > @@ -144,9 +145,11 @@ > static inline void padlock_xcrypt(const u8 *input, u8 *output, void *key, > void *control_word) > { > + kernel_fpu_begin(); > asm volatile (".byte 0xf3,0x0f,0xa7,0xc8" /* rep xcryptecb */ > > : "+S"(input), "+D"(output) > : "d"(control_word), "b"(key), "c"(1)); > > + kernel_fpu_end(); > } > > static void aes_crypt_copy(const u8 *in, u8 *out, u32 *key, struct cword > *cword) @@ -179,6 +182,7 @@ > return; > } > > + kernel_fpu_begin(); > asm volatile ("test $1, %%cl;" > "je 1f;" > "lea -1(%%ecx), %%eax;" > @@ -190,15 +194,18 @@ > > : "+S"(input), "+D"(output) > : "d"(control_word), "b"(key), "c"(count) > : "ax"); > > + kernel_fpu_end(); > } > > static inline u8 *padlock_xcrypt_cbc(const u8 *input, u8 *output, void > *key, u8 *iv, void *control_word, u32 count) > { > /* rep xcryptcbc */ > + kernel_fpu_begin(); > asm volatile (".byte 0xf3,0x0f,0xa7,0xd0" > > : "+S" (input), "+D" (output), "+a" (iv) > : "d" (control_word), "b" (key), "c" (count)); > > + kernel_fpu_end(); > return iv; > } > > ============================================================= > > I found that kernel_fpu_begin(); kernel_fpu_begin(); is used with > MMX and/or SSE: > > include/asm/xor_32.h > drivers/md/raid6mmx.c > drivers/md/raid6sse1.c > drivers/md/raid6sse2.c > > > With this change I its a little bit more stable, I needed more then 5 > minutes to crash the kernel (repeated it several times). If I read > the code correctly this disables preemption for the time the padlock cmd > is executing.
Forget that - I booted the wrong kernel.
I now really test this modification and it seems to be stable. The router now runs for 45 minutes without oops.
Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München Tel: +49 89 38196 276 Fax: +49 89 38196 150 Email: wolfgang.walter@stwm.de http://www.studentenwerk-muenchen.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |