From nobody Wed Dec 27 20:26:28 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0jpp4pJ2z56GTs for ; Wed, 27 Dec 2023 20:26:42 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (tunnel82308-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "garrett.wollman.name", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T0jpm63Wgz4SPm for ; Wed, 27 Dec 2023 20:26:40 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of wollman@hergotha.csail.mit.edu designates 2001:470:1f06:ccb::2 as permitted sender) smtp.mailfrom=wollman@hergotha.csail.mit.edu; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=bimajority.org (policy=none) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.17.1/8.17.1) with ESMTPS id 3BRKQTdl041213 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 27 Dec 2023 15:26:29 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.17.1/8.17.1/Submit) id 3BRKQSCq041212; Wed, 27 Dec 2023 15:26:28 -0500 (EST) (envelope-from wollman) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <25996.34932.339497.605798@hergotha.csail.mit.edu> Date: Wed, 27 Dec 2023 15:26:28 -0500 From: Garrett Wollman To: "Patrick M. Hausen" Cc: Yuri , FreeBSD-STABLE Mailing List Subject: Re: Odd values for various memory metrics via SNMP In-Reply-To: References: <1EDAF2AC-3A2B-43BE-B66B-E095F5A80C2C@punkt.de> <84B7C7D7-BC06-4944-A7E0-5AFC47B6BC0E@punkt.de> <8f4cf72e-8320-4bfd-a4d9-3db34db4580d@aetern.org> X-Mailer: VM 8.2.0b under 29.1 (amd64-portbld-freebsd13.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (hergotha.csail.mit.edu [0.0.0.0]); Wed, 27 Dec 2023 15:26:29 -0500 (EST) X-Spam-Status: No, score=-4.5 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS,NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on hergotha.csail.mit.edu X-Spamd-Result: default: False [-2.90 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[wollman@bimajority.org,wollman@hergotha.csail.mit.edu]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:1f06:ccb::2]; DMARC_POLICY_SOFTFAIL(0.10)[bimajority.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[wollman@bimajority.org,wollman@hergotha.csail.mit.edu]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FREEFALL_USER(0.00)[wollman]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4T0jpm63Wgz4SPm X-Spamd-Bar: -- < said: > Now only "virtual memory" is left - according to the book that should be > the sum of physical memory and swap space - and for my single Linux > host it is. > For the FreeBSD systems this is the one left that still looks nonsensical. > OPNsense (8G RAM, 8G swap): 4.91 of 4.99G used. > TrueNAS (64G RAM, 32G swap): 627 of 628G used. > TrueNAS 2 (32G RAM, 32G swap): 512 of 516G used. This is computed by the function vmtotal() in sys/vm/vm_meter.c. It walks all VM objects in the system, skipping those that are unreferenced, and adds up all of their sizes. There is one VM object for every open file and every running executable, shared library, and mmap()ed region, plus one for every copy-on-write mapping for each process that has modified it, which includes the data segment of every executable and shared library. This has no connection to either physical memory or swap space. The "shared" statistics count only and exactly the underlying (read-only) mapping of objects that are mapped with copy-on-write semantics. -GAWollman From nobody Wed Dec 27 20:39:31 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T0k5f5d9zz56HDk for ; Wed, 27 Dec 2023 20:39:34 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from egress.chen.org.nz (egress.chen.org.nz [170.75.172.82]) by mx1.freebsd.org (Postfix) with ESMTP id 4T0k5f10Nlz4VF3 for ; Wed, 27 Dec 2023 20:39:34 +0000 (UTC) (envelope-from jonc@chen.org.nz) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of jonc@chen.org.nz designates 170.75.172.82 as permitted sender) smtp.mailfrom=jonc@chen.org.nz; dmarc=none Received: from mail.chen.org.nz (unknown [210.54.37.164]) by egress.chen.org.nz (Postfix) with ESMTP id 6B3E9111E14 for ; Thu, 28 Dec 2023 09:39:20 +1300 (NZDT) Received: from mail.chen.org.nz (localhost [127.0.0.1]) by filter.inside.chen.org.nz (Postfix) with ESMTP id E82332835B for ; Thu, 28 Dec 2023 09:39:31 +1300 (NZDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on ametrine.inside.chen.org.nz Received: from [192.168.1.10] (jade.inside.chen.org.nz [192.168.1.10]) by mail.chen.org.nz (Postfix) with ESMTPS id E39872835A for ; Thu, 28 Dec 2023 09:39:31 +1300 (NZDT) Message-ID: <735d5bc7-fc83-4470-abde-2dca43bf7496@chen.org.nz> Date: Thu, 28 Dec 2023 09:39:31 +1300 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Unusual ZFS behaviour Content-Language: en-US To: stable@freebsd.org References: <3cad03f3-f3f6-4d6f-976b-55f5af8909db@chen.org.nz> From: Jonathan Chen In-Reply-To: <3cad03f3-f3f6-4d6f-976b-55f5af8909db@chen.org.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+a:egress.chen.org.nz:c]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[chen.org.nz]; ARC_NA(0.00)[]; ASN(0.00)[asn:174, ipnet:170.75.160.0/20, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4T0k5f10Nlz4VF3 X-Spamd-Bar: --- On 23/11/23 19:06, Jonathan Chen wrote: > On 22/11/23 19:49, Jonathan Chen wrote: >> Hi, >> >> I'm running a somewhat recent version of STABLE-13/amd64: >> stable/13-n256681-0b7939d725ba: Fri Nov 10 08:48:36 NZDT 2023, and I'm >> seeing some unusual behaviour with ZFS. >> >> To reproduce: >>   1. one big empty disk, GPT scheme, 1 freebsd-zfs partition. >>   2. create a zpool, eg: tank >>   3. create 2 sub-filesystems, eg: tank/one, tank/two >>   4. fill each sub-filesystem with large files until the pool is ~80% >> full. In my case I had 200 10Gb files in each. >>   5. in one session run 'md5 tank/one/*' >>   6. in another session run 'md5 tank/two/*' >> >> For most of my runs, one of the sessions against a sub-filesystem will >> be starved of I/O, while the other one is performant. > > I've run a few more tests, and the issue appears to be isolated to my > Alder Lake based system only. So it's more likely to be an issue with > the 'Alder Lake-S PCH SATA Controller [AHCI Mode]' or maybe the > scheduler using the P & E cores. I've updated to FreeBSD 14/STABLE, and I'm glad to report that this bug has gone away. I personally suspect that: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274698 is the cause. Cheers. -- Jonathan Chen From nobody Fri Dec 29 10:14:54 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1h8F6NrRz55nf6 for ; Fri, 29 Dec 2023 10:15:09 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1h8F0BsMz3CPb for ; Fri, 29 Dec 2023 10:15:08 +0000 (UTC) (envelope-from freebsd@omnilan.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de; dmarc=none Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.15.2/8.15.2) with ESMTP id 3BTAExXF032602 for ; Fri, 29 Dec 2023 11:14:59 +0100 (CET) (envelope-from freebsd@omnilan.de) X-Authentication-Warning: mx0.gentlemail.de: Host ezra.dcm1.omnilan.net [78.138.80.135] claimed to be mh0.gentlemail.de Received: from [172.21.3.1] (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 713D625B for ; Fri, 29 Dec 2023 11:14:59 +0100 (CET) Message-ID: Date: Fri, 29 Dec 2023 11:14:54 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Harry Schmalzbauer Subject: SIGILL when CPUTYPE set to anyting witjh avx and CFLAGS -O2 To: FreeBSD-STABLE Content-Language: en-US Organization: OmniLAN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.28 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; DMARC_NA(0.00)[omnilan.de]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4T1h8F0BsMz3CPb X-Spamd-Bar: --- Hello, at least since 14-release, I can't compile base/ports with CPUTYPE post nehalem.  Any '-march' declaring AVX(*) capability leads to SIGILLing binaries with default -O2 CFLAGS. Not much of a help, but here's a ports example, but same result with base outcome too: zsh: illegal hardware instruction (core dumped) /var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/src/vim kernel: pid 56502 (vim), jid 0, uid 0: exited on signal 4 (core dumped) gdb /var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/src/vim /var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/runtime/doc/vim.core GNU gdb (GDB) 13.2 [GDB v13.2 for FreeBSD] Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd14.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/src/vim... [New LWP 154051] Core was generated by `/var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/src/vim --clean -esX -V'. Program terminated with signal SIGILL, Illegal instruction. Privileged opcode. #0  0x000000000041e040 in init_yank () If I compile without CFLAGS -O2 ("CFLAGS= -pipe"), -march=skylake-avx512 the binary doens't crash with SIGILL. Is CPUTYPE supposed to stay untouched these days? Thanks, -harry From nobody Fri Dec 29 17:00:48 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1s8L3Tj6z54Vm3 for ; Fri, 29 Dec 2023 17:00:50 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1s8L33PWz4WdD; Fri, 29 Dec 2023 17:00:50 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703869250; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qZXz+DTkf3aNhC3vevv2RdVUQ6mM+elQjRIrYKnHKuI=; b=UfSst9UnidkevAKkI6IR1TPHCB3fJh9KR+0XO22JgmZ7R22BSK97luuyaXnV5uvTGCuZJJ f7PoJgTcpvqHrokW1PzZSG7uyw/ErboI1NzfMVyYii5nyqdPSYHjX8Aa6uOyVPeB5+CVFh X/c0mrK1U/S9Mnw7xA/HM/Xn2nlp683eQe8m6tDuPwCifxUho3EHe9nqcoi25l74RnxUmR P67yYqwQlArzUQFxpIb82q9UpjWjT7e/lAnAHr3qq+m28vCxxIPkTtclto9W3mSZm4wWFH w8PkiO26Kf/OZv0QmCgZJBKt3an10zoGjkGYRiQK4apx8s/2yI+4oSCg3O77iw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1703869250; a=rsa-sha256; cv=none; b=MEm0vkHT1ajePtPHhzGbCq3cjukHPpBcGM1tsfBVUpckQl/OIk0U3aU/rx7rPwkemWxmFb nrciF+REDM2y3Go9gsQ+qTjZCBSB5dsrAxztuP0rl89C1/TLbh9K3Axm+3LQHhP0UyZcZa Vwkgm7gB2iDF78s3HlU2R2pIiY2NA3mbp1rChpVQe0LgUyntRWUQndaJigCDcVHo9Cf1uu urvh94mUGbjMEohi9h4ziCpzFYfpWp/eArwoSAMAcdrkc+wYUwNcRQh5v/59TKsXbQ715u 1UYarXNJScPXYXF7vfKOPT1JCRvTmZgT8PW1PP7C1NgW1ZsGLd9Z2sBnqmWQZw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703869250; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qZXz+DTkf3aNhC3vevv2RdVUQ6mM+elQjRIrYKnHKuI=; b=ogpGxIBZQi3n6ufDhm8vtZCtiJmp45G8JRWN1w6jVuZrn8zIQ/R+i0183p4PXVznAUnAq8 W2CCjrSLvqI5FcSUVbsvWk30S2C4XHJibWYTcIzGk3Q9j/AQav0PlprRpXnET5w1cagYqc J0yjx77skfQ2kfx4Tm/3I1cD1ww5bI5HcvAqONjSQOnjlJoBy6JPHvWRN5nb+mldHm9gsI ARvPhkQGS2EVhEloJfH/KOoZMNOP4iko4jdGQcoIy0bRNZ0Gefy17ESfJvOeeAsN2jjB8k tzxSwoQNqe4Gbzd3CX7iPdZo2anRjJx7Sqe4WT0l0/3R8lbSLWStq3skUI+Ebg== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4T1s8L1QSkz14CJ; Fri, 29 Dec 2023 17:00:50 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0EEBF42F4C; Fri, 29 Dec 2023 18:00:49 +0100 (CET) Content-Type: text/plain; charset=us-ascii List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: SIGILL when CPUTYPE set to anyting witjh avx and CFLAGS -O2 From: Dimitry Andric In-Reply-To: Date: Fri, 29 Dec 2023 18:00:48 +0100 Cc: FreeBSD-STABLE Content-Transfer-Encoding: quoted-printable Message-Id: <72107B4B-F279-471B-8A8F-5B94C5EEDA47@FreeBSD.org> References: To: Harry Schmalzbauer X-Mailer: Apple Mail (2.3731.700.6) On 29 Dec 2023, at 11:14, Harry Schmalzbauer wrote: >=20 > at least since 14-release, I can't compile base/ports with CPUTYPE = post nehalem. Any '-march' declaring AVX(*) capability leads to = SIGILLing binaries with default -O2 CFLAGS. > Not much of a help, but here's a ports example, but same result with = base outcome too: >=20 > zsh: illegal hardware instruction (core dumped) = /var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/src/vim > kernel: pid 56502 (vim), jid 0, uid 0: exited on signal 4 (core = dumped) >=20 > gdb /var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/src/vim = /var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/runtime/doc/vim.c= ore >=20 > GNU gdb (GDB) 13.2 [GDB v13.2 for FreeBSD] > Copyright (C) 2023 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later = > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-portbld-freebsd14.0". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . >=20 > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from = /var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/src/vim... > [New LWP 154051] > Core was generated by = `/var/ports-wrktree/editors/vim/work-console/vim-9.0.2143/src/vim = --clean -esX -V'. > Program terminated with signal SIGILL, Illegal instruction. > Privileged opcode. > #0 0x000000000041e040 in init_yank () >=20 >=20 > If I compile without CFLAGS -O2 ("CFLAGS=3D -pipe"), = -march=3Dskylake-avx512 the binary doens't crash with SIGILL. >=20 > Is CPUTYPE supposed to stay untouched these days? Obviously not, but are you sure your target CPU is correct? If it is = not, the compiler may insert unsupported instructions. In any case, for the above gdb session, try the command "disassemble" to = see which particular instruction it crashed on. That may give more = information. -Dimitry From nobody Fri Dec 29 20:12:35 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1xPn5JVKz557Td for ; Fri, 29 Dec 2023 20:12:45 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1xPn0Xz6z3QFb; Fri, 29 Dec 2023 20:12:44 +0000 (UTC) (envelope-from freebsd@omnilan.de) Authentication-Results: mx1.freebsd.org; none Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.15.2/8.15.2) with ESMTP id 3BTKCdRJ035623; Fri, 29 Dec 2023 21:12:39 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from [172.21.3.1] (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id A022036C; Fri, 29 Dec 2023 21:12:39 +0100 (CET) Message-ID: <62cc8fed-6acd-45fb-a138-ac7cd218191a@omnilan.de> Date: Fri, 29 Dec 2023 21:12:35 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: SIGILL when CPUTYPE set to anyting witjh avx and CFLAGS -O2 Content-Language: en-US To: Dimitry Andric Cc: FreeBSD-STABLE References: <72107B4B-F279-471B-8A8F-5B94C5EEDA47@FreeBSD.org> From: Harry Schmalzbauer Organization: OmniLAN In-Reply-To: <72107B4B-F279-471B-8A8F-5B94C5EEDA47@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1xPn0Xz6z3QFb On 12/29/23 18:00, Dimitry Andric wrote: > On 29 Dec 2023, at 11:14, Harry Schmalzbauer wrote: >> >> at least since 14-release, I can't compile base/ports with CPUTYPE post nehalem. Any '-march' declaring AVX(*) capability leads to SIGILLing binaries with default -O2 CFLAGS. ... >> >> If I compile without CFLAGS -O2 ("CFLAGS= -pipe"), -march=skylake-avx512 the binary doens't crash with SIGILL. >> >> Is CPUTYPE supposed to stay untouched these days? > > Obviously not, but are you sure your target CPU is correct? If it is not, the compiler may insert unsupported instructions. Ho Dimitry, thanks for your attention! I have to admit that I know much too less about contemporary compilers and CPUs likewise, but target CPU matches -march ;-) I nailed it down to AVX instructions. Starting with 'sandybridge', Intel CPUs provide avx instruction units, and starting with CPUTYPE?=sandybridge, binaries crash on stable/14 (and late 14-current) on the corresponding machines. But only in combination with CFLAGS -O2! > In any case, for the above gdb session, try the command "disassemble" to see which particular instruction it crashed on. That may give more information. Thanks for the hint! This came out: Program terminated with signal SIGILL, Illegal instruction. Privileged opcode. #0 0x000000000041e040 in init_yank () (gdb) disassemble Dump of assembler code for function init_yank: 0x000000000041e030 <+0>: push %rbp 0x000000000041e031 <+1>: mov %rsp,%rbp 0x000000000041e034 <+4>: vpxor %xmm0,%xmm0,%xmm0 0x000000000041e038 <+8>: vmovdqa -0x202c10(%rip),%xmm1 # 0x21b430 => 0x000000000041e040 <+16>: kxnorw %k0,%k0,%k1 0x000000000041e044 <+20>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} 0x000000000041e04f <+31>: vmovdqa -0x202b77(%rip),%xmm1 # 0x21b4e0 0x000000000041e057 <+39>: kxnorw %k0,%k0,%k1 0x000000000041e05b <+43>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} 0x000000000041e066 <+54>: vmovdqa -0x202c5e(%rip),%xmm1 # 0x21b410 0x000000000041e06e <+62>: kxnorw %k0,%k0,%k1 0x000000000041e072 <+66>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} 0x000000000041e07d <+77>: vmovdqa -0x202cf5(%rip),%xmm1 # 0x21b390 0x000000000041e085 <+85>: kxnorw %k0,%k0,%k1 0x000000000041e089 <+89>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} 0x000000000041e094 <+100>: vmovdqa -0x202b5c(%rip),%xmm1 # 0x21b540 0x000000000041e09c <+108>: kxnorw %k0,%k0,%k1 0x000000000041e0a0 <+112>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} 0x000000000041e0ab <+123>: vmovdqa -0x202e43(%rip),%xmm1 # 0x21b270 0x000000000041e0b3 <+131>: kxnorw %k0,%k0,%k1 0x000000000041e0b7 <+135>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} 0x000000000041e0c2 <+146>: vmovdqa -0x202d0a(%rip),%xmm1 # 0x21b3c0 0x000000000041e0ca <+154>: kxnorw %k0,%k0,%k1 0x000000000041e0ce <+158>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} 0x000000000041e0d9 <+169>: vmovdqa -0x202ac1(%rip),%xmm1 # 0x21b620 0x000000000041e0e1 <+177>: kxnorw %k0,%k0,%k1 0x000000000041e0e5 <+181>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} 0x000000000041e0f0 <+192>: vmovdqa -0x202d58(%rip),%xmm1 # 0x21b3a0 0x000000000041e0f8 <+200>: kxnorw %k0,%k0,%k1 0x000000000041e0fc <+204>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} 0x000000000041e107 <+215>: movq $0x0,0x1414ee(%rip) # 0x55f600 0x000000000041e112 <+226>: pop %rbp 0x000000000041e113 <+227>: vzeroupper 0x000000000041e116 <+230>: ret End of assembler dump. Example is from 'cc -c -I. -Iproto -DHAVE_CONFIG_H -DLIBICONV_PLUG -I/usr/local/include -O2 -pipe -march=skylake-avx512 -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/alloc.o alloc.c' with CPU: Intel(R) Xeon(R) CPU E3-1275 v6 @ 3.80GHz (3800.00-MHz K8-class CPU) When I 1st noticed, I checked also much more recent CPUs - with the same result - if CPUTUPE is set to any avx-involving optimization together with -O2, binaries crash with SIGILL on Haswell, SkyLake, TigerLake... My last world/ports builds (sucessfully with CPUTYPE?=ivybridge) were with stable-13 (arround 13.1) - and llvm 13 I think - can't remember exactly. Thanks, -harry From nobody Fri Dec 29 20:20:19 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1xZg54mfz5585l for ; Fri, 29 Dec 2023 20:20:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1xZg0Jk8z3RZ0; Fri, 29 Dec 2023 20:20:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 3BTKKJmU088136; Fri, 29 Dec 2023 22:20:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 3BTKKJmU088136 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 3BTKKJMw088134; Fri, 29 Dec 2023 22:20:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Dec 2023 22:20:19 +0200 From: Konstantin Belousov To: Harry Schmalzbauer Cc: Dimitry Andric , FreeBSD-STABLE Subject: Re: SIGILL when CPUTYPE set to anyting witjh avx and CFLAGS -O2 Message-ID: References: <72107B4B-F279-471B-8A8F-5B94C5EEDA47@FreeBSD.org> <62cc8fed-6acd-45fb-a138-ac7cd218191a@omnilan.de> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62cc8fed-6acd-45fb-a138-ac7cd218191a@omnilan.de> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1xZg0Jk8z3RZ0 On Fri, Dec 29, 2023 at 09:12:35PM +0100, Harry Schmalzbauer wrote: > On 12/29/23 18:00, Dimitry Andric wrote: > > On 29 Dec 2023, at 11:14, Harry Schmalzbauer wrote: > > > > > > at least since 14-release, I can't compile base/ports with CPUTYPE post nehalem. Any '-march' declaring AVX(*) capability leads to SIGILLing binaries with default -O2 CFLAGS. > .. > > > > > > If I compile without CFLAGS -O2 ("CFLAGS= -pipe"), -march=skylake-avx512 the binary doens't crash with SIGILL. > > > > > > Is CPUTYPE supposed to stay untouched these days? > > > > Obviously not, but are you sure your target CPU is correct? If it is not, the compiler may insert unsupported instructions. > > Ho Dimitry, thanks for your attention! > I have to admit that I know much too less about contemporary compilers and > CPUs likewise, but target CPU matches -march ;-) > I nailed it down to AVX instructions. Starting with 'sandybridge', Intel > CPUs provide avx instruction units, and starting with CPUTYPE?=sandybridge, > binaries crash on stable/14 (and late 14-current) on the corresponding > machines. But only in combination with CFLAGS -O2! > > > > In any case, for the above gdb session, try the command "disassemble" to see which particular instruction it crashed on. That may give more information. > > Thanks for the hint! > This came out: > Program terminated with signal SIGILL, Illegal instruction. > Privileged opcode. > #0 0x000000000041e040 in init_yank () > (gdb) disassemble > Dump of assembler code for function init_yank: > 0x000000000041e030 <+0>: push %rbp > 0x000000000041e031 <+1>: mov %rsp,%rbp > 0x000000000041e034 <+4>: vpxor %xmm0,%xmm0,%xmm0 > 0x000000000041e038 <+8>: vmovdqa -0x202c10(%rip),%xmm1 # 0x21b430 > => 0x000000000041e040 <+16>: kxnorw %k0,%k0,%k1 This is AVX512 instruction (some of it subset, probably F), not AVX. > 0x000000000041e044 <+20>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} > 0x000000000041e04f <+31>: vmovdqa -0x202b77(%rip),%xmm1 # 0x21b4e0 > 0x000000000041e057 <+39>: kxnorw %k0,%k0,%k1 > 0x000000000041e05b <+43>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} > 0x000000000041e066 <+54>: vmovdqa -0x202c5e(%rip),%xmm1 # 0x21b410 > 0x000000000041e06e <+62>: kxnorw %k0,%k0,%k1 > 0x000000000041e072 <+66>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} > 0x000000000041e07d <+77>: vmovdqa -0x202cf5(%rip),%xmm1 # 0x21b390 > 0x000000000041e085 <+85>: kxnorw %k0,%k0,%k1 > 0x000000000041e089 <+89>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} > 0x000000000041e094 <+100>: vmovdqa -0x202b5c(%rip),%xmm1 # > 0x21b540 > 0x000000000041e09c <+108>: kxnorw %k0,%k0,%k1 > 0x000000000041e0a0 <+112>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} > 0x000000000041e0ab <+123>: vmovdqa -0x202e43(%rip),%xmm1 # > 0x21b270 > 0x000000000041e0b3 <+131>: kxnorw %k0,%k0,%k1 > 0x000000000041e0b7 <+135>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} > 0x000000000041e0c2 <+146>: vmovdqa -0x202d0a(%rip),%xmm1 # > 0x21b3c0 > 0x000000000041e0ca <+154>: kxnorw %k0,%k0,%k1 > 0x000000000041e0ce <+158>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} > 0x000000000041e0d9 <+169>: vmovdqa -0x202ac1(%rip),%xmm1 # > 0x21b620 > 0x000000000041e0e1 <+177>: kxnorw %k0,%k0,%k1 > 0x000000000041e0e5 <+181>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} > 0x000000000041e0f0 <+192>: vmovdqa -0x202d58(%rip),%xmm1 # > 0x21b3a0 > 0x000000000041e0f8 <+200>: kxnorw %k0,%k0,%k1 > 0x000000000041e0fc <+204>: vpscatterdq %ymm0,0x55f180(,%xmm1,1){%k1} > 0x000000000041e107 <+215>: movq $0x0,0x1414ee(%rip) # 0x55f600 > > 0x000000000041e112 <+226>: pop %rbp > 0x000000000041e113 <+227>: vzeroupper > 0x000000000041e116 <+230>: ret > End of assembler dump. > > Example is from 'cc -c -I. -Iproto -DHAVE_CONFIG_H -DLIBICONV_PLUG > -I/usr/local/include -O2 -pipe -march=skylake-avx512 -DLIBICONV_PLUG > -fstack-protector-strong -fno-strict-aliasing -D_REENTRANT > -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/alloc.o alloc.c' > with CPU: > Intel(R) Xeon(R) CPU E3-1275 v6 @ 3.80GHz (3800.00-MHz K8-class CPU) > > When I 1st noticed, I checked also much more recent CPUs - with the same > result - if CPUTUPE is set to any avx-involving optimization together with > -O2, binaries crash with SIGILL on Haswell, SkyLake, TigerLake... > My last world/ports builds (sucessfully with CPUTYPE?=ivybridge) were with > stable-13 (arround 13.1) - and llvm 13 I think - can't remember exactly. > > Thanks, > -harry From nobody Fri Dec 29 20:31:10 2023 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1xq61sxHz558lk for ; Fri, 29 Dec 2023 20:31:14 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1xq606c3z3T9m; Fri, 29 Dec 2023 20:31:13 +0000 (UTC) (envelope-from freebsd@omnilan.de) Authentication-Results: mx1.freebsd.org; none Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.15.2/8.15.2) with ESMTP id 3BTKVAXP035776; Fri, 29 Dec 2023 21:31:10 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from [172.21.3.1] (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id C72B9391; Fri, 29 Dec 2023 21:31:10 +0100 (CET) Message-ID: Date: Fri, 29 Dec 2023 21:31:10 +0100 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: SIGILL when CPUTYPE set to anyting witjh avx and CFLAGS -O2 Content-Language: en-US To: Konstantin Belousov Cc: Dimitry Andric , FreeBSD-STABLE References: <72107B4B-F279-471B-8A8F-5B94C5EEDA47@FreeBSD.org> <62cc8fed-6acd-45fb-a138-ac7cd218191a@omnilan.de> From: Harry Schmalzbauer Organization: OmniLAN In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4T1xq606c3z3T9m On 12/29/23 21:20, Konstantin Belousov wrote: > On Fri, Dec 29, 2023 at 09:12:35PM +0100, Harry Schmalzbauer wrote: >> On 12/29/23 18:00, Dimitry Andric wrote: >>> On 29 Dec 2023, at 11:14, Harry Schmalzbauer wrote: >>>> >>>> at least since 14-release, I can't compile base/ports with CPUTYPE post nehalem. Any '-march' declaring AVX(*) capability leads to SIGILLing binaries with default -O2 CFLAGS. >> .. >>>> >>>> If I compile without CFLAGS -O2 ("CFLAGS= -pipe"), -march=skylake-avx512 the binary doens't crash with SIGILL. >>>> >>>> Is CPUTYPE supposed to stay untouched these days? >>> >>> Obviously not, but are you sure your target CPU is correct? If it is not, the compiler may insert unsupported instructions. >> >> Ho Dimitry, thanks for your attention! >> I have to admit that I know much too less about contemporary compilers and >> CPUs likewise, but target CPU matches -march ;-) >> I nailed it down to AVX instructions. Starting with 'sandybridge', Intel >> CPUs provide avx instruction units, and starting with CPUTYPE?=sandybridge, >> binaries crash on stable/14 (and late 14-current) on the corresponding >> machines. But only in combination with CFLAGS -O2! >> >> >>> In any case, for the above gdb session, try the command "disassemble" to see which particular instruction it crashed on. That may give more information. >> >> Thanks for the hint! >> This came out: >> Program terminated with signal SIGILL, Illegal instruction. >> Privileged opcode. >> #0 0x000000000041e040 in init_yank () >> (gdb) disassemble >> Dump of assembler code for function init_yank: >> 0x000000000041e030 <+0>: push %rbp >> 0x000000000041e031 <+1>: mov %rsp,%rbp >> 0x000000000041e034 <+4>: vpxor %xmm0,%xmm0,%xmm0 >> 0x000000000041e038 <+8>: vmovdqa -0x202c10(%rip),%xmm1 # 0x21b430 >> => 0x000000000041e040 <+16>: kxnorw %k0,%k0,%k1 > This is AVX512 instruction (some of it subset, probably F), not AVX. > ... >> Intel(R) Xeon(R) CPU E3-1275 v6 @ 3.80GHz (3800.00-MHz K8-class CPU) My bad, sorry. Confused machines. This indeed was wrong target CPU, stupid me. Previously I tested tih CPUTYPE?=haswell, which editors/vim survives currently. Will run a base build with CPUTYPE?=haswell over the weekend and report back. Sorry for the noise so far... -harry