Hi all,
Changes since 20101126:
Linus' tree gained a build failure so I added the fix patch from his
(later) tree.
The v4l-dvb tree still has its build failure for which I applied a patch.
The net tree gained a build failure so I used the version from
next-20101126.
The security-testing tree gained some build failures for which I reverted
2 commits.
The tip tree reintroduced a build failure and added another one so I have
reverted 3 commits.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 180 trees (counting Linus' and 26 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell [email protected]
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/rc-fixes
Merging driver-core.current/driver-core-linus
Merging tty.current/tty-linus
Merging usb.current/usb-linus
Merging staging.current/staging-linus
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging sh-current/sh-fixes-for-linus
Merging rmobile-current/rmobile-fixes-for-linus
Merging fbdev-current/fbdev-fixes-for-linus
Merging gcl-current/merge
Merging arm/devel
Merging davinci/davinci-next
Merging i.MX/for-next
Merging msm/for-next
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
Merging tegra/for-next
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging parisc/next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/next
Merging galak/next
Merging s390/features
Merging sh/sh-latest
Merging rmobile/rmobile-latest
Merging sparc/master
Merging tile/master
Merging xtensa/master
CONFLICT (content): Merge conflict in arch/xtensa/configs/iss_defconfig
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging hfsplus/for-next
Merging jfs/next
Merging logfs/master
CONFLICT (content): Merge conflict in fs/logfs/logfs.h
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging vfs/for-next
Merging pci/linux-next
CONFLICT (content): Merge conflict in drivers/pci/pci-sysfs.c
Merging hid/for-next
CONFLICT (content): Merge conflict in drivers/hid/hid-input.c
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging hwmon-staging/hwmon-next
Merging quilt/kernel-doc
Merging v4l-dvb/master
Applying: media: const and __devinitdata do not mix
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/linux-next
Merging dlm/next
Merging swiotlb/master
Merging ibft/master
Merging scsi/master
Merging async_tx/next
Merging net/master
$ git reset --hard HEAD^
Merging refs/next/20101126/net
Merging wireless/master
Merging bluetooth/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging sound-asoc/for-next
Merging cpufreq/next
Merging quilt/rr
Merging input/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging mmc/mmc-next
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in drivers/mfd/wm8994-core.c
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging fbdev/master
Merging viafb/viafb-next
Merging omap_dss2/for-next
Merging voltage/for-next
Merging security-testing/next
Merging selinux/master
Merging lblnet/master
Merging agp/agp-next
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in drivers/scsi/bfa/bfa_fcpim.c
Merging audit/for-next
Merging suspend/linux-next
Merging fsnotify/for-next
Merging irda/for-next
Merging catalin/for-next
Merging alacrity/linux-next
CONFLICT (content): Merge conflict in include/linux/Kbuild
CONFLICT (content): Merge conflict in lib/Kconfig
Merging i7core_edac/linux_next
Merging i7300_edac/linux_next
Merging devicetree/next-devicetree
Merging spi/next-spi
Merging tip/auto-latest
Merging rcu/rcu/next
Merging oprofile/for-next
Merging xen/upstream/xen
Merging swiotlb-xen/master
Merging xen-pvhvm/linux-next
Merging edac-amd/for-next
Merging percpu/for-next
Merging workqueues/for-next
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
Merging sysctl/master
Merging driver-core/driver-core-next
Merging tty/tty-next
Merging usb/usb-next
Merging staging/staging-next
Merging slabh/slabh
Merging bkl-trivial/trivial
Merging bkl-llseek/llseek
Merging bkl-vfs/vfs
Merging bkl-config/config
CONFLICT (content): Merge conflict in arch/powerpc/kernel/setup_64.c
CONFLICT (content): Merge conflict in include/linux/hardirq.h
CONFLICT (content): Merge conflict in include/linux/smp_lock.h
Merging irqflags/master
Merging cleancache/linux-next
CONFLICT (content): Merge conflict in fs/ocfs2/super.c
CONFLICT (content): Merge conflict in include/linux/fs.h
CONFLICT (content): Merge conflict in mm/Kconfig
Merging scsi-post-merge/merge-base:master
Applying: Un-inline get_pipe_info() helper function
[master 85b5ba5] Revert "keys: add new key-type encrypted"
[master eac9151] Revert "keys: add new trusted key-type"
[master 2520dda] Revert "x86, nmi_watchdog: Remove all stub function calls from old nmi_watchdog"
[master 123045c] Revert "x86, nmi_watchdog: Remove the old nmi_watchdog"
[master bc45db3] Revert "perf, arch: Cleanup perf-pmu init vs lockup-detector"
Ave
2010/11/29 Stephen Rothwell <[email protected]>:
> Hi all,
>
> Changes since 20101126:
Setup is 14188 bytes (padded to 14336 bytes).
System is 1267 kB
CRC 61cea148
Kernel: arch/x86/boot/bzImage is ready (#1)
Building modules, stage 2.
MODPOST 537 modules
ERROR: "sock_no_mmap" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_no_getsockopt" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_no_setsockopt" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_no_shutdown" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_no_listen" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_no_ioctl" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_no_getname" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_no_accept" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_no_socketpair" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_no_connect" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_no_bind" [crypto/algif_skcipher.ko] undefined!
ERROR: "memcpy_fromiovec" [crypto/algif_skcipher.ko] undefined!
ERROR: "sk_free" [crypto/algif_skcipher.ko] undefined!
ERROR: "release_sock" [crypto/algif_skcipher.ko] undefined!
ERROR: "lock_sock_nested" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_kfree_s" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_kmalloc" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_wake_async" [crypto/algif_skcipher.ko] undefined!
ERROR: "sock_no_mmap" [crypto/algif_hash.ko] undefined!
ERROR: "sock_no_getsockopt" [crypto/algif_hash.ko] undefined!
ERROR: "sock_no_setsockopt" [crypto/algif_hash.ko] undefined!
ERROR: "sock_no_shutdown" [crypto/algif_hash.ko] undefined!
ERROR: "sock_no_listen" [crypto/algif_hash.ko] undefined!
ERROR: "sock_no_ioctl" [crypto/algif_hash.ko] undefined!
ERROR: "sock_no_poll" [crypto/algif_hash.ko] undefined!
ERROR: "sock_no_getname" [crypto/algif_hash.ko] undefined!
ERROR: "sock_no_socketpair" [crypto/algif_hash.ko] undefined!
ERROR: "sock_no_connect" [crypto/algif_hash.ko] undefined!
ERROR: "sock_no_bind" [crypto/algif_hash.ko] undefined!
ERROR: "sock_kfree_s" [crypto/algif_hash.ko] undefined!
ERROR: "sock_kmalloc" [crypto/algif_hash.ko] undefined!
ERROR: "sk_free" [crypto/algif_hash.ko] undefined!
ERROR: "memcpy_toiovec" [crypto/algif_hash.ko] undefined!
ERROR: "release_sock" [crypto/algif_hash.ko] undefined!
ERROR: "lock_sock_nested" [crypto/algif_hash.ko] undefined!
ERROR: "release_sock" [crypto/af_alg.ko] undefined!
ERROR: "sock_init_data" [crypto/af_alg.ko] undefined!
ERROR: "sock_no_getsockopt" [crypto/af_alg.ko] undefined!
ERROR: "sock_no_ioctl" [crypto/af_alg.ko] undefined!
ERROR: "sock_no_getname" [crypto/af_alg.ko] undefined!
ERROR: "sock_no_poll" [crypto/af_alg.ko] undefined!
ERROR: "sock_no_sendpage" [crypto/af_alg.ko] undefined!
ERROR: "sock_no_mmap" [crypto/af_alg.ko] undefined!
ERROR: "sock_no_recvmsg" [crypto/af_alg.ko] undefined!
ERROR: "sock_no_socketpair" [crypto/af_alg.ko] undefined!
ERROR: "sk_alloc" [crypto/af_alg.ko] undefined!
ERROR: "lock_sock_nested" [crypto/af_alg.ko] undefined!
ERROR: "sock_no_listen" [crypto/af_alg.ko] undefined!
ERROR: "sk_free" [crypto/af_alg.ko] undefined!
ERROR: "init_net" [crypto/af_alg.ko] undefined!
ERROR: "sock_kfree_s" [crypto/af_alg.ko] undefined!
ERROR: "sock_no_shutdown" [crypto/af_alg.ko] undefined!
ERROR: "proto_register" [crypto/af_alg.ko] undefined!
ERROR: "sock_register" [crypto/af_alg.ko] undefined!
ERROR: "proto_unregister" [crypto/af_alg.ko] undefined!
ERROR: "sock_kmalloc" [crypto/af_alg.ko] undefined!
ERROR: "sock_no_connect" [crypto/af_alg.ko] undefined!
ERROR: "sock_unregister" [crypto/af_alg.ko] undefined!
ERROR: "sock_no_sendmsg" [crypto/af_alg.ko] undefined!
WARNING: modpost: Found 16 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [sub-make] Error 2
--
Slawa!
Zimny "Spie dziadu!" Lech z Wawelu
That is not dead which can eternal lie.
And with strange aeons even death may die.
Salve!
2010/11/29 Stephen Rothwell <[email protected]>:
> Hi all,
>
> Changes since 20101126:
This crypto thing is pretty busted today
crypto/built-in.o: In function `alg_create':
af_alg.c:(.text+0x16c61): undefined reference to `sk_alloc'
af_alg.c:(.text+0x16c81): undefined reference to `sock_init_data'
crypto/built-in.o: In function `alg_setsockopt':
af_alg.c:(.text+0x16ccb): undefined reference to `lock_sock_nested'
af_alg.c:(.text+0x16d07): undefined reference to `sock_kmalloc'
af_alg.c:(.text+0x16d53): undefined reference to `sock_kfree_s'
af_alg.c:(.text+0x16d63): undefined reference to `release_sock'
crypto/built-in.o: In function `alg_bind':
af_alg.c:(.text+0x16e79): undefined reference to `lock_sock_nested'
af_alg.c:(.text+0x16ea3): undefined reference to `release_sock'
crypto/built-in.o: In function `af_alg_release':
(.text+0x16eda): undefined reference to `sk_free'
crypto/built-in.o: In function `af_alg_accept':
(.text+0x17083): undefined reference to `lock_sock_nested'
crypto/built-in.o: In function `af_alg_accept':
(.text+0x170ab): undefined reference to `init_net'
crypto/built-in.o: In function `af_alg_accept':
(.text+0x170b6): undefined reference to `sk_alloc'
crypto/built-in.o: In function `af_alg_accept':
(.text+0x170c9): undefined reference to `sock_init_data'
crypto/built-in.o: In function `af_alg_accept':
(.text+0x170e7): undefined reference to `sk_free'
crypto/built-in.o: In function `af_alg_accept':
(.text+0x1711b): undefined reference to `release_sock'
crypto/built-in.o: In function `skcipher_wait_for_wmem':
algif_skcipher.c:(.text+0x17471): undefined reference to `release_sock'
algif_skcipher.c:(.text+0x174b9): undefined reference to `lock_sock_nested'
crypto/built-in.o: In function `skcipher_alloc_sgl':
algif_skcipher.c:(.text+0x1755b): undefined reference to `sock_kmalloc'
crypto/built-in.o: In function `skcipher_data_wakeup':
algif_skcipher.c:(.text+0x176c9): undefined reference to `sock_wake_async'
crypto/built-in.o: In function `skcipher_sendpage':
algif_skcipher.c:(.text+0x1771b): undefined reference to `lock_sock_nested'
algif_skcipher.c:(.text+0x17809): undefined reference to `release_sock'
crypto/built-in.o: In function `skcipher_pull_sgl':
algif_skcipher.c:(.text+0x178e3): undefined reference to `sock_kfree_s'
crypto/built-in.o: In function `skcipher_recvmsg':
algif_skcipher.c:(.text+0x17955): undefined reference to `lock_sock_nested'
algif_skcipher.c:(.text+0x17a94): undefined reference to `release_sock'
algif_skcipher.c:(.text+0x17abd): undefined reference to `lock_sock_nested'
algif_skcipher.c:(.text+0x17d22): undefined reference to `sock_wake_async'
algif_skcipher.c:(.text+0x17d42): undefined reference to `release_sock'
crypto/built-in.o: In function `skcipher_sendmsg':
algif_skcipher.c:(.text+0x17dee): undefined reference to `lock_sock_nested'
algif_skcipher.c:(.text+0x17f00): undefined reference to `memcpy_fromiovec'
algif_skcipher.c:(.text+0x18056): undefined reference to `memcpy_fromiovec'
algif_skcipher.c:(.text+0x18102): undefined reference to `release_sock'
crypto/built-in.o: In function `skcipher_accept_parent':
algif_skcipher.c:(.text+0x1815c): undefined reference to `sock_kmalloc'
algif_skcipher.c:(.text+0x18179): undefined reference to `sock_kmalloc'
algif_skcipher.c:(.text+0x18196): undefined reference to `sock_kfree_s'
crypto/built-in.o: In function `skcipher_sock_destruct':
algif_skcipher.c:(.text+0x18284): undefined reference to `sock_kfree_s'
algif_skcipher.c:(.text+0x18297): undefined reference to `sock_kfree_s'
algif_skcipher.c:(.text+0x182ae): undefined reference to `sk_free'
crypto/built-in.o: In function `af_alg_init':
af_alg.c:(.init.text+0x440): undefined reference to `proto_register'
af_alg.c:(.init.text+0x450): undefined reference to `sock_register'
af_alg.c:(.init.text+0x465): undefined reference to `proto_unregister'
crypto/built-in.o: In function `af_alg_exit':
af_alg.c:(.exit.text+0x23d): undefined reference to `sock_unregister'
af_alg.c:(.exit.text+0x249): undefined reference to `proto_unregister'
crypto/built-in.o:(.rodata+0xec20): undefined reference to `sock_no_connect'
crypto/built-in.o:(.rodata+0xec28): undefined reference to `sock_no_socketpair'
crypto/built-in.o:(.rodata+0xec38): undefined reference to `sock_no_getname'
crypto/built-in.o:(.rodata+0xec40): undefined reference to `sock_no_poll'
crypto/built-in.o:(.rodata+0xec48): undefined reference to `sock_no_ioctl'
crypto/built-in.o:(.rodata+0xec50): undefined reference to `sock_no_listen'
crypto/built-in.o:(.rodata+0xec58): undefined reference to `sock_no_shutdown'
crypto/built-in.o:(.rodata+0xec68): undefined reference to `sock_no_getsockopt'
crypto/built-in.o:(.rodata+0xec70): undefined reference to `sock_no_sendmsg'
crypto/built-in.o:(.rodata+0xec78): undefined reference to `sock_no_recvmsg'
crypto/built-in.o:(.rodata+0xec80): undefined reference to `sock_no_mmap'
crypto/built-in.o:(.rodata+0xec88): undefined reference to `sock_no_sendpage'
crypto/built-in.o:(.data+0x2158): undefined reference to `sock_no_bind'
crypto/built-in.o:(.data+0x2160): undefined reference to `sock_no_connect'
crypto/built-in.o:(.data+0x2168): undefined reference to `sock_no_socketpair'
crypto/built-in.o:(.data+0x2170): undefined reference to `sock_no_accept'
crypto/built-in.o:(.data+0x2178): undefined reference to `sock_no_getname'
crypto/built-in.o:(.data+0x2188): undefined reference to `sock_no_ioctl'
crypto/built-in.o:(.data+0x2190): undefined reference to `sock_no_listen'
crypto/built-in.o:(.data+0x2198): undefined reference to `sock_no_shutdown'
crypto/built-in.o:(.data+0x21a0): undefined reference to `sock_no_setsockopt'
crypto/built-in.o:(.data+0x21a8): undefined reference to `sock_no_getsockopt'
crypto/built-in.o:(.data+0x21c0): undefined reference to `sock_no_mmap'
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2
--
Slawa!
Zimny "Spie dziadu!" Lech z Wawelu
That is not dead which can eternal lie.
And with strange aeons even death may die.
On Mon, Nov 29, 2010 at 09:47:38AM +0000, Zimny Lech wrote:
> Ave
>
> 2010/11/29 Stephen Rothwell <[email protected]>:
> > Hi all,
> >
> > Changes since 20101126:
>
>
> Setup is 14188 bytes (padded to 14336 bytes).
> System is 1267 kB
> CRC 61cea148
> Kernel: arch/x86/boot/bzImage is ready (#1)
> Building modules, stage 2.
> MODPOST 537 modules
> ERROR: "sock_no_mmap" [crypto/algif_skcipher.ko] undefined!
I hope this patch fixes it for you.
commit 7451708f39db19a8303bb7fb95f00aca9f673cb5
Author: Herbert Xu <[email protected]>
Date: Mon Nov 29 22:56:03 2010 +0800
crypto: af_alg - Add dependency on NET
Add missing dependency on NET since we require sockets for our
interface.
Should really be a select but kconfig doesn't like that:
net/Kconfig:6:error: found recursive dependency: NET -> NETWORK_FILESYSTEMS -> AFS_FS -> AF_RXRPC -> CRYPTO -> CRYPTO_USER_API_HASH -> CRYPTO_USER_API -> NET
Reported-by: Zimny Lech <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 467491d..96b0e55 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -848,6 +848,7 @@ config CRYPTO_USER_API
config CRYPTO_USER_API_HASH
tristate "User-space interface for hash algorithms"
+ depends on NET
select CRYPTO_HASH
select CRYPTO_USER_API
help
@@ -856,6 +857,7 @@ config CRYPTO_USER_API_HASH
config CRYPTO_USER_API_SKCIPHER
tristate "User-space interface for symmetric key cipher algorithms"
+ depends on NET
select CRYPTO_BLKCIPHER
select CRYPTO_USER_API
help
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Mon, 29 Nov 2010 22:57:17 +0800 Herbert Xu wrote:
> On Mon, Nov 29, 2010 at 09:47:38AM +0000, Zimny Lech wrote:
> > Ave
> >
> > 2010/11/29 Stephen Rothwell <[email protected]>:
> > > Hi all,
> > >
> > > Changes since 20101126:
> >
> >
> > Setup is 14188 bytes (padded to 14336 bytes).
> > System is 1267 kB
> > CRC 61cea148
> > Kernel: arch/x86/boot/bzImage is ready (#1)
> > Building modules, stage 2.
> > MODPOST 537 modules
> > ERROR: "sock_no_mmap" [crypto/algif_skcipher.ko] undefined!
>
> I hope this patch fixes it for you.
Acked-by: Randy Dunlap <[email protected]>
Thanks.
> commit 7451708f39db19a8303bb7fb95f00aca9f673cb5
> Author: Herbert Xu <[email protected]>
> Date: Mon Nov 29 22:56:03 2010 +0800
>
> crypto: af_alg - Add dependency on NET
>
> Add missing dependency on NET since we require sockets for our
> interface.
>
> Should really be a select but kconfig doesn't like that:
>
> net/Kconfig:6:error: found recursive dependency: NET -> NETWORK_FILESYSTEMS -> AFS_FS -> AF_RXRPC -> CRYPTO -> CRYPTO_USER_API_HASH -> CRYPTO_USER_API -> NET
>
> Reported-by: Zimny Lech <[email protected]>
> Signed-off-by: Herbert Xu <[email protected]>
>
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 467491d..96b0e55 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -848,6 +848,7 @@ config CRYPTO_USER_API
>
> config CRYPTO_USER_API_HASH
> tristate "User-space interface for hash algorithms"
> + depends on NET
> select CRYPTO_HASH
> select CRYPTO_USER_API
> help
> @@ -856,6 +857,7 @@ config CRYPTO_USER_API_HASH
>
> config CRYPTO_USER_API_SKCIPHER
> tristate "User-space interface for symmetric key cipher algorithms"
> + depends on NET
> select CRYPTO_BLKCIPHER
> select CRYPTO_USER_API
> help
>
> Thanks,
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20101126:
on i386 builds, I get tons of these (and more) errors:
arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
even though the kernel .config file says:
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_AES_NI_INTEL=m
Should arch/x86/crypto/aesni-intel_asm.S be testing
#ifdef CONFIG_X86_64
instead of
#ifdef __x86_64__
or does that not matter?
or is this a toolchain issue?
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 29.11.2010, 17:31 Randy Dunlap wrote:
> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20101126:
>
>
> on i386 builds, I get tons of these (and more) errors:
>
> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>
> even though the kernel .config file says:
>
> CONFIG_CRYPTO_AES=m
> CONFIG_CRYPTO_AES_586=m
> CONFIG_CRYPTO_AES_NI_INTEL=m
>
> Should arch/x86/crypto/aesni-intel_asm.S be testing
> #ifdef CONFIG_X86_64
> instead of
> #ifdef __x86_64__
> or does that not matter?
>
> or is this a toolchain issue?
Well, __x86_64__ should be a build-in define of the compiler while
CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
So by using the latter we should be on the safe side but if your compiler
defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
showed quite a few more places using __x86_64__ so those would miscompile on
your toolchain, too.
But it looks like linux-next is just missing
559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
That should fix the build issue.
Kind Regards,
Mathias
2010/11/29 Herbert Xu <[email protected]>:
> On Mon, Nov 29, 2010 at 09:47:38AM +0000, Zimny Lech wrote:
>> Ave
>>
>> 2010/11/29 Stephen Rothwell <[email protected]>:
>> > Hi all,
>> >
>> > Changes since 20101126:
>>
>>
>> Setup is 14188 bytes (padded to 14336 bytes).
>> System is 1267 kB
>> CRC 61cea148
>> Kernel: arch/x86/boot/bzImage is ready ?(#1)
>> ? Building modules, stage 2.
>> ? MODPOST 537 modules
>> ERROR: "sock_no_mmap" [crypto/algif_skcipher.ko] undefined!
>
> I hope this patch fixes it for you.
Thanks, I'll check it in tomorrows -next.
>
> commit 7451708f39db19a8303bb7fb95f00aca9f673cb5
> Author: Herbert Xu <[email protected]>
> Date: ? Mon Nov 29 22:56:03 2010 +0800
>
> ? ?crypto: af_alg - Add dependency on NET
>
> ? ?Add missing dependency on NET since we require sockets for our
> ? ?interface.
>
> ? ?Should really be a select but kconfig doesn't like that:
>
> ? ?net/Kconfig:6:error: found recursive dependency: NET -> NETWORK_FILESYSTEMS -> AFS_FS -> AF_RXRPC -> CRYPTO -> CRYPTO_USER_API_HASH -> CRYPTO_USER_API -> NET
>
> ? ?Reported-by: Zimny Lech <[email protected]>
> ? ?Signed-off-by: Herbert Xu <[email protected]>
>
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 467491d..96b0e55 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -848,6 +848,7 @@ config CRYPTO_USER_API
>
> ?config CRYPTO_USER_API_HASH
> ? ? ? ?tristate "User-space interface for hash algorithms"
> + ? ? ? depends on NET
> ? ? ? ?select CRYPTO_HASH
> ? ? ? ?select CRYPTO_USER_API
> ? ? ? ?help
> @@ -856,6 +857,7 @@ config CRYPTO_USER_API_HASH
>
> ?config CRYPTO_USER_API_SKCIPHER
> ? ? ? ?tristate "User-space interface for symmetric key cipher algorithms"
> + ? ? ? depends on NET
> ? ? ? ?select CRYPTO_BLKCIPHER
> ? ? ? ?select CRYPTO_USER_API
> ? ? ? ?help
>
> Thanks,
> --
> Email: Herbert Xu <[email protected]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
--
Slawa!
Zimny "Spie dziadu!" Lech z Wawelu
That is not dead which can eternal lie.
And with strange aeons even death may die.
On 11/29/10 10:26, Mathias Krause wrote:
> On 29.11.2010, 17:31 Randy Dunlap wrote:
>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Changes since 20101126:
>>
>>
>> on i386 builds, I get tons of these (and more) errors:
>>
>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>
>> even though the kernel .config file says:
>>
>> CONFIG_CRYPTO_AES=m
>> CONFIG_CRYPTO_AES_586=m
>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>
>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>> #ifdef CONFIG_X86_64
>> instead of
>> #ifdef __x86_64__
>> or does that not matter?
>>
>> or is this a toolchain issue?
>
> Well, __x86_64__ should be a build-in define of the compiler while
> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
> So by using the latter we should be on the safe side but if your compiler
> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
> showed quite a few more places using __x86_64__ so those would miscompile on
> your toolchain, too.
>
> But it looks like linux-next is just missing
> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
> That should fix the build issue.
The build problem still happens when that patch is applied.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 29.11.2010, 19:54 Randy Dunlap wrote:
> On 11/29/10 10:26, Mathias Krause wrote:
>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>
>>>> Hi all,
>>>>
>>>> Changes since 20101126:
>>>
>>>
>>> on i386 builds, I get tons of these (and more) errors:
>>>
>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>
>>> even though the kernel .config file says:
>>>
>>> CONFIG_CRYPTO_AES=m
>>> CONFIG_CRYPTO_AES_586=m
>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>
>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>> #ifdef CONFIG_X86_64
>>> instead of
>>> #ifdef __x86_64__
>>> or does that not matter?
>>>
>>> or is this a toolchain issue?
>>
>> Well, __x86_64__ should be a build-in define of the compiler while
>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>> So by using the latter we should be on the safe side but if your compiler
>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>> showed quite a few more places using __x86_64__ so those would miscompile on
>> your toolchain, too.
>>
>> But it looks like linux-next is just missing
>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>> That should fix the build issue.
>
> The build problem still happens when that patch is applied.
That's weird. So it must be something with your toolchain.
Can you please post the output of the following commands?:
$ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
$ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
Beside that, the patch below should fix the issue with your toolchain by using
CONFIG_X86_64 instead of __x86_64__.
Sorry for the inconvenience,
Mathias
[PATCH] crypto: aesni-intel - Fixed another build error on x86-32
It looks like not all compilers undef __x86_64__ for 32-bit builds so
switch to CONFIG_X86_64 to test if we're building for 64 or 32 bit.
Signed-off-by: Mathias Krause <[email protected]>
---
arch/x86/crypto/aesni-intel_asm.S | 40 ++++++++++++++++++------------------
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S
index d528fde..de0ec32 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -32,7 +32,7 @@
#include <linux/linkage.h>
#include <asm/inst.h>
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
.data
POLY: .octa 0xC2000000000000000000000000000001
TWOONE: .octa 0x00000001000000000000000000000001
@@ -105,7 +105,7 @@ enc: .octa 0x2
#define CTR %xmm11
#define INC %xmm12
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
#define AREG %rax
#define KEYP %rdi
#define OUTP %rsi
@@ -132,7 +132,7 @@ enc: .octa 0x2
#endif
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
/* GHASH_MUL MACRO to implement: Data*HashKey mod (128,127,126,121,0)
*
*
@@ -1333,7 +1333,7 @@ _key_expansion_256b:
* unsigned int key_len)
*/
ENTRY(aesni_set_key)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl KEYP
movl 8(%esp), KEYP # ctx
movl 12(%esp), UKEYP # in_key
@@ -1435,7 +1435,7 @@ ENTRY(aesni_set_key)
cmp TKEYP, KEYP
jb .Ldec_key_loop
xor AREG, AREG
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KEYP
#endif
ret
@@ -1444,7 +1444,7 @@ ENTRY(aesni_set_key)
* void aesni_enc(struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
*/
ENTRY(aesni_enc)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl KEYP
pushl KLEN
movl 12(%esp), KEYP
@@ -1455,7 +1455,7 @@ ENTRY(aesni_enc)
movups (INP), STATE # input
call _aesni_enc1
movups STATE, (OUTP) # output
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
#endif
@@ -1630,7 +1630,7 @@ _aesni_enc4:
* void aesni_dec (struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
*/
ENTRY(aesni_dec)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl KEYP
pushl KLEN
movl 12(%esp), KEYP
@@ -1642,7 +1642,7 @@ ENTRY(aesni_dec)
movups (INP), STATE # input
call _aesni_dec1
movups STATE, (OUTP) #output
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
#endif
@@ -1818,7 +1818,7 @@ _aesni_dec4:
* size_t len)
*/
ENTRY(aesni_ecb_enc)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl LEN
pushl KEYP
pushl KLEN
@@ -1863,7 +1863,7 @@ ENTRY(aesni_ecb_enc)
cmp $16, LEN
jge .Lecb_enc_loop1
.Lecb_enc_ret:
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
popl LEN
@@ -1875,7 +1875,7 @@ ENTRY(aesni_ecb_enc)
* size_t len);
*/
ENTRY(aesni_ecb_dec)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl LEN
pushl KEYP
pushl KLEN
@@ -1921,7 +1921,7 @@ ENTRY(aesni_ecb_dec)
cmp $16, LEN
jge .Lecb_dec_loop1
.Lecb_dec_ret:
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
popl LEN
@@ -1933,7 +1933,7 @@ ENTRY(aesni_ecb_dec)
* size_t len, u8 *iv)
*/
ENTRY(aesni_cbc_enc)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl IVP
pushl LEN
pushl KEYP
@@ -1961,7 +1961,7 @@ ENTRY(aesni_cbc_enc)
jge .Lcbc_enc_loop
movups STATE, (IVP)
.Lcbc_enc_ret:
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
popl LEN
@@ -1974,7 +1974,7 @@ ENTRY(aesni_cbc_enc)
* size_t len, u8 *iv)
*/
ENTRY(aesni_cbc_dec)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl IVP
pushl LEN
pushl KEYP
@@ -1998,7 +1998,7 @@ ENTRY(aesni_cbc_dec)
movaps IN1, STATE1
movups 0x10(INP), IN2
movaps IN2, STATE2
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
movups 0x20(INP), IN3
movaps IN3, STATE3
movups 0x30(INP), IN4
@@ -2011,7 +2011,7 @@ ENTRY(aesni_cbc_dec)
#endif
call _aesni_dec4
pxor IV, STATE1
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
pxor IN1, STATE2
pxor IN2, STATE3
pxor IN3, STATE4
@@ -2049,7 +2049,7 @@ ENTRY(aesni_cbc_dec)
.Lcbc_dec_ret:
movups IV, (IVP)
.Lcbc_dec_just_ret:
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
popl LEN
@@ -2057,7 +2057,7 @@ ENTRY(aesni_cbc_dec)
#endif
ret
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
.align 16
.Lbswap_mask:
.byte 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0
--
1.5.6.5
On 11/29/10 11:21, Mathias Krause wrote:
> On 29.11.2010, 19:54 Randy Dunlap wrote:
>> On 11/29/10 10:26, Mathias Krause wrote:
>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Changes since 20101126:
>>>>
>>>>
>>>> on i386 builds, I get tons of these (and more) errors:
>>>>
>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>
>>>> even though the kernel .config file says:
>>>>
>>>> CONFIG_CRYPTO_AES=m
>>>> CONFIG_CRYPTO_AES_586=m
>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>
>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>> #ifdef CONFIG_X86_64
>>>> instead of
>>>> #ifdef __x86_64__
>>>> or does that not matter?
>>>>
>>>> or is this a toolchain issue?
>>>
>>> Well, __x86_64__ should be a build-in define of the compiler while
>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>> So by using the latter we should be on the safe side but if your compiler
>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>> your toolchain, too.
>>>
>>> But it looks like linux-next is just missing
>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>> That should fix the build issue.
>>
>> The build problem still happens when that patch is applied.
>
> That's weird. So it must be something with your toolchain.
> Can you please post the output of the following commands?:
>
> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
#define __i386 1
#define __i386__ 1
#define i386 1
#define __i586 1
#define __i586__ 1
> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
#define __x86_64 1
#define __x86_64__ 1
So that's not the problem... and the patch below didn't help.
Sorry that I even asked about that. What next?
> Beside that, the patch below should fix the issue with your toolchain by using
> CONFIG_X86_64 instead of __x86_64__.
>
> Sorry for the inconvenience,
> Mathias
>
> [PATCH] crypto: aesni-intel - Fixed another build error on x86-32
>
> It looks like not all compilers undef __x86_64__ for 32-bit builds so
> switch to CONFIG_X86_64 to test if we're building for 64 or 32 bit.
>
> Signed-off-by: Mathias Krause <[email protected]>
> ---
> arch/x86/crypto/aesni-intel_asm.S | 40 ++++++++++++++++++------------------
> 1 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S
> index d528fde..de0ec32 100644
> --- a/arch/x86/crypto/aesni-intel_asm.S
> +++ b/arch/x86/crypto/aesni-intel_asm.S
> @@ -32,7 +32,7 @@
> #include <linux/linkage.h>
> #include <asm/inst.h>
>
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> .data
> POLY: .octa 0xC2000000000000000000000000000001
> TWOONE: .octa 0x00000001000000000000000000000001
> @@ -105,7 +105,7 @@ enc: .octa 0x2
> #define CTR %xmm11
> #define INC %xmm12
>
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> #define AREG %rax
> #define KEYP %rdi
> #define OUTP %rsi
> @@ -132,7 +132,7 @@ enc: .octa 0x2
> #endif
>
>
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> /* GHASH_MUL MACRO to implement: Data*HashKey mod (128,127,126,121,0)
> *
> *
> @@ -1333,7 +1333,7 @@ _key_expansion_256b:
> * unsigned int key_len)
> */
> ENTRY(aesni_set_key)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl KEYP
> movl 8(%esp), KEYP # ctx
> movl 12(%esp), UKEYP # in_key
> @@ -1435,7 +1435,7 @@ ENTRY(aesni_set_key)
> cmp TKEYP, KEYP
> jb .Ldec_key_loop
> xor AREG, AREG
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KEYP
> #endif
> ret
> @@ -1444,7 +1444,7 @@ ENTRY(aesni_set_key)
> * void aesni_enc(struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
> */
> ENTRY(aesni_enc)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl KEYP
> pushl KLEN
> movl 12(%esp), KEYP
> @@ -1455,7 +1455,7 @@ ENTRY(aesni_enc)
> movups (INP), STATE # input
> call _aesni_enc1
> movups STATE, (OUTP) # output
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> #endif
> @@ -1630,7 +1630,7 @@ _aesni_enc4:
> * void aesni_dec (struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
> */
> ENTRY(aesni_dec)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl KEYP
> pushl KLEN
> movl 12(%esp), KEYP
> @@ -1642,7 +1642,7 @@ ENTRY(aesni_dec)
> movups (INP), STATE # input
> call _aesni_dec1
> movups STATE, (OUTP) #output
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> #endif
> @@ -1818,7 +1818,7 @@ _aesni_dec4:
> * size_t len)
> */
> ENTRY(aesni_ecb_enc)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl LEN
> pushl KEYP
> pushl KLEN
> @@ -1863,7 +1863,7 @@ ENTRY(aesni_ecb_enc)
> cmp $16, LEN
> jge .Lecb_enc_loop1
> .Lecb_enc_ret:
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> popl LEN
> @@ -1875,7 +1875,7 @@ ENTRY(aesni_ecb_enc)
> * size_t len);
> */
> ENTRY(aesni_ecb_dec)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl LEN
> pushl KEYP
> pushl KLEN
> @@ -1921,7 +1921,7 @@ ENTRY(aesni_ecb_dec)
> cmp $16, LEN
> jge .Lecb_dec_loop1
> .Lecb_dec_ret:
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> popl LEN
> @@ -1933,7 +1933,7 @@ ENTRY(aesni_ecb_dec)
> * size_t len, u8 *iv)
> */
> ENTRY(aesni_cbc_enc)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl IVP
> pushl LEN
> pushl KEYP
> @@ -1961,7 +1961,7 @@ ENTRY(aesni_cbc_enc)
> jge .Lcbc_enc_loop
> movups STATE, (IVP)
> .Lcbc_enc_ret:
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> popl LEN
> @@ -1974,7 +1974,7 @@ ENTRY(aesni_cbc_enc)
> * size_t len, u8 *iv)
> */
> ENTRY(aesni_cbc_dec)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl IVP
> pushl LEN
> pushl KEYP
> @@ -1998,7 +1998,7 @@ ENTRY(aesni_cbc_dec)
> movaps IN1, STATE1
> movups 0x10(INP), IN2
> movaps IN2, STATE2
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> movups 0x20(INP), IN3
> movaps IN3, STATE3
> movups 0x30(INP), IN4
> @@ -2011,7 +2011,7 @@ ENTRY(aesni_cbc_dec)
> #endif
> call _aesni_dec4
> pxor IV, STATE1
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> pxor IN1, STATE2
> pxor IN2, STATE3
> pxor IN3, STATE4
> @@ -2049,7 +2049,7 @@ ENTRY(aesni_cbc_dec)
> .Lcbc_dec_ret:
> movups IV, (IVP)
> .Lcbc_dec_just_ret:
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> popl LEN
> @@ -2057,7 +2057,7 @@ ENTRY(aesni_cbc_dec)
> #endif
> ret
>
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> .align 16
> .Lbswap_mask:
> .byte 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 29.11.2010, 20:31 Randy Dunlap wrote:
> On 11/29/10 11:21, Mathias Krause wrote:
>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Changes since 20101126:
>>>>>
>>>>>
>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>
>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>
>>>>> even though the kernel .config file says:
>>>>>
>>>>> CONFIG_CRYPTO_AES=m
>>>>> CONFIG_CRYPTO_AES_586=m
>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>
>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>> #ifdef CONFIG_X86_64
>>>>> instead of
>>>>> #ifdef __x86_64__
>>>>> or does that not matter?
>>>>>
>>>>> or is this a toolchain issue?
>>>>
>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>> So by using the latter we should be on the safe side but if your compiler
>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>> your toolchain, too.
>>>>
>>>> But it looks like linux-next is just missing
>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>> That should fix the build issue.
>>>
>>> The build problem still happens when that patch is applied.
>>
>> That's weird. So it must be something with your toolchain.
>> Can you please post the output of the following commands?:
>>
>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>
> #define __i386 1
> #define __i386__ 1
> #define i386 1
> #define __i586 1
> #define __i586__ 1
>
>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>
> #define __x86_64 1
> #define __x86_64__ 1
>
> So that's not the problem... and the patch below didn't help.
That's odd. The output of the commands looks good so the x86-64 specific code
should be left out for 32-bit builds. :/
> Sorry that I even asked about that. What next?
Can you please post the full error message. Meanwhile I'm checking out a
linux-next tree, trying to reproduce your problem.
On 29.11.2010, 20:31 Randy Dunlap wrote:
> On 11/29/10 11:21, Mathias Krause wrote:
>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Changes since 20101126:
>>>>>
>>>>>
>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>
>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>
>>>>> even though the kernel .config file says:
>>>>>
>>>>> CONFIG_CRYPTO_AES=m
>>>>> CONFIG_CRYPTO_AES_586=m
>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>
>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>> #ifdef CONFIG_X86_64
>>>>> instead of
>>>>> #ifdef __x86_64__
>>>>> or does that not matter?
>>>>>
>>>>> or is this a toolchain issue?
>>>>
>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>> So by using the latter we should be on the safe side but if your compiler
>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>> your toolchain, too.
>>>>
>>>> But it looks like linux-next is just missing
>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>> That should fix the build issue.
>>>
>>> The build problem still happens when that patch is applied.
>>
>> That's weird. So it must be something with your toolchain.
>> Can you please post the output of the following commands?:
>>
>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>
> #define __i386 1
> #define __i386__ 1
> #define i386 1
> #define __i586 1
> #define __i586__ 1
>
>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>
> #define __x86_64 1
> #define __x86_64__ 1
>
> So that's not the problem... and the patch below didn't help.
> Sorry that I even asked about that. What next?
Sorry, I cannot reproduce the problem with the latest linux-next and commit
559ad0ff1368baea14dbc3207d55b02bd69bda4b from cryptodev-2.6 applied. Please
ensure you've applied that patch.
Regards,
Mathias-
On 11/29/10 11:45, Mathias Krause wrote:
> On 29.11.2010, 20:31 Randy Dunlap wrote:
>> On 11/29/10 11:21, Mathias Krause wrote:
>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Changes since 20101126:
>>>>>>
>>>>>>
>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>
>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>
>>>>>> even though the kernel .config file says:
>>>>>>
>>>>>> CONFIG_CRYPTO_AES=m
>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>
>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>> #ifdef CONFIG_X86_64
>>>>>> instead of
>>>>>> #ifdef __x86_64__
>>>>>> or does that not matter?
>>>>>>
>>>>>> or is this a toolchain issue?
>>>>>
>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>> your toolchain, too.
>>>>>
>>>>> But it looks like linux-next is just missing
>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>> That should fix the build issue.
>>>>
>>>> The build problem still happens when that patch is applied.
>>>
>>> That's weird. So it must be something with your toolchain.
>>> Can you please post the output of the following commands?:
>>>
>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>
>> #define __i386 1
>> #define __i386__ 1
>> #define i386 1
>> #define __i586 1
>> #define __i586__ 1
>>
>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>
>> #define __x86_64 1
>> #define __x86_64__ 1
>>
>> So that's not the problem... and the patch below didn't help.
>
> That's odd. The output of the commands looks good so the x86-64 specific code
> should be left out for 32-bit builds. :/
>
>> Sorry that I even asked about that. What next?
>
> Can you please post the full error message. Meanwhile I'm checking out a
> linux-next tree, trying to reproduce your problem.
>
I just built with "make V=1" to see the full commands that are used, but
that didn't help me either:
gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
There are 2945 lines like this:
linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
It's around 311 KB, so I'll just put it here instead of emailing it:
http://oss.oracle.com/~rdunlap/doc/cry32.out
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 11/29/10 11:52, Mathias Krause wrote:
> On 29.11.2010, 20:31 Randy Dunlap wrote:
>> On 11/29/10 11:21, Mathias Krause wrote:
>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Changes since 20101126:
>>>>>>
>>>>>>
>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>
>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>
>>>>>> even though the kernel .config file says:
>>>>>>
>>>>>> CONFIG_CRYPTO_AES=m
>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>
>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>> #ifdef CONFIG_X86_64
>>>>>> instead of
>>>>>> #ifdef __x86_64__
>>>>>> or does that not matter?
>>>>>>
>>>>>> or is this a toolchain issue?
>>>>>
>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>> your toolchain, too.
>>>>>
>>>>> But it looks like linux-next is just missing
>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>> That should fix the build issue.
>>>>
>>>> The build problem still happens when that patch is applied.
>>>
>>> That's weird. So it must be something with your toolchain.
>>> Can you please post the output of the following commands?:
>>>
>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>
>> #define __i386 1
>> #define __i386__ 1
>> #define i386 1
>> #define __i586 1
>> #define __i586__ 1
>>
>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>
>> #define __x86_64 1
>> #define __x86_64__ 1
>>
>> So that's not the problem... and the patch below didn't help.
>> Sorry that I even asked about that. What next?
>
> Sorry, I cannot reproduce the problem with the latest linux-next and commit
> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from cryptodev-2.6 applied. Please
> ensure you've applied that patch.
OK, thanks for trying.
Yes, I have applied that patch.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 29.11.2010, 20:54 Randy Dunlap wrote:
> On 11/29/10 11:45, Mathias Krause wrote:
>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Changes since 20101126:
>>>>>>>
>>>>>>>
>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>
>>>>>>> even though the kernel .config file says:
>>>>>>>
>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>
>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>> #ifdef CONFIG_X86_64
>>>>>>> instead of
>>>>>>> #ifdef __x86_64__
>>>>>>> or does that not matter?
>>>>>>>
>>>>>>> or is this a toolchain issue?
>>>>>>
>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>> your toolchain, too.
>>>>>>
>>>>>> But it looks like linux-next is just missing
>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>> That should fix the build issue.
>>>>>
>>>>> The build problem still happens when that patch is applied.
>>>>
>>>> That's weird. So it must be something with your toolchain.
>>>> Can you please post the output of the following commands?:
>>>>
>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>
>>> #define __i386 1
>>> #define __i386__ 1
>>> #define i386 1
>>> #define __i586 1
>>> #define __i586__ 1
>>>
>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>
>>> #define __x86_64 1
>>> #define __x86_64__ 1
>>>
>>> So that's not the problem... and the patch below didn't help.
>>
>> That's odd. The output of the commands looks good so the x86-64 specific code
>> should be left out for 32-bit builds. :/
>>
>>> Sorry that I even asked about that. What next?
>>
>> Can you please post the full error message. Meanwhile I'm checking out a
>> linux-next tree, trying to reproduce your problem.
>>
>
> I just built with "make V=1" to see the full commands that are used, but
> that didn't help me either:
>
> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>
>
> There are 2945 lines like this:
>
> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
more to be sure. ;)
> It's around 311 KB, so I'll just put it here instead of emailing it:
> http://oss.oracle.com/~rdunlap/doc/cry32.out
>
> --
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
On 11/29/10 12:02, Mathias Krause wrote:
> On 29.11.2010, 20:54 Randy Dunlap wrote:
>> On 11/29/10 11:45, Mathias Krause wrote:
>>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Changes since 20101126:
>>>>>>>>
>>>>>>>>
>>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>>
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>>
>>>>>>>> even though the kernel .config file says:
>>>>>>>>
>>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>>
>>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>>> #ifdef CONFIG_X86_64
>>>>>>>> instead of
>>>>>>>> #ifdef __x86_64__
>>>>>>>> or does that not matter?
>>>>>>>>
>>>>>>>> or is this a toolchain issue?
>>>>>>>
>>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>>> your toolchain, too.
>>>>>>>
>>>>>>> But it looks like linux-next is just missing
>>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>>> That should fix the build issue.
>>>>>>
>>>>>> The build problem still happens when that patch is applied.
>>>>>
>>>>> That's weird. So it must be something with your toolchain.
>>>>> Can you please post the output of the following commands?:
>>>>>
>>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>
>>>> #define __i386 1
>>>> #define __i386__ 1
>>>> #define i386 1
>>>> #define __i586 1
>>>> #define __i586__ 1
>>>>
>>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>
>>>> #define __x86_64 1
>>>> #define __x86_64__ 1
>>>>
>>>> So that's not the problem... and the patch below didn't help.
>>>
>>> That's odd. The output of the commands looks good so the x86-64 specific code
>>> should be left out for 32-bit builds. :/
>>>
>>>> Sorry that I even asked about that. What next?
>>>
>>> Can you please post the full error message. Meanwhile I'm checking out a
>>> linux-next tree, trying to reproduce your problem.
>>>
>>
>> I just built with "make V=1" to see the full commands that are used, but
>> that didn't help me either:
>>
>> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>>
>>
>> There are 2945 lines like this:
>>
>> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>
> Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
> 559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
> more to be sure. ;)
Touche.
What does that patch have to do with aesni-intel??
I'm using the linux-next tarball of 20111129.
However, your s/__x86_64__/CONFIG_X86_64/ patch was applied, so I dropped it.
new output file:
http://oss.oracle.com/~rdunlap/doc/cry4.out
>> It's around 311 KB, so I'll just put it here instead of emailing it:
>> http://oss.oracle.com/~rdunlap/doc/cry32.out
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 29.11.2010, 21:11 Randy Dunlap wrote:
> On 11/29/10 12:02, Mathias Krause wrote:
>> On 29.11.2010, 20:54 Randy Dunlap wrote:
>>> On 11/29/10 11:45, Mathias Krause wrote:
>>>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Changes since 20101126:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>>>
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>>>
>>>>>>>>> even though the kernel .config file says:
>>>>>>>>>
>>>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>>>
>>>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>>>> #ifdef CONFIG_X86_64
>>>>>>>>> instead of
>>>>>>>>> #ifdef __x86_64__
>>>>>>>>> or does that not matter?
>>>>>>>>>
>>>>>>>>> or is this a toolchain issue?
>>>>>>>>
>>>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>>>> your toolchain, too.
>>>>>>>>
>>>>>>>> But it looks like linux-next is just missing
>>>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>>>> That should fix the build issue.
>>>>>>>
>>>>>>> The build problem still happens when that patch is applied.
>>>>>>
>>>>>> That's weird. So it must be something with your toolchain.
>>>>>> Can you please post the output of the following commands?:
>>>>>>
>>>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>
>>>>> #define __i386 1
>>>>> #define __i386__ 1
>>>>> #define i386 1
>>>>> #define __i586 1
>>>>> #define __i586__ 1
>>>>>
>>>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>
>>>>> #define __x86_64 1
>>>>> #define __x86_64__ 1
>>>>>
>>>>> So that's not the problem... and the patch below didn't help.
>>>>
>>>> That's odd. The output of the commands looks good so the x86-64 specific code
>>>> should be left out for 32-bit builds. :/
>>>>
>>>>> Sorry that I even asked about that. What next?
>>>>
>>>> Can you please post the full error message. Meanwhile I'm checking out a
>>>> linux-next tree, trying to reproduce your problem.
>>>>
>>>
>>> I just built with "make V=1" to see the full commands that are used, but
>>> that didn't help me either:
>>>
>>> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>>>
>>>
>>> There are 2945 lines like this:
>>>
>>> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>
>> Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
>> 559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
>> more to be sure. ;)
>
> Touche.
> What does that patch have to do with aesni-intel??
The description should be clear enough: "crypto: aesni-intel - Fixed build error
on x86-32".
Here is the link to the patch: <http://git.kernel.org/?p=linux/kernel/git/herbert/cryptodev-2.6.git;a=patch;h=559ad0ff1368baea14dbc3207d55b02bd69bda4b>. Please apply it on
top of your linux-next build.
> I'm using the linux-next tarball of 20111129.
> However, your s/__x86_64__/CONFIG_X86_64/ patch was applied, so I dropped it.
Well I doubt it. The patch was made on top of 559ad0ff so it should have failed
to apply in your tree since obviously 559ad0ff is missing.
> new output file:
> http://oss.oracle.com/~rdunlap/doc/cry4.out
Same bug: 559ad0ff is still missing. Please apply the patch from the link above.
On 11/29/10 12:21, Mathias Krause wrote:
> On 29.11.2010, 21:11 Randy Dunlap wrote:
>> On 11/29/10 12:02, Mathias Krause wrote:
>>> On 29.11.2010, 20:54 Randy Dunlap wrote:
>>>> On 11/29/10 11:45, Mathias Krause wrote:
>>>>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>>>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Changes since 20101126:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>>>>
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>>>>
>>>>>>>>>> even though the kernel .config file says:
>>>>>>>>>>
>>>>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>>>>
>>>>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>>>>> #ifdef CONFIG_X86_64
>>>>>>>>>> instead of
>>>>>>>>>> #ifdef __x86_64__
>>>>>>>>>> or does that not matter?
>>>>>>>>>>
>>>>>>>>>> or is this a toolchain issue?
>>>>>>>>>
>>>>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>>>>> your toolchain, too.
>>>>>>>>>
>>>>>>>>> But it looks like linux-next is just missing
>>>>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>>>>> That should fix the build issue.
>>>>>>>>
>>>>>>>> The build problem still happens when that patch is applied.
>>>>>>>
>>>>>>> That's weird. So it must be something with your toolchain.
>>>>>>> Can you please post the output of the following commands?:
>>>>>>>
>>>>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>>
>>>>>> #define __i386 1
>>>>>> #define __i386__ 1
>>>>>> #define i386 1
>>>>>> #define __i586 1
>>>>>> #define __i586__ 1
>>>>>>
>>>>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>>
>>>>>> #define __x86_64 1
>>>>>> #define __x86_64__ 1
>>>>>>
>>>>>> So that's not the problem... and the patch below didn't help.
>>>>>
>>>>> That's odd. The output of the commands looks good so the x86-64 specific code
>>>>> should be left out for 32-bit builds. :/
>>>>>
>>>>>> Sorry that I even asked about that. What next?
>>>>>
>>>>> Can you please post the full error message. Meanwhile I'm checking out a
>>>>> linux-next tree, trying to reproduce your problem.
>>>>>
>>>>
>>>> I just built with "make V=1" to see the full commands that are used, but
>>>> that didn't help me either:
>>>>
>>>> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>>>>
>>>>
>>>> There are 2945 lines like this:
>>>>
>>>> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>
>>> Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
>>> 559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
>>> more to be sure. ;)
>>
>> Touche.
>> What does that patch have to do with aesni-intel??
>
> The description should be clear enough: "crypto: aesni-intel - Fixed build error
> on x86-32".
> Here is the link to the patch: <http://git.kernel.org/?p=linux/kernel/git/herbert/cryptodev-2.6.git;a=patch;h=559ad0ff1368baea14dbc3207d55b02bd69bda4b>. Please apply it on
> top of your linux-next build.
>
>> I'm using the linux-next tarball of 20111129.
>> However, your s/__x86_64__/CONFIG_X86_64/ patch was applied, so I dropped it.
>
> Well I doubt it. The patch was made on top of 559ad0ff so it should have failed
> to apply in your tree since obviously 559ad0ff is missing.
>
>> new output file:
>> http://oss.oracle.com/~rdunlap/doc/cry4.out
>
> Same bug: 559ad0ff is still missing. Please apply the patch from the link above.
Thanks for persisting/continuing with me.
I apologize, I had applied the most recent patch in Herbert's cryptodev repo,
not the one that you referred me to.
Yes, the build is now fixed.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 29.11.2010, 21:37 Randy Dunlap wrote:
> On 11/29/10 12:21, Mathias Krause wrote:
>> On 29.11.2010, 21:11 Randy Dunlap wrote:
>>> On 11/29/10 12:02, Mathias Krause wrote:
>>>> On 29.11.2010, 20:54 Randy Dunlap wrote:
>>>>> On 11/29/10 11:45, Mathias Krause wrote:
>>>>>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>>>>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>>>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> Changes since 20101126:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>>>>>
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>>>>>
>>>>>>>>>>> even though the kernel .config file says:
>>>>>>>>>>>
>>>>>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>>>>>
>>>>>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>>>>>> #ifdef CONFIG_X86_64
>>>>>>>>>>> instead of
>>>>>>>>>>> #ifdef __x86_64__
>>>>>>>>>>> or does that not matter?
>>>>>>>>>>>
>>>>>>>>>>> or is this a toolchain issue?
>>>>>>>>>>
>>>>>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>>>>>> your toolchain, too.
>>>>>>>>>>
>>>>>>>>>> But it looks like linux-next is just missing
>>>>>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>>>>>> That should fix the build issue.
>>>>>>>>>
>>>>>>>>> The build problem still happens when that patch is applied.
>>>>>>>>
>>>>>>>> That's weird. So it must be something with your toolchain.
>>>>>>>> Can you please post the output of the following commands?:
>>>>>>>>
>>>>>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>>>
>>>>>>> #define __i386 1
>>>>>>> #define __i386__ 1
>>>>>>> #define i386 1
>>>>>>> #define __i586 1
>>>>>>> #define __i586__ 1
>>>>>>>
>>>>>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>>>
>>>>>>> #define __x86_64 1
>>>>>>> #define __x86_64__ 1
>>>>>>>
>>>>>>> So that's not the problem... and the patch below didn't help.
>>>>>>
>>>>>> That's odd. The output of the commands looks good so the x86-64 specific code
>>>>>> should be left out for 32-bit builds. :/
>>>>>>
>>>>>>> Sorry that I even asked about that. What next?
>>>>>>
>>>>>> Can you please post the full error message. Meanwhile I'm checking out a
>>>>>> linux-next tree, trying to reproduce your problem.
>>>>>>
>>>>>
>>>>> I just built with "make V=1" to see the full commands that are used, but
>>>>> that didn't help me either:
>>>>>
>>>>> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>>>>>
>>>>>
>>>>> There are 2945 lines like this:
>>>>>
>>>>> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>
>>>> Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
>>>> 559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
>>>> more to be sure. ;)
>>>
>>> Touche.
>>> What does that patch have to do with aesni-intel??
>>
>> The description should be clear enough: "crypto: aesni-intel - Fixed build error
>> on x86-32".
>> Here is the link to the patch: <http://git.kernel.org/?p=linux/kernel/git/herbert/cryptodev-2.6.git;a=patch;h=559ad0ff1368baea14dbc3207d55b02bd69bda4b>. Please apply it on
>> top of your linux-next build.
>>
>>> I'm using the linux-next tarball of 20111129.
>>> However, your s/__x86_64__/CONFIG_X86_64/ patch was applied, so I dropped it.
>>
>> Well I doubt it. The patch was made on top of 559ad0ff so it should have failed
>> to apply in your tree since obviously 559ad0ff is missing.
>>
>>> new output file:
>>> http://oss.oracle.com/~rdunlap/doc/cry4.out
>>
>> Same bug: 559ad0ff is still missing. Please apply the patch from the link above.
>
> Thanks for persisting/continuing with me.
> I apologize, I had applied the most recent patch in Herbert's cryptodev repo,
> not the one that you referred me to.
>
> Yes, the build is now fixed.
Great! Have fun with your new AESNI-accelerated crypto :)