On Wednesday 2010-06-30 16:04, Andy Polyakov wrote: >> 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, >[...] >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...
Perhaps you can reproduce the SIGBUS on Solaris by forcing FPU on T1. Or maybe it's another signal, which could point to a trap translation issue in Linux. >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... $ LD_SHOW_AUXV=1 /bin/true AT_HWCAP: flush stbar swap muldiv v9 v9v Though that relies on glibc... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
