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
---
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
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 fixed a missing
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
That is
.
From d8d9b7c3e5be9c5a6198dac6fe7279ca904343a8 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Date: Wed, 17 Jul 2013 19:45:19 +0900
Subject: [PATCH 3.11-rc1] crypto: Fix boot failure due to module dependency.
Commit
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 will increase
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[] = {
