> Since the inclusion of sparcv9a-mont.s/.pl, I get a SIGBUS error when > running bntest. Package is openssl 1.0.0 with sparcv9a on Linux 2.6.34 > with a sparcv9 environment (64-bit kernel, 32-bit userspace/v8/v8plus) > on a sun4v US T1 CPU. I am aware of the FPU implications - openssl just > chooses sparcv9a by default, so I stumbled across this. > Any insight would be appreciated.
T1 on Linux is the keyword here. I mean it wouldn't have happened under Solaris. Because CPU detection on Solaris is more elaborate than on Linux and bn_mul_mont_fpu wouldn't have been called on T1, bn_mul_mont_int would. For details see crypto/sparcv9cap.c. As you can see on Linux capability vector is assumed to be fixed (with "for now assume that the rest supports UltraSPARC-I* only" resolution) and the only way to override it is to set OPENSSL_sparcv9cap environment variable. So to quickly verify this run 'env OPENSSL_sparcv9cap=0 make test' and see if it passes. Actually it's strange that it fails with SIGBUS... I'd rather expect suboptimal performance, but not SIGBUS... SIGBUS normally denotes unaligned access, but instruction in qustion pulls 16-bit value and effective address is 16-bit aligned... Anyway, the solution is to refine CPU detection and the question is how to *programmatically* detect if it's sun4v system. uname(2) returns sparc64 in utsname.machine field (right?) and doesn't tell the story... One can parse /proc/cpuinfo (looking for type: line), but then you depend on /proc being mounted... Finally one can probe if instruction in question fails the way similar to one in crypto/ppccap.c... Something will be done shortly, meanwhile set OPENSSL_sparcv9cap environment variable to 0. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
