From nobody Sun Apr 09 02:40:37 2023 X-Original-To: freebsd-arm@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 4PvGYs4bVHz459tn; Sun, 9 Apr 2023 02:40:49 +0000 (UTC) (envelope-from kevans@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 4PvGYs44mBz4QX0; Sun, 9 Apr 2023 02:40:49 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681008049; 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=AqA0V16yq+OjcCMN0KeBOsKnhVu7f+IR7+tSxbNk2tA=; b=imoxzr0KxJnxZ77/qF+L6QGNzNWTQJT8i67NKcVhITZ3HsFxsQYYQODwdVAQqjhz4Y7h7r SxXjb+ibQZIbApopf0+O9VciIGns4swhggAc36z5iG+a6JZfHy1aSnCKXhsVamGZsb36AJ UfGlEpwQd5CyBdHJJ0qbBsInC9ZI2sVuPN7TmLFpJhF2dXad2P+WVB6qswsnHvEo1Hm/ij 9qcgYKJBzYZhbvlxY/WAwbLPaYkhOaM71ft6M+VsI0HdBimr12G9UcabcP2Ow7eztVRuXo HIi2aD3GTf8cx22CyKtTl4NAEKQRJ0aiXYEebDSlrfh35M9XTVKQsx3oFpITag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1681008049; 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=AqA0V16yq+OjcCMN0KeBOsKnhVu7f+IR7+tSxbNk2tA=; b=q1/sn321PDuaAS1u3SUw6AVyQGMvK70ccvRjidgKoEUVy6uGx2aYDczjzn9wRjlI8xYlus e9u3SiFaDGUXw2x3VigOrr1mSHH7Y0BvC/imQ/OerBAdJL6nzSihmxpRP4OIWJzQy12POh iJwAA1PycxPoq7eulWevtErUmRCALLGYZARPIWxzp0IR7+tFU5ijo9tAvkJ4NzQ/XUYn9I Um5UatY6ApKEQitNgjxyUsQXFjHKXO0259zo6lc6JSjGhBuDfwacOGHu/xcU4BSfAeNSne VcZZxCuAcHbrIakWm3nAHm+lizdzm6GM7HNSVDzYG+UgWMcWVbnYtUhyRzaRbQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1681008049; a=rsa-sha256; cv=none; b=M+HN41JfLYKu75HArFp1ZJRPmX/9NxoV8U2Uj9F1LjFbnfY6XaXvYPmzh5AxQfCOQnq3Px un3YZ8wpgPBEt84LAhvGOe4l5aKqIBYHKXMyMK2Bb0WhlnFpsTk5AGCDArOshBgWAZdaS+ iVhXVsfw5at3p3ah8gezGKBceOkznk4kA92MAiTlzX0tgmmNCuf5zIPDpY2d8/7VYIoFpO fkFvxVwc/9imW3d+AOORUxiiUV2LLcjaT57xzydzxVu65XKBc6lOA7dTVttD2eM0kR4EAl +tNxN4OXwiYrMRvlI2SdcUJu6yKMl7KPcBBNTCI8NkbjIi/B8l6aooWS4XIXYQ== Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PvGYs31fJznyQ; Sun, 9 Apr 2023 02:40:49 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f179.google.com with SMTP id bn8so1880690qtb.2; Sat, 08 Apr 2023 19:40:49 -0700 (PDT) X-Gm-Message-State: AAQBX9eYp2gkBIQhjXiNpeLf2/dX+c1fBsBNn9wfhA6+VhYI83VnloTo mJXpt0AKcOb8QRuvNup1Ep735153EANgwpdBnvw= X-Google-Smtp-Source: AKy350aifjTI7XK/IbTGk9Rucrolsyq7xpXzsohboE6/AULmqSGdMZqIqd+2L2Q1vFbBUdnREG1HuyspheUOXiNcTX4= X-Received: by 2002:a05:622a:394:b0:3d7:9d03:75b0 with SMTP id j20-20020a05622a039400b003d79d0375b0mr2572684qtx.13.1681008048647; Sat, 08 Apr 2023 19:40:48 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <3A019D10-E520-4C11-AE9F-4EA5D99B9B07@yahoo.com> In-Reply-To: From: Kyle Evans Date: Sat, 8 Apr 2023 21:40:37 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75 [separate aarch64 panic for zpool import] To: Mateusz Guzik Cc: Kyle Evans , Mark Millard , dev-commits-src-main@freebsd.org, Current FreeBSD , freebsd-arm , John F Carr Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N On Sat, Apr 8, 2023 at 5:24=E2=80=AFAM Mateusz Guzik wr= ote: > > On 4/8/23, Kyle Evans wrote: > > On Fri, Apr 7, 2023 at 4:54=E2=80=AFPM Mateusz Guzik wrote: > >> > >> On 4/7/23, Mark Millard wrote: > >> > On Apr 7, 2023, at 14:26, Mateusz Guzik wrote: > >> > > >> >> On 4/7/23, Mateusz Guzik wrote: > >> >>> can you try with this: > >> >>> > >> >>> diff --git > >> >>> a/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h > >> >>> b/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h > >> >>> index 16276b08c759..e1bca9ef140a 100644 > >> >>> --- > >> >>> a/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h > >> >>> +++ > >> >>> b/sys/contrib/openzfs/include/os/linux/kernel/linux/simd_aarch64.h > >> >>> @@ -71,7 +71,7 @@ > >> >>> #define ID_AA64PFR0_EL1 sys_reg(3, 0, 0, 1, 0) > >> >>> #define ID_AA64ISAR0_EL1 sys_reg(3, 0, 0, 6, 0) > >> >>> > >> >>> -#define kfpu_allowed() 1 > >> >>> +#define kfpu_allowed() 0 > >> >>> #define kfpu_begin() kernel_neon_begin() > >> >>> #define kfpu_end() kernel_neon_end() > >> >>> #define kfpu_init() (0) > >> >>> > >> >>> > >> >> > >> >> ops, wrong file > >> >> > >> >> diff --git a/sys/contrib/openzfs/include/os/freebsd/spl/sys/simd_ar= m.h > >> >> b/sys/contrib/openzfs/include/os/freebsd/spl/sys/simd_arm.h > >> >> index 178fbc3b3c6e..c462220289d6 100644 > >> >> --- a/sys/contrib/openzfs/include/os/freebsd/spl/sys/simd_arm.h > >> >> +++ b/sys/contrib/openzfs/include/os/freebsd/spl/sys/simd_arm.h > >> >> @@ -46,7 +46,7 @@ > >> >> #include > >> >> #include > >> >> > >> >> -#define kfpu_allowed() 1 > >> >> +#define kfpu_allowed() 0 > >> >> #define kfpu_initialize(tsk) do {} while (0) > >> >> #define kfpu_begin() do {} while (0) > >> >> #define kfpu_end() do {} while (0) > >> > > >> > It will take me a bit to setup a separate build/install > >> > context for the source code vintage involved. Then more > >> > time to do the build, install, and test. (I'm keeping > >> > my normal environments completely before the mess.) > >> > > >> > FYI: > >> > > >> > I have used the artifact build just after your pair of zfs > >> > related updates to confirm the VFP problem is still in > >> > place as of that point: > >> > > >> > https://artifact.ci.freebsd.org/snapshot/main/5e2e3615d91f9c0c688987= 915ff5c8de23c22bde/arm64/aarch64/kernel.txz > >> > > >> > (No artifact build was exactly at either of your commits.) > >> > > >> > =3D=3D=3D > >> > Mark Millard > >> > marklmi at yahoo.com > >> > > >> > > >> > >> I have arm64 + zfs at $job and just verified the above lets it boot > >> again, so I committed already. > >> > > > > This was a known issue that we were working on fixing properly over in > > https://reviews.freebsd.org/D39448... this really could have waited > > just a little bit longer. This problem was already brought up in > > response to the commit in question days ago. > > > > Mate, that's one confusing email. > Sorry, this was misdirected anger around this series of crappery. > I had seen the upstream review, apparently there is opposition to the > patch, it is clearly not going to land within hours. > The opposition is notably from a person that does not actually work on this platform, and IMO has no bearing on our downstream review. We'll get past him eventually, because this is what needs to happen. > Whatever the Real Fix(tm) might be, I'm confident my change has no > impact on work on it, past the need to flip kfpu_allowed back to 1. > > At the same time things were broken to the point where aarch64 + zfs > literally did not boot. Once more, I fail to see how restoring basic > operation by fipping a macro to 0 throws any wrenches into the effort > to get simd working. > Thanks! > If anything the question is how come a clearly *not* implemented simd > support got kfpu_allowed set to 1. > Your guess is as good as mine -- it clearly could not have been tested at all, I have no clue why they didn't err on the side of caution and avoid fpu usage. Thanks, Kyle Evans