Waiman Long wrote:
> I would like to report that I also have the same boot problem on a
> RHEL6.4 box with the crypto patch. My workaround is to force kernel
> build to have the crc_t10dif code built-in by changing the config file:
>
> 4889c4889
> < CONFIG_CRYPTO_CRCT10DIF=m
> ---
> > CONFIG_CR
Herbert Xu wrote:
> The trouble is not all distros will include the softdep modules in
> the initramfs. So for now I think we will have to live with a fallback.
I see.
Herbert Xu wrote:
> OK, can you please try this patch on top of the current tree?
>
> This way at least you'll have a working s
Herbert Xu wrote:
> On Fri, Jul 19, 2013 at 06:31:04PM -0700, Tim Chen wrote:
> >
> > However, when I have the library and generic algorithm compiled in,
> > I do not see the PCLMULQDQ version loaded.
> >
> > CONFIG_CRYPTO_CRCT10DIF=y
> > CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
> > CONFIG_CRC_T10DIF=y
>
Tim Chen wrote:
> On Fri, 2013-07-19 at 16:37 -0700, Tim Chen wrote:
> > Herbert,
> >
> > I've tried the module alias approach (see my earlier mail with patch)
> > but it didn't seem to load things properly. Can you check to see if
> > there's anything I did incorrectly.
> >
> > Tim
>
> I fix
Tim Chen wrote:
> > > Your approach is quite complicated. I think something simpler like the
> > > following will work:
> >
> > We cannot benefit from PCLMULQDQ. Is it acceptable for you?
>
>
> The following code in crct10dif-pclmul_glue.c
>
> static const struct x86_cpu_id crct10dif_cpu_id[] =
Tim Chen wrote:
> > Therefore, I think possible solutions are either
> >
> > (a) built-in the dependent modules
> >
> > # grep crc /lib/modules/3.11.0-rc1+/modules.dep
> > kernel/drivers/scsi/sd_mod.ko: kernel/lib/crc-t10dif.ko
> > kernel/lib/crc-t10dif.ko:
>
> This approach
be loaded on
!X86_FEATURE_MATCH(X86_FEATURE_PCLMULQDQ) systems.
>From d8d9b7c3e5be9c5a6198dac6fe7279ca904343a8 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 17 Jul 2013 19:45:19 +0900
Subject: [PATCH 3.11-rc1] crypto: F
