On Sun, 2011-01-02 at 20:41 +0100, cfchris6 wrote: > What has to be done until the proposed solution to blacklist the module could > be implemented? > > I do think that it is not very nice to have a big part of those with a newer > amd64 box unable to use this functionality. > > If I get it correctly, the main reason for the decision to disable that module > is that it's not playing nice with a T400. What is the number of the bug report > with upstream on that matter? I don't know of one. There is a Fedora bug report <https://bugzilla.redhat.com/show_bug.cgi?id=571577> and if I read that correctly then this is not a model-specific bug - the module was actually completely broken in 2.6.32 if CONFIG_CRYPTO_FIPS=y (which it is in Debian packages). However, it also looks like this was fixed in 2.6.32.19, which is incorporated in the source for the current package. Please can you test whether aesni-intel loads and works in: 1. Package version 2.6.32-12 <http://snapshot.debian.org/package/linux-2.6/2.6.32-12/>. This was the last version with aesni-intel included. 2. Package version 2.6.32-29, modified to reenable aesni-intel. See the instructions at <http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>. a. Follow section 4.2.1. b. Change '# CONFIG_CRYPTO_AES_NI_INTEL is not set' to 'CONFIG_CRYPTO_AES_NI_INTEL=m' in debian/config/kernelarch-x86/config-arch-64. c. Follow section 4.2.4. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part