From nobody Sun Jan 21 07:28:09 2024 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 4THlMF5D7Zz56pnh for ; Sun, 21 Jan 2024 07:28:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (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 4THlMD4BRyz4qyp for ; Sun, 21 Jan 2024 07:28:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=eXaBv5KS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705822103; bh=+aam5efiEq2o1zXvv7d1auvGOVe9vw8TV5C+OhVJWrM=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=eXaBv5KSp+685NR+xUk/HoonsCcOnKNcjew2aAZx/hAHOYZ458L8VGnmZhQRl8aXyTWu5Tg9QANVtTzOZ1mqvvz+hIUPaITtY/vvSQGU0/sP1605H27r0bczdffFQnCXy3dUntxVpKzjOWCrJYWeWPykgcItufkoSsOAt08woyYChbvlOzt9wBwDe4w0wMFzzJgAi2TlfummNpoYLILKYErbQJcn7Bko5Ae2g/AZtm2HgL/vtlxj9H93vGAxdu+eG6Ihc73FsT0TIL6Bsib6fcEzN2Ypyd2+uYy1/FkWCLlyUEl5BsY00LAZN3E5vPRztZI36FnJB1LyzbRDmOFLww== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705822103; bh=cGknLU0MYqcO0fR4VznZsN/qFbhrkcE4N8CHbaRgRUD=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=TbXKrsaMUfGch/+8zm8kTgwlJmqw/nNOSk562myroZv8ARC9H5Ac0Uu2+SjQgJzHUfJHaeUhaL6wpV3EGSM9B5phdwltS7A9TYJA8F9QyUUaiKUFtmVQ9pqd7QXPbeCUEG5qW1BSZyStn7lyHIQK+LlURApJnKQIwnDp6bD59+2HN5L863nC4EV/VfkPWxnuDeJMSEcO8od1DuJw4bSogoGZlHvL6MdIQg5y1tukronHypEI5loI6eJZrhhLIzz0Xvi2XbMqhYAboA+Tl26UIPFT4GlCs2kKeXtOcp1h/z/JEgy63jTbwLN5e9Wub4F6qMs9KLIS9o5QeqfHqv74fQ== X-YMail-OSG: yCsC5kUVM1noki_XWfdfVhyjVjjCc5bLfCDBodhRstD2.kjE623QFzZZS384uiE HULOLKqae8DJZpm3SjiX_aLbPAjwnsFNWGStWuwlAkY0Qk.pIE7yjhn77ZijGxLtEXzBMBV2Ptae RCZ.UTRHOAO8cpIEe7h9MYK5kgAnBeNFkxt7Znb2CfzGeDkoBQqehIzX0Tz60QBwWO2Kb7VZBxy5 BIZP73XgyYziKM0yI_jtGDkEg4GmmojxkAiM1VuLK5tMVsn771KOJqMnRxb4aSGk05M7Nvum28T1 QsP4FG.ck.V7SbEc1fHuU8oyb2_mNFaTro7VyF_XOUBaEvNwNqJIYzYMtjJSSDo6Pw2SCK._KFrW gdOf0UDHLc3xGLu_ypwdW7TafwxKtoASYk4xrsTKmnxnWiVNmwO8.Gd4FXXbGYksBrdpSJn4QCK5 zrUKAOeoDURyhWI0uuGwA0WXV.osJy0ZA3wLgMOp0i7jhZd0ntZj7N3IpxhuHf5E2y5WVnA43Tq6 3I7SgoQuScD49nBOBZjgMIS.GHSlGrvqJc.EKvk6b82X7uR4KPclmWuAhvmdPaR0bluNbI.sV190 vcFYyzZz67NZxDYfy2HgGjscUuqPNgvSnb_GD1sNbtI9SxXemjQzaaQE9jM8jJEvy6hISy5xQVjt W9RBZcvUgP.5KCVbq2ynHAf3mJocg.a0f.9IBPG6NpcNwb8nE_.RyOCS6dYLkCMp8F.iHFykEI4I 8PkZX6sOeG8KUCd2cw4XuHxxXax7HoXLkfpIKAyW8FhXjLRb4W3.SsJ3ba4nxri.R89rDfUvHmvP mnpCZtu3nK0Hd5.whcdSHvpNX5mqphXn4pfTDiT.L6c4ZglcZUg.z7oPpDwriZkjqOCUuzfoneFM lv9GJH_hTHfB_9Yt6PbF8hg7mQD4Lg3h4V4t6Y0ITwZOMGmFgcS8fYcR8hwZxua3WNCBxsM_7tWw QkPDVCDk5z8BX5PogV0qwd60FOffwGd605ktnAgZ2kqp34x7yPYZ_BMn6QB5jqffI5Ah1Ogx0p2D M83oxHj4xKdxL_0CH_0H12DFShtTvjXWoT9yg9dXoE9INsjxEHlt_qPxw8hEhWuVCsttOAWLfhhg dLc_kPUPWMrDzBBKUJrUY6aDRhQ1vLGVjb.E3LwYJtOA89OUdEF38r6M8tt8HKsimP_5xqV3xeVu kUY4JTOw2_3.dn9S_wX9W2ocCJx0nCY.r2pr0rUHqVWQQpeFHASzahSEUtxyySKIS8jkwIKF6ahM I39zhTO0EcokEvDWgBOLFs5GqJ.VcDI6y2t2gnWxEwcniFHOfCdVjdpQQtkyI1KbGtZsmhcBaCA_ aXA0VghTCmbUs03Qc0T.yhMjhDf8W8EBMJJ4oAwH.gJWZFMPzTUpgwd8BChfGztiAVTOMQX4WBKl J31WPhCwhwFhFfMwzPP30Z58wHHiQiP.vanTr1jV.yICfQd74wy.jo_GbkjMZXi_NOboMt7_Cj4f nOgJ0MVnZWh0_TzGifUGScdbUxkrmjQ1G.ma_Gqw2iZ5U7Wj5HZby0JBU8F28QAYUGcZiDlD71rA kaeGAyoHfNQRUbP0IPNrEUHLcf4.t7T.MuK50rKYFnfOTvbFKK_geX6KDU8AMiyA5Nik9jWP2ufN AOJds_smJEpXcjl8o_zuG5YOU9wkC2HSpRYuLRLelClStGZFcYqkjEXqpE2qzSo5rlMhg1NB9EFI WKguQFTLEWgdUHpRzMrqYn0lsGTGhmfy6BJfdY0w6E9dztS4cUDXR7d.id2qHEYZFMvqskBQ8h0K az9UGouaj.Ktjqy5C7Ce0CovODx5yrQmybtkBQXPAUHm1MFKyP78f62nHJspboPcJv.rNfoCkXVe duZt95o8RurE.uJhNNR91dbY91RYCyMfwPEZlL7JW44dtTWQsyeU6li93DgdbZtwprsECpSHW6m2 7jOWa0_xNZBPXVdLW8spPNJJHVOBZty_3NPTdLqB7ZXxNNjKQ6iF1NYgUU2LhMeP3BXRYzdJ9WEr OMgrj_cRSrGr70kn.k_MtggSBB_HzB_8eGwq2B33M.WCym2X4Dpox16YfbVcQmeIAZzvFQ1o_p0k cMM.ECotTeI.OG3XbruUMqdEciWKJj3EezsuZyrFDelDZNHlUw2QjV5BktAokwxCrFOCMYatWAuT LhCxyY07NtOFEkYmchiJExBSmLcmrmctXP0futaRkhJC8AbfYN8cyDQsZVud8cNthXMVr30GjGNv G6d7pY0lXzbwsa.0BWJ_mPo.2saAvFUi1vDKcg2mJWG6q2KR2WWqF2j7FTPX06gxq4DbfjzUU5xQ - X-Sonic-MF: X-Sonic-ID: 752cdbf8-3961-4782-afe6-f3fd3a381869 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 21 Jan 2024 07:28:23 +0000 Received: by hermes--production-gq1-78d49cd6df-k5hld (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8e0025e21f9b4ae312d84a1a3048d591; Sun, 21 Jan 2024 07:28:20 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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.300.61.1.2\)) Subject: EDK2 and RPi5: sudden 1000+ inode check-hash failures and such on occasion Message-Id: <4B59C446-3EA5-466C-BDCD-C710D2E556BF@yahoo.com> Date: Sat, 20 Jan 2024 23:28:09 -0800 Cc: FreeBSD-pkgbase@freebsd.org To: FreeBSD ARM List X-Mailer: Apple Mail (2.3774.300.61.1.2) References: <4B59C446-3EA5-466C-BDCD-C710D2E556BF.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.148:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.148:from] X-Rspamd-Queue-Id: 4THlMD4BRyz4qyp In experimenting with the RPi5 via the existing EDK2 I've had multiple occasions when the system suddenly had 1000+ inode check-hash failures and such shown during activity that scans directories and files. Rebooting via boot -s and using fsck_ffs -y / agree about the there being such. There had been earlier fsck_ffs / runs that passed. So far the experiments have been with main. Some recent activity has been since starting my experiments with pkg base and the port packages installed. This lead to being able to use: # pkg check -s which ends up listing missing files. It looks like when a file is missing in a directory, a bunch are typically missing from that same directory. The examples outside /usr/local/ in the recent case were inside /usr/src/ . It also got: FreeBSD-clang-dbg-15.snap20240120223308: checksum mismatch for = /usr/lib/debug/usr/bin/llvm-nm.debug g_vfs_done():ufs/rootfs[READ(offset=3D-432310823128264704, = length=3D32768)]error =3D 5 g_vfs_done():ufs/rootfs[READ(offset=3D-432310823128264704, = length=3D32768)]error =3D 5 g_vfs_done():ufs/rootfs[READ(offset=3D-432310823128264704, = length=3D32768)]error =3D 5 g_vfs_done():ufs/rootfs[READ(offset=3D-432310823128264704, = length=3D32768)]error =3D 5 pkg_checksum_hash_sha256_file(read failed): Input/output error FreeBSD-clang-dbg-15.snap20240120223308: checksum mismatch for = /usr/lib/debug/usr/bin/llvm-objcopy.debug In more activity I've gotten: [1/2] Installing FreeBSD-src-15.snap20240120223308... /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry /: bad dir ino 12259846 at offset 0: mangled entry /: bad dir ino 12259846 at offset 512: mangled entry It appears that installing/updating the likes of FreeBSD-src and FreeBSD-src-sys lead to an fsck-ffs / (no writes) just afterwards failing with large numbers of errors. (Many may well be consequences of others, rather than being independent.) But doing shutdown now, moutn -r /, poweroff and booting the same media in a RPi4B via the normal U-Boot UEFI/fdt style did not find failures via "fsck_ffs -y /" (writable). "pkg check -s -a" after going back to multi-user mode also did not complain. This suggests that the RPi5 was seeing problems in memory before much of the media had been updated with bad information (and that the "shutdown now" did not write out [much?] problematical data). Same media but on RPi4B using U-boot 2024.01's UEFI/fdt : "pkg upgrade -f" did not lead to any problems being detected in a following "fsck_ffs /" (no write) after rebooting. The above had been using the kernel-GENERIC-NODEBUG . I tried kernel-GENERIC. It gets the same kinds of RPi5 problems but does not report any other debug information while doing so. I wonder if: hw.busdma.zone0.alignment: 524288 (a.k.a. 0x7FFFFu+0x1u) that happens for the EDK2 context on the RPi5 contributes to any problems handling things. For hw.busdma.zone0.lowaddr 0xffffffff there are only 8192 positions with the indicated alignment and fitting in the 32-bit address subrange involved. An earlier report of mine showing example hw.busdma information from an largely idle since boot was: # sysctl hw.busdma hw.busdma.zone0.total_deferred_time: 0 0 hw.busdma.zone0.domain: 0 hw.busdma.zone0.alignment: 524288 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.total_bounced: 12018773 hw.busdma.zone0.active_bpages: 12 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.free_bpages: 1227 hw.busdma.zone0.total_bpages: 1239 hw.busdma.total_bpages: 1239 =3D=3D=3D Mark Millard marklmi at yahoo.com