quoted text > 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 , %%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:
