On 2015/05/19 22:02, Masanobu SAITOH wrote:
Hi. On 2015/05/19 10:45, Timo Buhrmester wrote:As of late, when building (and installing) -head I end up with a libcrypto causing SIGILL, apparently due to using the ``pshufb'' instruction (which I believe is part of the SSE3 extension). My CPU is, according to /proc/cpuinfo:For x86, /proc/cpuinfo have not maintained for many years... To avoid this problem, use "cpuctl identify 0" instead of /proc/cpuinfo to check cpu features (PR#49246). Regards.
I've commit the change of x86/procfs_machdep.c to print much information about CPU features now! Example: before:
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 12 model name : Intel(R) Xeon(R) CPU E3-1240L v3 @ 2.00GHz stepping : 3 cpu MHz : 2000.24 fdiv_bug : no fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
after:
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 12 model name : Intel(R) Xeon(R) CPU E3-1240L v3 @ 2.00GHz stepping : 3 cpu MHz : 2000.27 fdiv_bug : no fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm
It's not perfect but it's better than before Thanks.
processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 6 model name : AMD Athlon(tm) II X2 265 Processor stepping : 3 cpu MHz : 3311.46 fdiv_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht processor : 1 [another core](No sse3) As far as gdb is concerned, in libcrypto.so.8.4, this is the point where it blows up: [...] >0x7f7ff6f3ba87 pshufb %xmm6,%xmm0 ;bang 0x7f7ff6f3ba8c add $0x40,%r9 ;for context 0x7f7ff6f3ba90 pshufb %xmm6,%xmm1 0x7f7ff6f3ba95 pshufb %xmm6,%xmm2 0x7f7ff6f3ba9a pshufb %xmm6,%xmm3 0x7f7ff6f3ba9f paddd %xmm9,%xmm0 (Core dump available on request) The assembly code originates from crypto/external/bsd/openssl/dist/crypto/sha/asm/sha1-x86_64.pl (around line 346), but seems to have been untouched for too long to be the culprit (a -head build in March didn't provoke the problem yet). Any ideas?
--
-----------------------------------------------
SAITOH Masanobu (msaitoh%execsw.org@localhost
msaitoh%netbsd.org@localhost)