* Herbert Xu | 2009-02-26 14:06:18 [+0800]:
As algorithms requiring fallbacks are a special case, we can fix
this by giving them a different module alias than the rest. Then
it's just a matter of using the right aliases according to what
algorithms we're trying to find.
Yup. I am not sure if we
Hi Herbert,
your patch solves the hanging modprobe (tested on top of cryptodev-2.6).
Both modules (aes_generic and aes_s390) are loaded after the modprobe
aes_s390.
Thanks a lot, Jan
On Thu, 2009-02-26 at 14:06 +0800, Herbert Xu wrote:
On Wed, Feb 25, 2009 at 05:33:50PM +, Jan Glauber
On Wed, Feb 25, 2009 at 05:33:50PM +, Jan Glauber wrote:
STACK TRACE FOR TASK: 0x3f6137c8 (modprobe)
STACK:
0 schedule+1136 [0x2df82c]
1 fcntl_setlk+412 [0x107a0c]
2 sys_fcntl+262 [0xd7076]
3 sysc_noemu+16 [0x27a5e]
I see. Please let me know if this patch fixes it.
crypto: api
Hi Herbert,
commit 73d3864a4823abda19ebc4387b6ddcbf416e3a77 leads to a
hanging modprobe aes_s390 process. If the process is
interrupted the following oops occurs:
[ cut here ]
Badness at crypto/algapi.c:293
Modules linked in: aes_generic aes_s390(+) binfmt_misc
CPU: 0
Jan Glauber j...@linux.vnet.ibm.com wrote:
That only happens if the aes_generic module isn't loaded. If
aes_generic is already present the aes_s390 loads without problems.
Any idea how to solve this? Is something missing in the fallback code
that uses aes_generic?
Yeah it looks like it's
