From nobody Sat Jun 10 04:52:35 2023 X-Original-To: dev-commits-src-all@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 4QdQYK0wtFz4bZQX; Sat, 10 Jun 2023 04:52:37 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QdQYK0FNgz3GZ1; Sat, 10 Jun 2023 04:52:37 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686372757; 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: in-reply-to:in-reply-to:references:references; bh=ySNfnFBQzW9P9+BfC7L7Im0ay/mAvQn1ynKZKsvBsgQ=; b=ZyRrVWsBZ+3J41Vlp8PohKU46Qcihe2CcvrIDLX92mASd0qw/y4PCQ5QEEKmfBnzsfzWYb WNeNA7DnBIxnsfZk/If6/4GCmXujq5z/YGM8/TwQZgTaUX19KgprFqVAqOgkNhONZVQcl7 ZUgdc/nhC3J9ggkBhZwUiCUtvSVLtJNRkNekj5Gu1pF3iP28GmZvCsMe+wRNXFH1TE8qTG tEVGKON98uo80g4H0suH9vl2WAMbCoifKc8jZUb6k2WmeG9G6uz0xbW+Hmn2DvcsG/cWZB YxAvMdg3X9ukAh4jweJD8rGkxT6n/uRSeBPP5B8EjOkVyanhGZalhDBHZyXRTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1686372757; 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: in-reply-to:in-reply-to:references:references; bh=ySNfnFBQzW9P9+BfC7L7Im0ay/mAvQn1ynKZKsvBsgQ=; b=Kj5PdDnqaTzzze5+bOByM5l71pOjkjbD95jR5VFuAQuTESez69V+i6lsDILNbKaxjp/rWB VQUbyWyA3WsWr8KmsUtW4HUQR/NHMXos8gUcC6pIR5wflFZsjaQBASlVECWd8xs+DrcPR2 LU2b96kxKan68BGrESu0rJODKUiogqXTiEzrrlCdYGs3C1q7lYbEgdMVW+eQk6KjwC9neU tpxMljhTEFM2iBsCEan9Hiw8JyBUnGKv1Xwv9P8PREkkQ+nw+DzIIhLWarAXG0bAHZij4p i1VrWheKIEp1Q6aamzvD0fLudy8ZzCeYrsZevHErDtHbxs4dA7y9DLHDSViLiA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1686372757; a=rsa-sha256; cv=none; b=n9hTX2nWGOjGcXKeF2xbiiGea00j6wqywtsAtDPA41skhzx1wBEr4cam2n4KqGoRAWzQob 8pvTAjJZGsYKDKKsjKp/34kro296K1S/hEHE3XX9bdATSa0PXajuLXZV9KYe23ib1u/nMc y6Oa2Ai2DE6/rDySyh6VMVtyCHGawB1V2O0OK2QWd6qupr+4kq1ZT6WXxHXgMXAS48mzFU k0JS1nB4bYUsutnSKzQtstaBDYHb6KrSJY1yCibwCGSyRivrgsHuYQFP57NrDUIRwaIC7y S74sJogK9z0Nz5lcRximtFzCAHBNT0RDSH3A8pozAe84eh5h5QTGhY4PnPDmjw== Received: by freefall.freebsd.org (Postfix, from userid 1033) id 5F0E49629; Sat, 10 Jun 2023 04:52:35 +0000 (UTC) Date: Sat, 10 Jun 2023 04:52:35 +0000 From: Alexey Dokuchaev To: Warner Losh Cc: Kyle Evans , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: ce5a210997da - main - openzfs: arm64: implement kfpu_begin/kfpu_end Message-ID: References: <202304261724.33QHOl6x001199@gitrepo.freebsd.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Wed, Apr 26, 2023 at 12:02:19PM -0600, Warner Losh wrote: > On Wed, Apr 26, 2023 at 11:24???AM Kyle Evans wrote: > > commit ce5a210997da3c4064cfe162e760379f1fa8b587 > > > > openzfs: arm64: implement kfpu_begin/kfpu_end > > > > This is part one of a fix for booting with ZFS on arm64 using > > accelerated checksum implementations. Checksum benchmarking will > > attempt to use the FPU, so we currently panic quickly on boot. > > > > Note that _STANDALONE is special-cased here, but ideally we > > wouldn't be building the code that uses kfpu_begin()/kfpu_end() > > at all in the loader environment. > > Yes. As noted elsewhere, the upstream is a mess. There's no way to > say "I only want the generic implementation" for these functions. > So we went through some crazy hoops to try to disable that... only > to run into a buzz-saw of upstream changes that broke the crazy hoops Sorry for not replying earlier, but given the situation with ZoL and how they keep breaking stuff for us, how feasible would it be to switch back to normal (illumos) ZFS? ./danfe