From nobody Sun Oct 29 01:25:18 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 4SHzHQ20knz4yJ5m for ; Sun, 29 Oct 2023 01:25:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SHzHP1DR7z3WgW for ; Sun, 29 Oct 2023 01:25:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=I2DPLar7; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1698542734; bh=nT4wqhqFNSpEWNyEfDkrh5LnZT7QCw3a6bGOdCs5L9g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=I2DPLar7NbmSA0NDp/cYpg/h3Kijuhn0mg7yGEogdUjMSdXcUTQQoWtV34A5PWYKRj6SJXZeEN2uxduBblsFCar0YK4XJGYDHR0BHF8sABjwx7dP8XvrnK2RhRO4hc9Z11l5HtOJyqt3tw/uTvf1oMxBNCUCXDf0T+2UdBW/G3EEzCM/RzRBTYu96GKbqqceX8DgrIqoNyeRaeHZ4m94PRdKIJn2Frnqo7qTuC1e2PQH/T5vmdg7NqsEtTTvV+7cqze05Y0jMwPmcZeNIuBG3zq9uiMzoR8TosocnyvymhebuwuLzBD6FCfM3cTF/9z5g3mYxCXySVOoAgDPRB2DYA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1698542734; bh=2f+hW/ZFsMhr0Grq37i90ScyHnRFgA5lJchgNFUR546=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=VvocaWldJFtgKgDQqT6LPkOktjpJh6ioysJFjBAP8ViJ523zWE1Nip1y9edNKZh1NLCVgna+LdYwh6DZK6TNjDGy3hISO7jIMBkLDmBdGzl869U8Z1NGpFWHnHjzkh08DZoRlPTMtyDEtjpoEuiqar7WeJb91JTHlAORV8rPX9i4JLSa2E7vLtRIUpBkA0K/bp4/R/zIXI2ZpDvLCmC6Qriusggt59YtQFIMMeWp15dqVzE3Qrl3VM7aXaLMqNVHZvloexJoqgYUvt7bwfQkA8ZukTI5sNeBXGCR0/Yu8JkjWxYCz7vtdk48HGiqvU1/qr+lyYG+L88FMLrpAwzS6Q== X-YMail-OSG: uuZvjlkVM1kqZeHufUs5es6ds339fm_ysfuUEMZ_GUSwGSL.BLj5vDSGgqdzlxB hx4_q_2AGIFfUmpRNrC6.g1IC6txVbMAVI4inxLkJIOFz0CZU6yROXe8Ac0TPUPZu1kyuD1Y.vu1 FnyeE921CYL0y1IkWIMlUgYw09EGPvorzFttBKKABC3rWhjR_a9BRSkF5RUcvEkLd.U.6yQJfsJe 891V6FLbtugpQcUYM29nMTdfdvR_24vFmsaUDUeIRHAj4DgoqKqVZX_acF7ablyuzIXb5jLlA9X3 GkbsFEuFvqDSFsLhDaDpgKURrKLDQ6Dnjaw1jevA8KmTQZ6xwOJZJSI8wHP1o2.9_aacsexyAxtc DYOwBiuIrAQ3x7AaWaUSkknIzS3JoV6MRknv0UCciZqTX..cqQSdIMcja2_GthDM8QeeNhlz_.DH WA7XOO0eHPwJavmWhUyvXxDzCmVxq5jaM_Wg7PmE36difxaq.qv6tKW491bH21ClarbgZOZ6GVAz LSIv9PI8Y0Ihw.4uhpGE6.X_faAwP2BZgXtx8MekFM9Cf4Sph.Isr6hMVXaBhCX.tPVFoe08JaAq byTPWgDy9fAK_SEobebx8zf_MWIeNB4NvTyosuKdc5XkXBC0On021SneyYlc1pLOb6Tif0w5BdZ1 3HVzLndI620BYYIjQ6Xifijwl.pfAV1Y65v1yMrRgE4C5rupfvyVZz.equ_Ev7.WhPLPk65DtpV. ToWsXxwbH_fFRfvdBMSguygQ29bu4zp7ueyaP2acVe9pulPhPZg_jWO8PtHr0sKDD7vQBHRm3Kq2 Vhhwvv7_MsDSt9KV1uyakY5OUApdjn3J1eKNkftZNwWVP7TW_jlqsEgXLVUb18Fvmi1kruqxPBjO wpEL35IEPoUiPVf0at_m78QaL6y76YMn6tNL8sr0QCtZNbDZfIbix0Q8FxHKjuXpZCeougskoh3n DNNLetB1Q6d4rr_84fO467Fy4avOso1jzIETGL6R3IRRiIgbHk59NwHCHQcbOFNXsYWXkRdjg9f2 K4ipkWFlYAOnvwmAinOcibiY81lk8JC6z5T_dTwYiHB3TrA_alUlAdA6zfOmvA.I2VmhdPksoFKk kDiEUDR4pOjv4jUvsbjnThq3AuXurTQGv5Rfi7O9IVkGcbsrdI7owd9ax3RGhGgeF8yJvwH4EE3E 1G3HKykjnrLJAk_DEKkuRdxPVc4PcZJS_e27fCJkgrqw1j.XtH77t9WwkZe6Q0gjyPrphg6AsK1M n.9PfkdTCbY7H8jx7Z84_mB2w.1gQnWIj7QnfyruzSYQsvEAT6aRmbqXFUymzy3Tk7PN.TLC.Sx_ yFjWaH07srfb9xGnLxNmUfh4wFzYvL9syawD3N9vJwK_pNcyesgaxJbxeEPcvSiI6CsCXeOphUN8 t_D1NQ44_ZTT5n.CfSrIMGweB_6ybKvtihfyr1IRXli9fuakALkpqKvFkePz707CoE_Cpk5pQaHP 5jAL7wkr_N0qhW4FP3fFehdQNLnOHWu9Ewx1ZhhQHMKU62fqV_27Hs0SunxmNfjdmF3UC2T81QJt NMXpRlPE8bRfJrJl5ijoffDaVGk7.q.gWcIPg.46S3gwC.Rns3iCGsv9rJhkHsZuolNfxoWKuvzf 1cggtz6vDhKl3bQ.gzmeqg9GHGi1hfV2RfT17J_N5F3b6w05sY4gM3UzBcpjWeiZ4BBaNdQNtrlY sLMcE2PZNkYTPbBFHOK103TQDmvdY05Oc2a2t5zJGag_mT5yUdSkbiUqFSjGiqFGU6xZDDYA61Vw lcaZLhmb7nFzbo2juYgwOGb3xVDQRLtbEyKEylpcPobEdLZrxlsxmJlgn95cpG4rENS5cJqA9L.0 Sw_DOYL28ZisIi5NLivGp6BtoeOHT_oiD4ExJdakngsba1W1RfQqUHsJx0met6l4Kz.YkqpuX1FG 6tLkPzynZYJBPeuATvGE6psz8aY_hSbf5tDdySdS2yWLPjGushV8MVhe1G4NuXbLMAomjSUKr4Ng P8j5dsVZmKqO4KuDYKwMt9T2aCaprObDH4d2kpP4GTRYdHXJw6j.Z327A_w6w7v5KEZ36c1oThkZ pfQOdSpxcPwBZeb_c0R5JwwTGKkBJepqtDWyfihqZTzA5RUf378Oy4wKltsr_u6ruQYp3zmebs7Q WfhGHGV3TGI05rIXzE7O_HoHHVj4Hrm1W9H9jIBEhVnLnUw5KSZy.0sxzXT7YCy64cgFB3B47f2I RGnbYTiyZlmsCetu760cPYt4kbDtDh.y7jHW6iY9JwndQ87xvTOKQm6EjC8uw618LVI4gfW3vAdc - X-Sonic-MF: X-Sonic-ID: 5d27aa67-1c3b-4340-acb3-8b227ff3aee2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 29 Oct 2023 01:25:34 +0000 Received: by hermes--production-ne1-56df75844-jh4w4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 72de6089317834b8c07db9aac882124a; Sun, 29 Oct 2023 01:25:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: 15-aarch64-RPI-snap From: Mark Millard In-Reply-To: <183A9CD0-42DB-4A0C-982D-FC6D3980163A@yahoo.com> Date: Sat, 28 Oct 2023 18:25:18 -0700 Cc: Colin Percival , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <6CF6E677-CF8F-4DE9-9781-754003FCE0B6@yahoo.com> References: <0100018b6a9d257c-b35e4157-ba97-4aa7-988c-aba797c6d2ca-000000@email.amazonses.com> <13B64416-4334-4070-8588-71F7D938350B@yahoo.com> <3B40F89C-7E5E-427F-A7A1-2D37CCC06A6F@yahoo.com> <183A9CD0-42DB-4A0C-982D-FC6D3980163A@yahoo.com> To: Glen Barber X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spamd-Result: default: False [-3.48 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.980]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; BLOCKLISTDE_FAIL(0.00)[98.137.68.32:server fail]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SHzHP1DR7z3WgW X-Spamd-Bar: --- On Oct 28, 2023, at 09:40, Mark Millard wrote: > On Oct 27, 2023, at 23:00, Mark Millard wrote: >=20 >> On Oct 27, 2023, at 22:24, Mark Millard wrote: >>=20 >>> On Oct 27, 2023, at 21:34, Glen Barber wrote: >>>=20 >>>>>> . . . >>>>>> = ^ >>>>>> ./offset.inc:16:19: error: null character ignored = [-Werror,-Wnull-character] >>>>>> = = = = >>>>> 00>#undef _SA >>>>>> = = ^ >>>=20 >>> Are the above from a ZFS file system? UFS? Something else? >>>=20 >>> Back in 2021-Nov (15..21) I had problems where ZFS was leading >>> to blocks of such on aarch64, not specifically RPi*'s, various >>> files but not the same ones from test to test. When I updated >>> past some zfs updates on the 23rd the problem stopped. >>>=20 >>> I also have notes from 2022-Mar (19..22) about replicating >>> another example problem someone was having with files ending >>> up with such blocks of bytes but the testing was on the >>> ThreadRipper 1950X. (The replication showed that ccache did >>> not need to be involved since I've never used it.) Again >>> ZFS was part of the environment that got the replication. >>> Mark Johnson fixed sys/contrib/openzfs/module/zfs/dnode.c >>> during this and my ability to replicate the issue then >>> stopped when I tested the patch. >>>=20 >>> Which ever file system it is that holds the bad bytes, some >>> attempted testing for repeatability of the problem could >>> be of interest, some of that being on aarch64 but not on >>> RPi*'s, some of it not on aarch64 at all. But it might take >>> information about the context to know better what/how to >>> test. That could include information about both the host and >>> the jail OS versions if such is involved. >>=20 >> Those last notes are likely too generic, in that normally >> official buildworld buildkernel activity is done on amd64 >> for all target platforms (last I knew). (Not that running >> such builds on other platforms would be a bad problem-scope >> isolation test.) >>=20 >> Any notes that help delimit what sort of test context >> would be a reasonable partial replication of the original >> context could prove useful. >>=20 >>> . . . >=20 > If the file system is ZFS, I'll note that main [so: 15] already has > a zpool feature that is not part of openzfs-2.2 and so not part of > releng/14.0 or stable/14 . So what zpool features are enabled could > be relevant to problems that only happen in main and might need to > be involved in efforts to replicate the problem. >=20 > But I've not evaluated if redaction_list_spill would be likely to > possibly be involved for the specific type of file corruptions. I'll note that the upstream openzfs master commit for the data corruption issue: "Zpool can start allocating from metaslab before TRIMs have completed" was on 2023-Oct-12, so not long ago. If the official builds use ZFS and TRIM but are based on a system version that predates FreeBSD picking up that commit, then there is a known data zfs data corruption issue present in the official build environment. Since port->package builds are based on a HOST/JAIL such as: Host OSVERSION: 1500000 Jail OSVERSION: 1500002 or: Host OSVERSION: 1500000 Jail OSVERSION: 1400097 but the Host kernel is the one in use (with the Host kernel commit not identified), it could have such an issue. (Because of such issues, I wish that Host OSVERSION related commit identification was also reported for the package builds. Presuming ZFS use, I also wish that the zpool features enabled were reported for similar reasons.) =3D=3D=3D Mark Millard marklmi at yahoo.com