From nobody Sun Feb 19 00:04:20 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 4PK5QB1c17z3s65q for ; Sun, 19 Feb 2023 00:04:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 4PK5Q95TBqz3wtr for ; Sun, 19 Feb 2023 00:04:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676765072; bh=Bp4LN9I161Zo84dP9Gbj9vv74GTybCZvvb0ekKUkWs0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ldtRHqxcAlIxxz6z8eQkgwn4Z6eGDs+rdeGbdiDMIeVc3lUkezLW7vOMIlkHvsT/iEMw1e2+J426ziM0gN1noLuRQbxV5mGg1wasla9pNDbVXiHGI9hw+sIWC6lChNvYOBVlKrcm5vp/zo1tO06fDgh57C9z/1+CZWzD5dks85FXB9Ic5m+BPUQhyahTdnKMktbW6rZbujKaN4lkiKkORfseIF0eyKylvUXM9f+2QIqXKUas4CAszv+zoauooGX+J+TzfObIP0HNb99vZE/qPC2KHgbIqJcH6vWCaof4OPBMwdYPa8+GG8BhE+sXXUtI3op/yoptLIrhorHWH8+Rrg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676765072; bh=glFWr3V2zgGZ2itaaUErlFcw18Kew5/ClZg6ApbTkq+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Ye2V2kQBzNgfXFIL6xhMCft5eE1mwZOXyUTYrCw5/yHNDjGiWc6cay9PwNKvlLDddIHBtOG1Q3HohWQwWffJg01on9PZlF1X/OV3LfN/CqRrACbaYv8bV01pLV5mDLDapzSiMNnayKhIuo8JO8ui0RngauYPuOXAEFfgm2NF8ilXUgxiJu8SgX+S+LmveuBz4CbP+elr56QkmkER82/KaCHWAGNXoJ7wbaOvXXdWwOHG6o/VO4kDUECX5jdf5AGNuoz5MxORbZ3UWaeqOBbSyGU7ttwQi73r+7RWF/FpTwlMlqHBRigQGScM/ojFrTFPAgl+EzdqlbZBiOAWJwO/ww== X-YMail-OSG: DDt4t0IVM1leHojl4jt.mnsFFN5.v21dpdURKl9GVZIK36OIoS6vCzOLJxFpy2p 6w3pPfVTMnjrRhG__sREKkjFtpdwQb29s7rODCvzPht_lhRjTzFezhdrFkKtnACXH7N0I1P_oOx8 v60EUOc_pAd17gIa8QsIBzQQRqK3EL82g2XWhfDyNcMu3A8cxF6UiFbIZ8slWLwLZ_8VDuTMbDMz brcrBNzDxgQCpslyZWFO8Wpqc0p8dtZoJINQtZ3tk4odL.VnYIm_SnieJCDh9.Tz0COFjZmPoAYw LMXx7rrZcky2ZMMZoiPN8vglsGu1a.InZrPKWnyS8HG46baCzrMT8S6pibHk8D15susok7Fvmyou 750aBbsdKKpi.Wa1vtosB77UFBL2QWH6QTY9Ike7qh5QKji6mKDOakMdesU7Co5jnxbnC_DLwdx8 2rOMetf6d6BNVJwh1bobbgtoasKGFOHlYWp8vKIrlhGalvSCv31pDnD_aDUNWRewPWv_9BGqPkNN EG8hZEAy3iz0Bk1NYDHjkjxQuO_3vOpn.rrUQ27WToQgGhEYdxUMnJP4Hco8NMrCUb.zsprf6sCZ TB9c_7ml5NQRaCUA5pQB._bg1L7_.FMPMtf0ozKfp56o9cSlo08ivr3yFZFIGgGFaJH5gCky2OA7 _0M_KdVHB.aRQKLmPN4CIJLiU3Vq0pY6pfVe4I7WT.Deh9ygvrqcWCscsywKu2FNNfsema1R.1ig eGcQ.FMzrQslOZbIDOK6Dv_oXJWLyZOdK.Hd7ewGqnoKKKK2IpqDRwCc_IgorRtnfvI42Wl.2qVZ .Mt_yLvdT.uoQxNj9PlBycCWh2cYWnFgbrMSyaElkM1.ZoFw.WPqOBOKvkteDEHQldIdSTAvKE5b dfAIi5XW77gKFCpIgvSeU3IHF_OxsdEoR3oHrW6xBbb3z3ipKPkmrT212hFqeQqslZanR5pA0aRA 7bPP9Tepvuq7y9rOqsivl8ofsv8tDjTzAY0XAlNQwhXb_UVM0I.1fdOYItGdqcp1WQwCoJS9ZbNh cPq9LPuGNUT65G9Y7P.IK9ggiH8XO0QDlR3V5_2G07pZ8ld8K8zvc.NVTD0tx8RQt69FIHv5Xj7i 6ozJrRdWgvRDn3Z6SpOPQ1GHRaapQwiOqHobpypkiO.3Dopf1hTK7yJPncg4kZYPvrinCnomOy8x XteHXMA86dUY21JfXtG1HL.n_p7RShII5JJnBNR6shxIgFEpJASJrR9jcChTTP9NbPlLVPuf1s3D G3ocXVWH8rFVRFNbARnUm4PNLrRTIIRL.wKCB2Gjkuhfv9piT9IIJuv1c8mu6KH7W2NkkSvaTiuC DFVa8irW8L8CkR5.iKeqE6DRwzG5Gszu1L1ARIT8BiFCcP_MrCRNsQzOMOJHec6cGFl3FdZAluHm ugx3r9xpdO6VWhNFSSRtkYvn_XGr_P0QMknwVVi7uAFcJRGCEeq6Qoz_hKEiY0FUJAhkwYWLxlRU I6TpVKwZkUbnSFJMxw6T4Iua57oGX5vOCsvDk6c_tYsyXdYWquYTyX.yU3VzP_sV3faK85Eq8xlp GsTFActsuZKn.TC_KU.guxFMCxSdkyZeDUgCXjMQ9ZssqGexItOzGNdVNIuBxlt4nwVjAoErLezq Pj3rQnuNeWAAQmCvtcmpPms3eO4d5JXpBCRpuSyby8VaV3pY8b6zEpoO9GviTox0KvcGRIHZw73Z OOYCWSiyIW3abT1m.8OR_PAyFQcWsZwcJ9iqDifsPyfS74YjfxRY4b3rQ1rFXgubCNPH5JhibLgb NrKj4KzHNqLDGXVcAjr7iufv5VLGBiSqHAbpsAS2W1hA2tnTK499MAvV0DE2EL_XtvPbFscVl3Ca e6oEaalyOqVFumIr.zQlNWR40CXXMs4_F8B1zL9l3HjMURzq1E4HL09fYTBTyS85x705fy_jc.7R u0ULRYFfZTPi7JUE7osxCeYUSBaNoliezt7Cm1jWdks_454eg9JjfOy30NwwWiWq9kUK8vm_MOMy QwK4VbpP0InPULbMs8tsX9Lurxq1.iVEghY_EEe8L_SoHhCVn9jLsgTHQoilT1s.l2WnWA0jyQ9L 3vzTxVSzE3HGfG9ezaO07KpMCD4YfKptkL_pCyqfVIOLWrrTqA..mJocLoDlPgcRKu8c9bwaBzyP hoVfO.e4GVmmgE9dDdwGU3c0BhDSW1rznJmAbOnH_Aiwoh.NS9zLk1hO6aNy3Y5kkXH7VKF6P5c9 J6m52Ha69JRn8fHFAWhHrihk.6H94f2cVPK1KVej4YeRkAo15EoxTwrfK9A9VZYjhg74dTEtWkLw - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Feb 2023 00:04:32 +0000 Received: by hermes--production-gq1-655ddccc9-nql2v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d92c823dad7a4622523c4c3e02524e82; Sun, 19 Feb 2023 00:04: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 \(3731.400.51.1.1\)) Subject: Re: freebsd-update confusion From: Mark Millard In-Reply-To: Date: Sat, 18 Feb 2023 16:04:20 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: void X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PK5Q95TBqz3wtr X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 18, 2023, at 15:06, void wrote: > Hello Herbert, >=20 > On Sat, Feb 18, 2023 at 11:11:50PM +0100, Herbert J. Skuhra wrote: >> On Sat, Feb 18, 2023 at 09:53:56PM +0000, void wrote: >>> In = https://lists.freebsd.org/archives/freebsd-security/2023-February/000146.h= tml >>> there's an SA for openssl. >>>=20 >>> If I upgrade (buildworld etc) on an amd box, it gets: >>>=20 >>> % openssl version >>> OpenSSL 1.1.1t-freebsd 7 Feb 2023 >>>=20 >>> (as expected) >>=20 >> This is either stable/13, releng/13.2 or main where openssl was = updated >> to version OpenSSL 1.1.1t. >>=20 >>> If freebsd-update is run on a 13.1-R arm64 machine, installed = updates then >>> rebooted, it gets: >>>=20 >>> $ openssl version >>> OpenSSL 1.1.1o-freebsd 3 May 2022 >>>=20 >>> ??? >>>=20 >>> The freebsd-update was run about 10 mins ago (feb 18th 1821 UTC) >>=20 >> This is releng/13.1 where openssl is still OpenSSL 1.1.1o; only = security >> fixes were applied.=20 >=20 > This is the bit that was confusing me. I thought 1.1.1t was with the = security fixes. OpenSSL 1.1.1o was patched to remove the problems. That does not produce 1.1.1t as a result. >> You will get OpenSSL 1.1.1t after upgrading to >> 13.2-RELEASE (expected to be released next month). >=20 > = https://lists.freebsd.org/archives/freebsd-security/2023-February/000146.h= tml has this: >=20 > Corrected: 2023-02-07 22:38:40 UTC (stable/13, 13.1-STABLE) > 2023-02-16 17:58:13 UTC (releng/13.1, 13.1-RELEASE-p7) > 2023-02-07 23:09:41 UTC (stable/12, 12.4-STABLE) > 2023-02-16 18:04:12 UTC (releng/12.4, 12.4-RELEASE-p2) > 2023-02-16 18:03:37 UTC (releng/12.3, 12.3-RELEASE-p12) >=20 > So, if I'm understanding you correctly, none of those releases = indicated above > would go to 1.1.1t ? Same point for 13.1-RELEASE-p7 here: OpenSSL 1.1.1o was patched to remove the problems. That does not produce 1.1.1t as a result. >> What's the output of 'freebsd-version -kru'? It will tell you if your >> system is up-to-date. >=20 > % freebsd-version -kru > 13.1-RELEASE-p6 > 13.1-RELEASE-p6 > 13.1-RELEASE-p7 That last indicates that you have the patched OpenSSL 1.1.1o in the world (user space). > It's really kind of opaque (to me) that openssl version is = '1.1.1o-freebsd 3 May 2022' *after* the update has been applied. If it = was something like '1.1.1o-freebsd-p1 16 Feb 2023', I'd feel a bit = better, because as it stands, it looks like, on the face of it, that = openssl hasn't > been patched. Otherwise wouldn't the versioning info change in some = respect, to > indicate that it had? The output of the openssl command likely is just as upstream has defined it, it not being directly a FreeBSD thing. The patches to the openssl source were likely also from upstream. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Feb 19 00:44:09 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 4PK6JC0HHJz3s8XZ for ; Sun, 19 Feb 2023 00:44:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (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 4PK6J96FQ0z41bG for ; Sun, 19 Feb 2023 00:44:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=p6cFbx0U; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 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=1676767463; bh=bMLt/fVPq06nFtcbWHILH9vBASns8aeC1BgNy47PyzU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=p6cFbx0UOJn7OaP2lhAkzdO3CBzkawOxk0tqzUO/zdfVmteMDrRigfrqDjJj7qUO1wfPxdxpZUgO5L28LCGCYaeTAZtpZLvM1V3gURd4HINH5MVwEiew/CYOqx04R6nTOFE8Z5eXkfDNJ37o6XErQ4Gs+560jfwAR/JsDg6ggtyVwlknIva9ip2X99WjN9cRY399Ga0PhdXcpbYybzfURn/QGrdRnIDcQZZNVqB1+bvybYqsqBdOvk1P5O188mmJ4BIc5IHcKU+YEkyvzD18VJLMMSJc9TctTPsj9u6seW8FPmBpTAU/v00Q1O73ZDGh2Oews3HMAYz1j0kpp0nUwQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676767464; bh=9FginL+XASS8HBEvloMNn6oNCW4l7SS1awP0MbK2yea=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=AcGsnzF3eB8S3h+c29xRf0Ba5zRhPMQZvpl3l5q3GipI0f7LksUX84Yb5oVIe1Ksi4b3i5XBsGOyejipNdOgVDFhUltm55AtLcXNQmjCHTPmlBrN0b1LfglpJP/8DexpcKArRQuoIh5k9J/0B0K8xPdMwJk2BlvUEFEkLSPABkEsE3x1HSy9ISHg73Xmyffh2wIgGIkt/y1Ph9AIcmHCcEse5+qIUnx95OMnpasZzyKNQMYYHd16pQlKi6pEr6UCVkKnueCBlPxbN3nUJuzBvA0OLvs/QeOq8YyPFWuH5M1qjL0OhydEmeNAiU/LZUYY/Z6SMyg8ZTeLTsJiiFKGdQ== X-YMail-OSG: CAWQpesVM1nhDR2iX93n0yjYibOqi5ZFZvZEmOmHugDdOxlowIUvhJ3NCzeXPV2 5skd81FIfC9iRPD1YqHCU2iy03VakeUaW.DhLYEpRGOY4fhHrXNVnbiv1PzQ_twf9wOR6cDoLAQC feJMh6yG2QnwVYaiuKpnrvHPfbDOC_WqjhovibxZOtc3pUa5KEvFKt24yRDNSBOQofb5_qx2JOQT FLPQBKTkW94r59JiBIOYs7Cbef.haUJjo0lUs.vWzhQtH4Sk0RDjf5ZGCjpCLJZm.DaVerKAZKgg MqoMSySlcMslbxH2EOmowprh9XzKkkWRuUzu9DYjJzGVJHW2LPTztQzWTHmqMnwtXJSYAYFjCwzu p2ku.8k0.Y9cy6CwbV5WXKLxNQcHzJZq7EzG2tcwOq7N3jTlA0outAef0_Nw1gKSO2xiyrAkyl1G 6D8Ek60yR.LGqVSvKow2Udoy5KIpA0LhNOpYL6aebAH3yOwAk3YxXIvvc1RcbSU3j.cUo33vXUQh 5Rfuq7EXUfcWRnfgmpRUbz69aAcJDGpwGDjKC4Ne_5gzWwCL5_Txho.jTQd0AObPDqphmPPx61Sp RPu5446hmeVsMukqtV8kh4sJdL2W58g2tSpsqN0KdMgemP5S_5WMmGuZE_HqmM0YeRwz9Jru5NuU _4JoMpdeCYZCiV0wkQY0qP2OND5uf.uxep0GRhKm.TmC_r_HWTb2s7OfmJk1T30qHBeQ1ISx7klz hdg33XXVk1ZJItb5BDhil11y79K.OxMKBAGzwJYVDBcHm4yS5ZUwHD7Gl2RyKi3waeynzIfA_TG0 HNmJzBRrXyxqeyCrhWTue5nx85.jvqNrOlJtyXJ8spGRINk1cuRtMhr4s5Z8FGp9RITYlWcEwAWI MFEveTSy04ibyS0Py3gaVTv6pfcEV8wLkyGRJU68cN4gaHW.fPywK80biKyVzKRxPDvR6nmg9l7_ latFDYlpnbkBIsVodL1auJjIc.I7h_wftMYNcMA0gGgnMETV.XPVcHZFAG6zR6sCoFQRF9az8BjX fYP5nI2knsUKDDPRAucXl3wd2bxB7Phr4Pwhf5lMCkONGklnRpDzGR0EEl0bpGfxsCDoSIvwGa0T rKCwVXq.jGL9B4v1ANmXx0cw3EDv.8Nrhj8s0MiiDRZEKbRanxypIF_E.QB3NACIDimzKg_4kNQc 5347OFan0rcJgIJAdScdb5b2hdV.HhmJS00iRVAUelCnXRUIEOqtvwsWHWcGPonrBojaFmkyF1ym N3oqUhGdbfSmkEOwnBbMWIO6IK.3QVu5WC_dhJY.2Bkj6e3C9Bn.KnDU.JnZ6OrDtV3PtJnNhch5 zwNw.RYCFc0NrEKMy2HNpDZibmFBofedceTZsKbgUg2sJCx1WM8Qwc6tujKZOFYpOktD5zbWLe02 HH0PtE_YJBO9YL7tuLFEwWL9spXioFpvOWq5Id1wUwSlHTCp1RpbnjqeyqO6KY0yYVT_Fi3peEnh op40XUvzIrIFiyKrak6ntMFTYSW2b5M_PdVMJ1o8u2XHKBZ9CMrfPVWdPHKK8jluL30hRPcYoDsi CVSi0nCbjW0ODOXR_VmKbiGb3VcZogypHJS4ejDzqn7I6f9TlltbxTpjBG1zC.UiO0Oo4RmDm57L 7zCgQj4gxmqhoYLML2.5QG2BgG2LucRcKjF.Px4_JXVnXkk1r7HfYgLYvLEcQgaOoEVhwui8oybJ qtU0zI8gSVVNbgfwFltHFXd6Nk5NbiFlrOkW6NA.N0JC2wvB.v9l7jMjwJEd8xb3_L0W4y0BUEEH wWtEsWQL6Ju36VXtn7JoECgu687lWqFBzjJU.q_M27YVtk8cJE5WS1H5R4PJ_.CG6FYH8zbyg_Ay IGAMH9KmV_CKeVC.EmRa1NeqLXW5WcxUQtVq3B6ry5ZkJxKDhvZuFfUOaKvHceBFUoOF8jCVt6W2 w5M1tQEqVCpYr40bdMz_pcMaLj_pTwQQdeYWu_dF6O7dwocmcHz8wlGskecDO6d4K4rthrX.ja40 8q699Jr1j9vWgg84C1o7E.3AdSz7WIQ.Rg4PuSsZAWp9LB8LvS8rW.KgUwVp72oRvqG8qJ0C7BWT ywX9YEYtJuwxOGViC1MqoZuUvuPhASXVbooRsb8Z56bpdteQIJtKJoaTyv7ku6VNUU52gWpDXR6J Wv1StyftZD3vjLHzrsTmTsoF4pvrfoHqW0W3uh4Xd_xNa_jzuQ1KB56u9ilva4BXBFDBVfOJtBTO BmD54_FgwCEDHaJDq2pYX8NC3UD6BJ5uP.FyqA03H2UvoX7I.Eay1KxDB1TyK1aUsARnwEc5.fbw - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Feb 2023 00:44:23 +0000 Received: by hermes--production-bf1-57c96c66f6-npzd5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4ac5943d9f0e442e37a27f0c1a232657; Sun, 19 Feb 2023 00:44:21 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 \(3731.400.51.1.1\)) Subject: FYI: upcoming 13.2-RELEASE vs. 8 GiByte RPi4B's based on U-Boot 2023.01 recently in use, given UEFI style booting Message-Id: <2B3378B0-A506-4A90-80D4-734AAA5EE774@yahoo.com> Date: Sat, 18 Feb 2023 16:44:09 -0800 To: cperciva@freebsd.org, FreeBSD-STABLE Mailing List , freebsd-arm X-Mailer: Apple Mail (2.3731.400.51.1.1) References: <2B3378B0-A506-4A90-80D4-734AAA5EE774.ref@yahoo.com> X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.80)[-0.797]; 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]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from] X-Rspamd-Queue-Id: 4PK6J96FQ0z41bG X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N This is an FYI about 8 GiByte RPI4B coverage by 13.2-RELEASE. (The existing snapshots and such show the issue now --but I'm noting the 13.2-RELEASE consequences for as things are.) When sysutils/u-boot-rpi-arm64 and sysutils/u-boot-rpi4 recently changed to be based on U-Boot 2023.01, the U-Boot produced no longer boots 8 GiByte RPi4B's for FreeBSD: U-Boot increased the number of U-Boot "lmb" regions it uses for RPi4B's for UEFI booting --without adjusting the bound imposed on the number that can be in use. The 8 GiByte RPI4B's end up over the limit during part of the activity and U-Boot aborts the UEFI-boot attempt. The U-Boot message about this is misleading. The middle line of: Found EFI removable media binary efi/boot/bootaa64.efi ** Reading file would overwrite reserved memory ** Failed to load 'efi/boot/bootaa64.efi' is actually caused by the rejection of adding another lmb range, having nothing to do with potentially overwriting reserved memory. (The message is generated far from the code that did the rejection and no rejection reason is propogated.) A FreeBSD bugzilla for this issue is: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269181 I'd not be surprised if U-Boot 2023.04 has things working by default again. But, until such, either an older U-Boot, such as 2022.10, or a patched 2023.01 U-Boot, would be needed for 8 GiByte RPi4B's to end up being directly bootable by 13.2-RELEASE as-built. I'm not aware of any other type of FreeBSD aarch64 context broken via the use of 2023.01 U-Boot. === Mark Millard marklmi at yahoo.com From nobody Sun Feb 19 01:09:31 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 4PK6sF2sfsz3sB6l for ; Sun, 19 Feb 2023 01:09:37 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 4PK6sD3m2Hz47bw for ; Sun, 19 Feb 2023 01:09:36 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b=vqhgA710; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=gqOo9xPj; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.25 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 7050732000CC for ; Sat, 18 Feb 2023 20:09:34 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 18 Feb 2023 20:09:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1676768974; x=1676855374; bh=WgApWvz/ox 9xVjFftwBdGv3utNy3C1s4r702jOmqQiA=; b=vqhgA710+Hb//ul6dN/t3jRswv Bcj5EWNxMvu/gXqLpiABZvbtj9gkbQYKeW5ufR0Ssur37mG6VJjebBt90jhqvxgU 0BW5S3aWwcqbxoOqpCWhrbRjJqnswFFnPb3t42j/6Aaz0UxwSKHG9AubeD2y/Dh8 lhfuCphZbPxQsIobWiFBsHZkErmAGhZRlKNNE6ZWnNnXqAkL8nnG+en3K64Hz9St kV7NKg3IjvaNHn7NDAG25+URpnSSmg4TGTGXZT4Z1BFqcJKFxuM4q2xx/60T35Oa f8NwleU0IVhBQCppb5Ncim8zYxpikkniNbmqT8ZMaBa4c6B/wqu14ldA3mlA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1676768974; x=1676855374; bh=WgApWvz/ox9xVjFftwBdGv3utNy3 C1s4r702jOmqQiA=; b=gqOo9xPj7sBEjGhGKxa7RiICLf46Dpi28fgfEeM+6i9x oQ2ybErPZ6Agpt1On02q3xrmXg7BtYZmX8G5XsjeBAdDpDx5iArAT0LUEKniwOI0 SDmI1IqbyY6P4FNKSlLO9mrlHEtor+wkf8guIcWQPTw8y2Z2FVA0W/0JTzeqm4XI JpZ7YMVf50S9TwXt93xErjWJVXrY5LVNUeyfuBP4HRb/Fn50Av8ZrF5JagKZZXyj i8BEMb/iSqDCUS3IEwEciQnQQfsf15+xs8vN7V0lHKFBsez8xvMacsA2xAGJxVO4 DEw/R8UD4l1KWF6gS13w3cY2ruTl8wJVhi7UNXww+Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejvddgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 18 Feb 2023 20:09:33 -0500 (EST) Date: Sun, 19 Feb 2023 01:09:31 +0000 From: void To: freebsd-arm@freebsd.org Subject: Re: freebsd-update confusion Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.53 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.995]; NEURAL_HAM_SHORT(-0.94)[-0.941]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4PK6sD3m2Hz47bw X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 18, 2023 at 04:04:20PM -0800, Mark Millard wrote: >Same point for 13.1-RELEASE-p7 here: >OpenSSL 1.1.1o was patched to remove the problems. That does >not produce 1.1.1t as a result. ok - so I'm understanding from what you're saying is that (in this case) 13.1R is following openssl 1.1.1o branch ok I wasn't aware it was tied in this way. >The output of the openssl command likely is just as upstream >has defined it, it not being directly a FreeBSD thing. The >patches to the openssl source were likely also from upstream. I still find it counterintuitive though that after being patched, openssl version still returns 3 May 2022 and not the patch date. -- From nobody Sun Feb 19 02:28:50 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 4PK8cz0Zb1z3sHBB for ; Sun, 19 Feb 2023 02:29:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 4PK8cy4qX0z4F5h for ; Sun, 19 Feb 2023 02:29:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676773744; bh=QJQbSpi80ETwAynCjY/l5xayoDik06TGoefxOBIvwfI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Scvx/rIJDb+JRjIXDcMV7N7w1i2VqKP/ydmuizNQuUhqcMXT/sbO1mcn0pJ6ULKJ/v+yT2suFPsMqTOCFxJI3tNhDOwkTKSRG5zDake7/PGHrwGwJ4DlxiQ+VH9qiYAndYv8SiBKkRQhB2GAd64a7GeInoU9NuF+Xx57Z3kvzcZSrtblLYaVUk6JtlYIRUvMPKrzMJ1Sl1RBZXEIqcVGJ+m4lRYnOCKPJN4Cp8xGFHRuhJxVOWXmFyGpi354Bq88EibHycaVL38jZsv1C28GEOHAWvwKFJoInG65rOYWTCBLNK9hT+P1v7xI2wTEgm+2mWMa8FXE5tez6Vaq2UklMQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676773744; bh=Vrwo9X5Rf2Fb5IftqPan380HJQuC1Gq+aiDTGWsEMim=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TM0LhI02lANEXc/tIWOOKcX/coZmZr8DZ3VODNFgj2YnHJTt4BifOEYIOmvwd28c49lflPYniaLFRv1r9fo62tU2ogF18OtVqkq5kXbW89mCbJNrMItmClZQ7Es1JM/abpwjysUITZwyssHoM8GnlvLccwzYCnys52J5/TM9rDbLkSDHrtt8tHEbs5LB+iHJK2aTSeVHEEZQ7GE8MHVbAvgqPTFWU5+JIrLDVG5DGrRdhzTeSU+3KxqJsfutOPphb4lb7yhNkaLGmjWVetPdYT5Y1GsPrITeQXR+mhssn6b6C+NB2mCdqm7xA/fip6O/p4xEdzpvV5ySmGuzgs6Qhw== X-YMail-OSG: YrNrY.YVM1kLw2lNhmqcIUd8KnjHJzjUIaeKx7vz_1h.yODD0EF_rITwl9OFeud 5I.lIPik56aTmdtnwFUh1Z0fDt6xJTTxT6TWghhaMFIisBPlSWA2qtKEr5lfbTzrPtN0hPxqSCkM VhOJpK2uAY5ubX0VFiHqWC6O9xMOZPbArN93cblExJXT0b3SB2W2KybBZrVdn6BpEpwubHcuAtVg W9zU5293Qu8x29LNqzkTffNsc4YLe2Xtg_pOY_cMZ_H.H3xfSClnM2mDEHHjqDkvcA3CXDu_8KZD OTc6rkKFyVS5jjk9_3NGdg3PgOSxQCNc_SNP3tn1.7cZJiLxl_PD8O7332OMQpciKK_CguEFtLXd GiUolTcdTGytCqb_uwBojaY6THvpEEj4RbLq2y4b_8UOtyqA3QaLCX5LW1Fwr8tadG9ArGRevN5f x1ife8J2yXivldBKZFiJdR26iw4sj2TTxYTeT4r1KyNPkj5Ww8gU_FnlWsACERQyN1hPtVe5X4jY H7J.F80tbzBKqGXiDD1.cmLce5BZjxS969Bws2DUXGWhPMXnpx109QHpA3BPImhsGka54brwwLBR qtcJ32yK3LJVIazSyDkK1MkEz6qiI1LG2ZwDidYQ1JHDHzzFOnpHxfHb2bC3GmTjzNjsGmHtbjRZ z_NXP98ESrTqwolx8UTw71pGBFMc7nsJ8V1qeELaFNe4DVzmazTyYMvjYcbrOzevuho44j7ce0tb SZvtP3Mp3EWx5dDiGzYwjv3Ez31gXmAT8fjj0YwrVhdTsuWaGdvSdHYT6RXi2HGY.1pjuyAYV_NS OVtvy7bvagDJra.SMQQf4hH.LVwNKSGCQVnMOhlBIRzgDt9EJIyeEVJSsaEReejQkdAMpnqC659j _Ho5elHJyx9HOGRsy6v.aXfzwct8.4F88utnnu0lyk6p7qwzjurjqf2GISzjXaN_dKbVb3fotfX8 RXr8sVEg3y1Us4Hol.sfkcPvqIv.2JH7wnWdSH162BIv2rIP6vRjyHeMAcoXKRoIffnNV63oQBnI xdWxgEEBB7z05Zxgn2KZUn26gHdlD_.uB7KA92xxScHjiBtx_NtDh.iTDu1qnhqOVbt2IVmjais4 fYx.BLbeYDN_IY2_TADRiJQUQDLFS5BAjHNuwS4PaUFoKDw7zDKTFQTmaipw_Z0S5DzmVvWaBkqD OFej63_RHF6no6cM2NhPA7VKmCDJw2qKouA.Xx1uKVxyKUBxCTKf11HOrUieS7xXBlNUwcpBWyJQ PRfxC5GCOcOLct7IbrhlIzB9cK3R0klhI4ZkIhBUoEl2h9z038.Y6s2hGfvqHzvpm8E9U6QN0gGj po6bkWure0KbUxCNFN0Yg4T33yOBiunvTcQRYrCoINkW4dlw45wsK.uveddILsrJAC4k6uwrwYN2 EVw1xtmJ28DLka6iEok0acETzGWr5ZtELmosk6_NZhlapLn8MFStV3M1HXgqiKEFVUg0AnAKmPwT qdhh9civghUnyM6zk27H14s3doGRnQlGIMKjssYomTfdSGyBRQ9ADhXHWJXH9BfTbpWhHC.g_vnf vYnL6hZReL5PnBzph2ZbAVtMgsLh596JqiZA5TL8Oo0w4PgsdS0WC.KwHhb49mjn_Op86tbb5Y8J k1Wy2St5eSEdUaUlu_p5aJislYAORrUfBIhp7gvBcLFGg7A_M4w7V1KePhK38o5HprMutDd5Yb4t 0cbZ5U2K9Y_QU9bmWkbuVaF6CR06Q6kb9eBIBiA5w_kmTGEdCl69Ah.8RffMig4rfVU3_idPdGV5 kFeEPzYGh3ZYIsbcwXKlz21nF.DErenTZKPpak283mU04agzrmcFzarLTCIvvWz2ETKMhm1l5sLM r2ILHroNWLhXCaXdAaOZCEShN7GBMTz_vLtIwKWYGI2z5TyCoGzljUZ6s5zNZbdB0xeFXDZ90hxj z0vX5XANxVpAQIGuD5dWmsG6geyR1IwUmTglju2Op1.E2hkxp.SeVYThMSKJ3mWD3Mcl_5wkrD9m lmeRceT_3mHQbwrAONO_dNylHcz0PWzAZPR8ChMK9Of31uoT2o_Ux7Rbonhcv5UtokYZefEv6wTn RcTa8m4HFyrSnC17y0dY.27ADAew5FTJXA5rB0ESDNSMuMWbGmIMjUm3zDv0OIVYG6A_5MKAUowO E02fMRK5upb21x4TRJN1JT8rrA.XlPAtcya_EAfgN3guT4MaALen2659syCfDgo486hCn5sN9EHJ h6NlPUoUhlbrf9Q4Kfqoke.jXTRtjph4_MlgrF2mv2jWFHHKGAQ8xcNbyiEDSAWmW9mN2nf19Ajy I X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Feb 2023 02:29:04 +0000 Received: by hermes--production-ne1-746bc6c6c4-wq9r9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7b5101b4723e54b3b5a6fb8434b33dd2; Sun, 19 Feb 2023 02:29:01 +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 \(3731.400.51.1.1\)) Subject: Re: freebsd-update confusion From: Mark Millard In-Reply-To: Date: Sat, 18 Feb 2023 18:28:50 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6429E063-2B5F-4426-9885-EE81493CF0FA@yahoo.com> References: To: void X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PK8cy4qX0z4F5h X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 18, 2023, at 17:09, void wrote: > On Sat, Feb 18, 2023 at 04:04:20PM -0800, Mark Millard wrote: >=20 >> Same point for 13.1-RELEASE-p7 here: >> OpenSSL 1.1.1o was patched to remove the problems. That does >> not produce 1.1.1t as a result. >=20 > ok - so I'm understanding from what you're saying is that > (in this case) 13.1R is following openssl 1.1.1o branch >=20 > ok I wasn't aware it was tied in this way. >=20 >> The output of the openssl command likely is just as upstream >> has defined it, it not being directly a FreeBSD thing. The >> patches to the openssl source were likely also from upstream. >=20 > I still find it counterintuitive though that after being patched, = openssl version still returns 3 May 2022 and not the patch date. --=20 >=20 Actually, looking at history, there is an example from the past that updated the date (for 1.1.1k) after the actual changes had been committed: = https://cgit.freebsd.org/src/commit/crypto/openssl/include/openssl/openssl= v.h?h=3Dreleng/13.1&id=3D9d31ae318711825d3a6ffa544d197708905435cf shows: Fix multiple OpenSSL vulnerabilities. Approved by: so Security: SA-21:16.openssl Security: CVE-2021-3711 = Security: CVE-2021-3712 (cherry picked from commit = be158ffe54dcc4a633652685afc5e37894e10ea0)=20 Diffstat (limited to 'crypto/openssl/include/openssl/opensslv.h') -rw-r--r-- crypto/openssl/include/openssl/opensslv.h 2 1 files changed, 1 insertions, 1 deletions diff --git a/crypto/openssl/include/openssl/opensslv.h = b/crypto/openssl/include/openssl/opensslv.h index ec4a1123f131..328d0971c414 100644 --- a/crypto/openssl/include/openssl/opensslv.h +++ b/crypto/openssl/include/openssl/opensslv.h @@ -40,7 +40,7 @@ extern "C" { * major minor fix final patch/beta) */ # define OPENSSL_VERSION_NUMBER 0x101010bfL -# define OPENSSL_VERSION_TEXT "OpenSSL 1.1.1k-freebsd 25 Mar 2021" +# define OPENSSL_VERSION_TEXT "OpenSSL 1.1.1k-freebsd 24 Aug 2021" /*- * The macros below are to be used for shared library (.so, .dll, ...) Looking at releng/13.0 history: = https://cgit.freebsd.org/src/commit/crypto/openssl?h=3Dreleng/13.0&id=3D22= 61c814b7fa4730f308b476eff1afb0dcdf35ec also got that change as part of the commit on that branch. So, may be the date in that part of the text is considered FreeBSD specific. (My wording has ignored when FreeBSD contributes material to opensll. So, sometimes specific changes might occur in FreeBSD first.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Feb 19 21:00:20 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 4PKdH91gkXz3s1Yt for ; Sun, 19 Feb 2023 21:00:21 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PKdH86snYz4898 for ; Sun, 19 Feb 2023 21:00:20 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676840421; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Ucj00W86hHKs540QQoRmimgGxZEMXWxPFhQ+zM2AW2E=; b=DJ+sBOzMMc1pXoBlk2iS3xT1OY0t0b9RhrWeIORtMJLTEa/mvf+axjps/ryJ9HoHiQHeBv /foXxDYZTFjo0aaESMas9ycIDF4fSLXspmBDBzj4X37odymHq+bJUeJ+FJ7TWH8MVUcL7+ NBNwqBnyiFookgjIVtK2D6C9FefTm9MMX81MSePTLnHTpXObue2RJZEgvl6Ok6y7X38uXU bxrBhz9vTt6cdp8F2iPW6D1pKt/Oo7+s7a8nMLkYgNaTQxHVk59F2nYiO7KgfBAfx8C1rY FPctPlR0LZOLMRl0/CmclMhKfH+r1iQYtCXxm1Cc7qk44M/Rn7ogBdUvsgWp3A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676840421; a=rsa-sha256; cv=none; b=v47ie7AjqvujG3jovuev9QR7c1fSsemmQt6yshKmNlvX8Bc5Dp3BF0/Dfl5wL76daUiBBB fSwchxFuCPY3221em5szJY1B7vmEn5r0amukFvlQdvZ3YxNaZkdsqZx7imDO/29ytt/Z2q dVsrl3GPAWZAmP1EYvcmBU/psP3Cjoz3+H4+Gi3ZxYsHtgE9NvTpPEawMvOU4iqT9N+zSA 2Ld9UvX14HZAccmJ3zzTBtpdRVcZw62TDO4OdGwsVThYaiz5M5fNiwWOV18lacUbnX2sDj FPyGon3ty/oBTxfYuUvhEjQZyH/OpajxwL3un0K4J1soacZtB1Uc/lw0i9UgzA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4PKdH85y1czGHg for ; Sun, 19 Feb 2023 21:00:20 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 31JL0Kii046110 for ; Sun, 19 Feb 2023 21:00:20 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 31JL0K2A046109 for freebsd-arm@FreeBSD.org; Sun, 19 Feb 2023 21:00:20 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202302192100.31JL0K2A046109@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 19 Feb 2023 21:00:20 +0000 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 Content-Type: multipart/alternative; boundary="16768404203.dB5D.44161" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N --16768404203.dB5D.44161 Date: Sun, 19 Feb 2023 21:00:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 2 problems total for which you should take action. --16768404203.dB5D.44161 Date: Sun, 19 Feb 2023 21:00:20 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat

2 problems total for which you should take action.
--16768404203.dB5D.44161-- From nobody Mon Feb 20 04:45:44 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 4PKqbh1DS9z3rtTZ for ; Mon, 20 Feb 2023 04:45:20 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PKqbf5CMHz3lQ4 for ; Mon, 20 Feb 2023 04:45:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 31K4jjsh058232 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 19 Feb 2023 20:45:45 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31K4jjP7058231; Sun, 19 Feb 2023 20:45:45 -0800 (PST) (envelope-from fbsd) Date: Sun, 19 Feb 2023 20:45:44 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230220044544.GB57936@www.zefox.net> References: <202302192054.31JKsq7w079295@chez.mckusick.com> <3DD8EEC2-6135-42A0-A80C-F195CAAC025E@yahoo.com> <20230219222328.GA55941@www.zefox.net> <2F5B20E9-AFF8-42F6-9E1F-50BBDF4E1B79@yahoo.com> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F5B20E9-AFF8-42F6-9E1F-50BBDF4E1B79@yahoo.com> X-Spamd-Result: default: False [-1.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.997]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[zefox.net]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PKqbf5CMHz3lQ4 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Sun, Feb 19, 2023 at 02:35:15PM -0800, Mark Millard wrote: > > Kirk likely monitors the freebsd-fs list. I didn't notice there was such a list 8-\ > Kirk likely does not monitor the freebsd-arm list. > None of us thought to switch to freebsd-fs at the > time. The only part of your context that ended up > to be arm specific was original buildworld crash. > You definitely started in an appropriate place > (freebsd-arm). After the crash, the rest was more > general relative to platforms and more specific > relative to file system handling (UFS support). > > I do not see any reason for any of this exchange > to go to any lists, given the current status. Alas, the story's not over yet 8-( After getting the disk fsck'd and booting once more, an attempt to buildworld using a fresh /usr/src and empty /usr/obj crashed again, in I think the same way. This time some notes have been collected at http://www.zefox.net/~fbsd/rpi3/scsi_status_error/readme To a casual glance, it looks like a hardware error. But, the machine seems to work fine until it's running buildworld, and then crashes during a relatively easy part of buildworld. The initial error message is: bob@pelorus:/usr/src % (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 43 29 d6 40 00 00 40 00 (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI status: Check Condition (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error) (da0:umass-sim0:0:0:0): Error 5, Unretryable error SCSI errors are not unknown, but they usually succeed on retry. It's not obvious why this is treated as un-retryable. Are there any simple tests that might help decide what's wrong? It's likely that re-running buildworld will reproduce the crash. I've placed the results of smartctl -a at the end of the notes. The interpretation isn't self evident, hopefully someone else can lend an eye. I'll try smartctl -t after a good night's sleep. Thanks for reading! bob prohaska From nobody Mon Feb 20 05:50:45 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 4PKs3X2KnKz3ryfZ for ; Mon, 20 Feb 2023 05:51:04 +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 4PKs3W6XQCz3qy2 for ; Mon, 20 Feb 2023 05:51:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676872261; bh=ILFKGihcB432UFw0tCVhHGAdz0MR5G/oTOJD1HpVYtU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dATacpgPt/i5XKmNdCR5h8F2lMcLMyUhYsPEZWXpxUVCx9DMUTyxjPOshpHY0lHj5ERaCShrPpT6ERgk76Bd/r6BVLDMM4ykklX3BCfh9PyygdX4YO5rpcdmdI85TMmzBDc9r7ZMrLuYuwMx81vVdFUWWp92UOMUir3oySb/Vp7KQ2ueBON7o/DMlSs1t/TqM2rVw27wLwYRVoi0GzXLdH4ZuDVVpkyB6KVqnyoMwDkUKlj1Ex9UPvXh3tI6H2Q5GgKUGM0t/jIm5xPefTpfhfhtSj+kn+N8azYL4K+wYdz/yFo8wRXFhZK5x5HGxyS7oZQ435sZbDBhcEiQNz2H/g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676872261; bh=P+9SRqiFQEsfiHtP2fUOZ13xszqGX2NWuOS59Bvf2wa=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=MwJ2Ot+mdE4HildWgIYbDNT+7NQuWkShf5TXdUXCuU7L+cjOAQVG+BCuwSHBfOnhlFijn3TG+f7n3etfz8ljw9OvARbT+1OZ6CQphiHhL+qGu11anGP/bCpsb1b+MW4AoP0GnyMArT9ckiGjKM6a29TXiErPzJQIy8yNJ5g44Byl5YN7jn6XwuFwxg+xGxOegJZaAlq1QtEUXkQgUeFYeDSwVXfq0eYMICDWcLYIDcHnd4+p4cfQx4HjskTx8KYqWLwNhN64KR+7fPKLRNuteHPVHoLhawXy5QsiKxWfid7OQCErQXYOybSo/WrYNBvpNjaE5XIXPGhZIDCQEnWItw== X-YMail-OSG: lexE1OEVM1lvUN24_w1cf3zhTDM_ZC79vVeOdli9dr0QB48ubqgu9Yhh0dcmvGS qFtKhJOot359YuQdjGSh5ZMEf6KlKk_Khr4JGd_Nr7pMFLAr1ha78AD.F83fDZhela38DSx2vO5J gdNbBOmN2dmAyEl0EpCnHHORHUrYftCO_P8jsIGPubu6DDvEOLIf9fDRWOsrxxl6OvXSBZ7jHRlj Pvk6cSJTUPu9O5OVzQ6.oWag24VZhGmx4cJkW694Vni096aJu7NpwCgyFdBIJp7k1g431GJ5YEvc _KwLL41PXLN6UwUWxHEbyiYvgpeJvDb8KkY7MSjAfRl8kg6apPPxk_QhjQsmFzAUPPBZUWZ54QuK Z_DAUUrcA.44DsVoP9IKU0L6MB1d26h9gG_SaTR9StfAoG47XXWKf62iSovSJooWju293kskYXE_ KvKbZlKaDWgvxB5t0LaCL.vJJTt1Lj18LQ1T3B.bmHJN_mVj9Rc7IOxKyRPL8IVGmze9KL64Eh6L HJ6zAzOcwM1pDMzSh.AO91D0VQSMvoSBiQknjm1qJJGzlIUVbMHAFQDdsRvhAhG7Ai4RyMnSATQG uITODXnxumr_zHRZUIame.W0MPcQ2NSNVDzItxknRZiWIfbEOkhht.853YH2SNTiwCjRd2SjelCZ 2QBjx5uY9ss3zhQ0gNDXUFzAAU0.d0Ka3YD9.gdNY5c0Z0iQrJHzSPtXun9fz5nxF2k3lHrYL0ZA nlEDG0pehlp8IKJuFFM5FTYz_vZiu9MP.9s5.5oe.1NlObQVYNJSw7lLVfAqSJ5VKz0JOtRPyRm8 lSlq57B7yAAu2BGO4Lr0RTDzrd8Yj9zXzef70ZOeIgQeBtJ1J72lW.Amzvp8ubFRZiH5h6TFzzMd RGQ33cmxFguCMGihJshhzhkntpf1ewpWqzqm3zDl5e3x_8xoQqFIb0JyvdApliOtwd.c_M6zL0Ae fUbdnmj2C9VJe6IE76ULua8B2mbJfbkTYMFVCNBrKQ3EaGg1oMgGPijIVEQyWvN3CCiGJwP6i_1r xM6AIcbWxx3QrjYnO3QnZyzrPHI_U_7YatgJu9y22ZOxq9kvcc5brooHpJqYiGfrSc8B4PL.nOum HN7PDcvpy8A.4AEW6jUPn_OgOFgSeWINBOMVjasO9RBRwiluk3oRbDuWfT1Tyy9EoI1cpUyhBDYA Ns5HoStrG6Zamz7t32tg2ktT9XvL_u7nqcHWHFFNd4Uf60Gk8Do4TlYmaFCtGaWxERMlIVC8c.3J .twaSmQwx22egBVgKLUSltbUgY2gFjIwOJLPR.jmbMcd4zGgnSrkYs21V3tbtqteDkaGbJ4PiRj2 Wvyz0jt3ndEV9JGMhOTvoB78uGh0b5KM1bIRZGa3WuRVNHsMcJjf0l3FIdMSMcKRfWQmTLDoPzDT ost6cEgIzowJQpnj2eIP2AuD4JfJie_EA1YoZgt_vW7Ezgrvc.2fR3kDqoKUyyFnz.1cozATOfAx eKB8T9_E0UArFLfMGkF_oxsh5b4h.i_aktxJKb9dTkEtmVCJAhiLHSAKq68G68ZETiKQJiVsVyiX XlhFNxHUkpjPUJF6b59qCKyEPCPzboZjeEPQsRckaXxe9z5O13JV3H2SgFqtoJP.Mge65A7F.iYK P_392zMSb5CWnmG3CZKY.IF4y2Xj7UQ6kbC5vL07c3NNoJGAdAP62B4QxIKKlwlUiT75nKsC7k62 jpPnj1yPPhTp9BTlNkZoSlC6WzNT2kpjMFzhEVgtc4tSGAn.f.z3alkgNP5I4WpBYjh8ZLuOw9hM Mxc3BFim_.oV5FE9WrjlA.wDWG9Jak4MlduoCODhxWa57NpoqA7L3_XSNf6HhppoH9ncSfv_P.qm Nf1W5nw2E.bC3XkBEOXT9n7oSp4XmcUGB4Oy8pOj.KNKxbzU6UO1heX0Kd70W06ZvdU1OYPWlID4 RH04jkx_XL47sruQSlFIjbWKZpaI.GBYIpGHzBEf2VBZtMhTMGILYTgeRai8dBIq8k4cOjSMQK37 7xB1EM49cSDZG8c2q.9zgZ4JGHJ.DZ766UcLqh1.m3zP22xLkNSY3wprnOiiNH04otRIzO9zdXpi rBKbTs5ZXF3w1J0IvrTuPpaWV7fa3GPjDETLtvu0QEeL7RD4CTzvoUksewPJ6gXdlB47Hy9yvKSt YRLMlhKztesA_igs62yE9FHGMuAtUMN1Vk_SNxCAtqUPpsxzgV.VNgAvMGIAan8pF6Vdh_tSksy4 T3xkFfKjwWNpnyX._Dp3A2k5J2U8SdfLDFDoJ1p1q3Iva3dNwPhPpaNGQ0k1E7vCQItrceRiTSTL 4Gwk- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Mon, 20 Feb 2023 05:51:01 +0000 Received: by hermes--production-bf1-57c96c66f6-76kbw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1a078502384662df17a582e6b8f0bd1a; Mon, 20 Feb 2023 05:50:57 +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 \(3731.400.51.1.1\)) Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) From: Mark Millard In-Reply-To: <20230220044544.GB57936@www.zefox.net> Date: Sun, 19 Feb 2023 21:50:45 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9CEF4E7A-2F13-454F-A04A-A6C5A80FD4B7@yahoo.com> References: <202302192054.31JKsq7w079295@chez.mckusick.com> <3DD8EEC2-6135-42A0-A80C-F195CAAC025E@yahoo.com> <20230219222328.GA55941@www.zefox.net> <2F5B20E9-AFF8-42F6-9E1F-50BBDF4E1B79@yahoo.com> <20230220044544.GB57936@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PKs3W6XQCz3qy2 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 19, 2023, at 20:45, bob prohaska wrote: > On Sun, Feb 19, 2023 at 02:35:15PM -0800, Mark Millard wrote: >>=20 >> Kirk likely monitors the freebsd-fs list. >=20 > I didn't notice there was such a list 8-\ >=20 >> Kirk likely does not monitor the freebsd-arm list. >> None of us thought to switch to freebsd-fs at the >> time. The only part of your context that ended up >> to be arm specific was original buildworld crash. >> You definitely started in an appropriate place >> (freebsd-arm). After the crash, the rest was more >> general relative to platforms and more specific >> relative to file system handling (UFS support). >>=20 >> I do not see any reason for any of this exchange >> to go to any lists, given the current status. >=20 > Alas, the story's not over yet 8-( =20 >=20 > After getting the disk fsck'd and booting once more, > an attempt to buildworld using a fresh /usr/src > and empty /usr/obj crashed again, I'm confused. The original crash was reported to be on a RPi2B using a armv7 kernel, or so I thought. (The RPi3B was for later fsck_ffs activity for the media's UFS.) This new material indicates a RPi3B arm64 (aarch64) context for this buildworld failure. Is it the same media as for the prior buildworld failure? > in I think the > same way. This time some notes have been collected > at > http://www.zefox.net/~fbsd/rpi3/scsi_status_error/readme >=20 > To a casual glance, it looks like a hardware error. > But, the machine seems to work fine until it's running > buildworld, and then crashes during a relatively easy > part of buildworld. The initial error message is: >=20 > bob@pelorus:/usr/src % (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 43 = 29 d6 40 00 00 40 00=20 > (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (da0:umass-sim0:0:0:0): SCSI status: Check Condition > (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered = read error) > (da0:umass-sim0:0:0:0): Error 5, Unretryable error A description of "Media Error" from seagate is: Medium Error - Indicates the command terminated with a nonrecovered = error condition, probably caused by a flaw in the medium or an error in = the recorded data. To compare/contrast with other alternatives, see: https://www.seagate.com/support/kb/scsi-sense-key-chart-196259en/ A more extensive list with asc/ascq involved as well is at: https://en.wikipedia.org/wiki/Key_Code_Qualifier/ Allowing more comparison/contrast with other classifications. It indicates: 3 11 00 Medium Error - unrecovered read error (matching the reported text). > SCSI errors are not unknown, but they usually succeed on retry. > It's not obvious why this is treated as un-retryable.=20 Because that is what the "3 11 00" combination involved means. The drive is reporting that. It is not a FreeBSD driver choice of handling. (I'm not expert at drive internals, so I take it at face value.) > Are there any simple tests that might help decide what's wrong? > It's likely that re-running buildworld will reproduce the crash. See the https://en.wikipedia.org/wiki/Key_Code_Qualifier/ description material for some background information? > I've placed the results of smartctl -a at the end of the notes.=20 > The interpretation isn't self evident, hopefully someone else > can lend an eye. I'll try smartctl -t after a good night's sleep.=20 man smartctl reports: UNC: UNCorrectable Error in Data The 3 examples of: After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f Error: UNC at LBA =3D 0x0fffffff =3D 268435455 indicate UNC. All 3 list the same LBA value. Error 4 occurred at disk power-on lifetime: 11121 hours (463 days + 9 = hours) Error 3 occurred at disk power-on lifetime: 11098 hours (462 days + 10 = hours) Error 2 occurred at disk power-on lifetime: 11096 hours (462 days + 8 = hours) So spread over a little over a day overall, with 2 and 3 spread over a couple of hours. It suggests to me that the drive is no longer usable. But I'm no expert. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Feb 20 06:00:35 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 4PKsGz1z6nz3s0TV for ; Mon, 20 Feb 2023 06:00:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 4PKsGy2BV6z3s67 for ; Mon, 20 Feb 2023 06:00:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="i/Sw1V9w"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.204 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=1676872848; bh=RkUYQGCYQ3/WKYKoZWertAz3zs2XeCh86/lqcTzoiI0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=i/Sw1V9wfiQo2wLEwPdDWzXFuiDIhRUgC0JoTB+yKZIDvBpOiEL3LzlexIlq4eFiAuiPC3835wezozTVZ8mXGOHGXOdngkX43nHKNR6T0vhuS/sCbWaLRvn6trroTdy/lx8hqv0LHlCO/G60V7BuQAs21nR3Jo1a0bbJQOQ5wDsAgfagWt1sSBdxwZMTcABWly+HjMFJTaXN7pPkWzJKLAVBmX8JNKNL/pLAo9l4IY+gP4qJzLNIey/JmkBigxZ7OtTP3aIracVDumz1UesLFO52CU5E6Hi+J7A20fEmlLaIa6lq8HOoZ3yKp0rHsbIN3qDxm7TYbf1I5WBXanXfgw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676872848; bh=NNGrmcR5skb42cGDyYWPpCCiVugA11pRq4eBynFL6oj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OqHREA3T0k8kilvG0GRe7G9XRyvN/mGvt53bkPMN0//fx9YTqZ9dlvlokU1iCMMYjQhac0JfE3XffAWIDlQyjvsdz30XEDdXymmNWtOJQiMHJAqw0VODDDaeZ+vNOVIsbGW6H3guLcG53QRL40YVYpD0gUnQWNSM2Lvles8uUgeVvn9dLdDXYPhBFhWbvA45eKWCQdwk5EBLmr4XvfoAzd9t1F4Ge2c8MmkqEtfahjnxfZePvF9ZhG+dx8/kuJrRQacAYx1pzqCnBQC3YUXYFb90PXf3afClWwKSSQa4GMA5xGO8iqP+OZ3eqKLyqFBOj6z5jM0UO4lqtvF+ibyn9g== X-YMail-OSG: mAgF_fwVM1nZ.S9AdOBwCSU8gv1wFCpM0N5xQOeMLReIHVWTos7mRbA.AKqJusH fY5ounEtwVLet1n3AOw95gWgeDy0c3DTUEes7vYgUqHDC1Yrews6.2f9.YBJhmmOt3fFtN1x3gbW H.gWFuLZeZ4FEsHCqblBtTDzA7_qfrp50PlRGks0JwR454DlUaE57Luo6NA2luYwNk.iS9UqyM1k jEl1KGY2.PIBVEUiWFFTvnbCvSgoMtagS4QjteJHlTjYaCehJ3vT.Z59oErMIfjCkTKsbncUkaMk WftmkQFiQqCQGKYXLvNUlHDvkLRxrPPnZptttOMCaOzMPWqtEmI2z6n2ZDalYloNt5tWjez1eYQe _gmKMbSdm4wdkm6hOPwG6Sf97c9CkSUPvEsH7Y8RHiN52bU1ogEcxJJyw6R0YjYHdVKCHprTuwle OcVcuKYCE01yazBQoUvOdCE592vSahKUBtJ6Hd.1tTRL_ie6caG7pCcNFU8GKOcTXwwCrwaw0RPS h.6sJatnIvz1jMR6bzYlfxiffLQ0bqVlHeqgnPz7WcdwgZbAtViM31WdarBCWVSbIeLEYbh1S8f1 OhypbSbc.Xq4T7myU8G_mJidF.IyK5nwbbm2a91c5hwaEa4r6CqNMIEK6ywgBheCM8JnzfUvdc.8 eo4ykvQTzPGWjvN7CLmYzGeU_4j0qphpTi02xOsbgOYw4sv52UKBWproBZ__4g9oIUWwc05RrA_e 9F7SBn1uCAmR4gu416cVABX_POS3dxEly5JhgyJmL4d2t2W5PzLTG32dmEUWlDHj1o510pCfzr.m DBigiu1QX5iu0tBOy2IoF0b_iQCx975.AOchu_1WLIHPcR197wXvlqutb4xhDDTxXsB4dcgz5GMi hV.fFIr4IaZG4SgAx96NVpS44jPuz_FmGDUGxNyb4jzLoopQm59w8d_0abL.N.x35W3fWK1tj3jq mkHbuUGbdTsxXU3GY81U3A0y_7oCYPPGL085VThL.fYdI3BrM6tf6ESnhdWjqE3d0xm1_QAARhHj qVYaK4mlIEdAnXNIGefBGDhkZkOlKHia1iXRzd_VJJT3M.DKd9em_uoL8jcdHjjOw3AeZFueYekF w0Cb1ssVioRrx3UEzAaKdz49m2jPYsQNX87TYuA.tXGcxqj2GL5bb_VGIyfDm05LHqmcvH6xbA0x enBqxbbsmsv_XFQAF.e_S8esTAHaLB9csqqpY.i42zIl4dCdFRi7aoy4d7nnXxnygncENwRL7LkE DJ4BRJgipVQ7dTmC2Us4oHR5exLp_6RwktHhZQO2VmBQKltUMcq.l3FrRVcmSvog1ZH.zcPqm6j5 rVSJpk_sfyEUWM.wwN0SFFQ9hEpKkCkInCXExbg8PKUCQPV4TNGVZ3kapekXtHAkZJaAQE5pOIUL 4Mk5XWML27vZVWMQZeFlpujr6wkkwU7s5N4W6xEppZpWXMdjvjFZdfTMHUXjAEFMXj56sDSnmFnY edF4tVk0CUjIwfsTeHpBTL2mEEZ20xnAt6jV27.Uvq7mEWayuEVflweW4ENSjnBBm7WWAAByE8NC li4PgA22Cb3Y2vSZm4XdtEX7Rv8hpakJu5_CR_Cla0r5simz_pXKR0r0DDj7V4r2X2xHFXpMnese 0e681QqsBlaGzRuZgdgwcfLDzf4jf.SNtJ5hoUe51xZS5TB4ckD.3NVrjSy4DA8mBw2G0VJ3mKT. bpPWwwSDa._06gu29F8T1P6hRdmt1osnxWS9AduVlYPL36ZfXs01o02iCNOqtkE2AA8u86Sio0t0 ZF0sYxNQWl66FxXlpMGSSxa0eWQEk6cvl14f8ndP9RpA3ttIqt6ENggfuUnmTc3jxy6igep7MUvb njoqpJfGOwFC95DvrTP4OIa1UXltC..TZYCl712gRsj9fP02IYuhyrtbYmNOScTKA5.deTLX4EnT _7Xq0.zFtmUhzEor1vFQohMLqHFWMkvBAOLxxA2km9ALcXlAeD.meDWKEcVApMfY5cy6izY0bCmb iefHulSfnJURbxd63wAF6nv4BeekhBgmXxsZj_y0VV7Jd7VjLKshhGgP4GTw_C51uOiti8bqkDA9 ghgN3iVPZHZ_11MAKAnLXwQ5sY0ucb5Nskg6p7gI0EEbPA7k67jdEcuZi5VAjYHHBxtEu8DTg864 LqYYqVFxNTXkcEAgHbnUCB4US.nGgvPDpc_IBMP3ZZV5M9C0JQCD7ECcwuJ0nno6DbXTw.rHQbHY V94mWSr8hD7h0GkiWf2FrE2ic7obuJcPCMY2Uxxmps0kySMSCMPZ9xBQHzZ2Sg9uPD0cPpa1uSA- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 20 Feb 2023 06:00:48 +0000 Received: by hermes--production-ne1-746bc6c6c4-9t6ft (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ec98122237b7b129c887928e709eec3b; Mon, 20 Feb 2023 06:00:47 +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 \(3731.400.51.1.1\)) Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) From: Mark Millard In-Reply-To: <9CEF4E7A-2F13-454F-A04A-A6C5A80FD4B7@yahoo.com> Date: Sun, 19 Feb 2023 22:00:35 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <268392B4-58FE-49EE-9B1D-6DA632757DFA@yahoo.com> References: <202302192054.31JKsq7w079295@chez.mckusick.com> <3DD8EEC2-6135-42A0-A80C-F195CAAC025E@yahoo.com> <20230219222328.GA55941@www.zefox.net> <2F5B20E9-AFF8-42F6-9E1F-50BBDF4E1B79@yahoo.com> <20230220044544.GB57936@www.zefox.net> <9CEF4E7A-2F13-454F-A04A-A6C5A80FD4B7@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.70)[-0.696]; 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]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4PKsGy2BV6z3s67 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Feb 19, 2023, at 21:50, Mark Millard wrote: > On Feb 19, 2023, at 20:45, bob prohaska wrote: >=20 >> On Sun, Feb 19, 2023 at 02:35:15PM -0800, Mark Millard wrote: >>>=20 >>> Kirk likely monitors the freebsd-fs list. >>=20 >> I didn't notice there was such a list 8-\ >>=20 >>> Kirk likely does not monitor the freebsd-arm list. >>> None of us thought to switch to freebsd-fs at the >>> time. The only part of your context that ended up >>> to be arm specific was original buildworld crash. >>> You definitely started in an appropriate place >>> (freebsd-arm). After the crash, the rest was more >>> general relative to platforms and more specific >>> relative to file system handling (UFS support). >>>=20 >>> I do not see any reason for any of this exchange >>> to go to any lists, given the current status. >>=20 >> Alas, the story's not over yet 8-( =20 >>=20 >> After getting the disk fsck'd and booting once more, >> an attempt to buildworld using a fresh /usr/src >> and empty /usr/obj crashed again, >=20 > I'm confused. The original crash was reported to be > on a RPi2B using a armv7 kernel, or so I thought. > (The RPi3B was for later fsck_ffs activity for the > media's UFS.) >=20 > This new material indicates a RPi3B arm64 (aarch64) > context for this buildworld failure. Is it the same > media as for the prior buildworld failure? >=20 >> in I think the >> same way. This time some notes have been collected >> at >> http://www.zefox.net/~fbsd/rpi3/scsi_status_error/readme >>=20 >> To a casual glance, it looks like a hardware error. >> But, the machine seems to work fine until it's running >> buildworld, and then crashes during a relatively easy >> part of buildworld. The initial error message is: >>=20 >> bob@pelorus:/usr/src % (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 = 43 29 d6 40 00 00 40 00=20 >> (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error >> (da0:umass-sim0:0:0:0): SCSI status: Check Condition >> (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:11,0 = (Unrecovered read error) >> (da0:umass-sim0:0:0:0): Error 5, Unretryable error >=20 > A description of "Media Error" from seagate is: >=20 > Medium Error - Indicates the command terminated with a nonrecovered = error condition, probably caused by a flaw in the medium or an error in = the recorded data. >=20 > To compare/contrast with other alternatives, see: >=20 > https://www.seagate.com/support/kb/scsi-sense-key-chart-196259en/ >=20 > A more extensive list with asc/ascq involved as well is at: >=20 > https://en.wikipedia.org/wiki/Key_Code_Qualifier/ >=20 > Allowing more comparison/contrast with other classifications. >=20 > It indicates: >=20 > 3 11 00 Medium Error - unrecovered read error >=20 > (matching the reported text). >=20 >> SCSI errors are not unknown, but they usually succeed on retry. >> It's not obvious why this is treated as un-retryable.=20 >=20 > Because that is what the "3 11 00" combination involved > means. The drive is reporting that. It is not a FreeBSD > driver choice of handling. >=20 > (I'm not expert at drive internals, so I take it at face > value.) >=20 >> Are there any simple tests that might help decide what's wrong? >> It's likely that re-running buildworld will reproduce the crash. >=20 > See the https://en.wikipedia.org/wiki/Key_Code_Qualifier/ > description material for some background information? >=20 >> I've placed the results of smartctl -a at the end of the notes.=20 >> The interpretation isn't self evident, hopefully someone else >> can lend an eye. I'll try smartctl -t after a good night's sleep.=20 >=20 > man smartctl reports: >=20 > UNC: UNCorrectable Error in Data >=20 > The 3 examples of: >=20 > After command completion occurred, registers were: > ER ST SC SN CL CH DH > -- -- -- -- -- -- -- > 40 51 00 ff ff ff 0f Error: UNC at LBA =3D 0x0fffffff =3D 268435455 >=20 > indicate UNC. All 3 list the same LBA value. Turns out that the LBA value is likely garbage, given the size of your drive (> 128 GiBytes): Quoting the smartctl man page: (Because of the limitations of the SMART error log, if the LBA is greater than 0xfffffff, then = either no error log entry will be made, or the error log entry will = have an incorrect LBA. This may happen for drives with a = capacity greater than 128 GiB or 137 GB.) Also, the more expanded material about UNC is: UNC (UNCorrectable): data is uncorrectable. This refers = to data which has been read from the disk, but for which the Error Checking and Correction (ECC) codes are inconsistent. In effect, this means that the data can not be read. >=20 > Error 4 occurred at disk power-on lifetime: 11121 hours (463 days + 9 = hours) > Error 3 occurred at disk power-on lifetime: 11098 hours (462 days + 10 = hours) > Error 2 occurred at disk power-on lifetime: 11096 hours (462 days + 8 = hours) >=20 > So spread over a little over a day overall, with 2 and 3 > spread over a couple of hours. >=20 > It suggests to me that the drive is no longer usable. > But I'm no expert. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Feb 20 11:47:30 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 4PL0yz4jXHz3sgxN for ; Mon, 20 Feb 2023 11:47:39 +0000 (UTC) (envelope-from jfc@mit.edu) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.outgoing-exchange.mit.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PL0yz2xsqz3Ln8 for ; Mon, 20 Feb 2023 11:47:39 +0000 (UTC) (envelope-from jfc@mit.edu) Authentication-Results: mx1.freebsd.org; none Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 31KBlXKv024982; Mon, 20 Feb 2023 06:47:33 -0500 Received: from OC11EXPO29.exchange.mit.edu (18.9.4.102) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1497.47; Mon, 20 Feb 2023 06:47:27 -0500 Received: from oc11exhyb6.exchange.mit.edu (18.9.1.111) by oc11expo29.exchange.mit.edu (18.9.4.102) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Mon, 20 Feb 2023 06:47:32 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.169) by oc11exhyb6.exchange.mit.edu (18.9.1.111) with Microsoft SMTP Server (TLS) id 15.0.1497.47 via Frontend Transport; Mon, 20 Feb 2023 06:47:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L2HhsyYCuvI4wsAkQE1ZDIlEamQXTBpBTM2IoJdgSB/2vrfTe+zRrCIz+C5bpWxo5f01DUXfXIXYLAz0X3NRN9ePPwlOjcz0urtVektnCcq2eSmsOmSmMfr6CBI/iyRcbR7dVkh2UWV/GFKr8zpPoosXg/q/a+wHtD63dY+Gfkf3XGnl0mA0dgJ97IkUZKd3Nj1XQ1wZTAT0V7gVhzfWw2IcvIg+7eRVURoPPRrvv1vPa2SLz5tQU/YrXPEpWdG556Kb00OlQdO9SuKbQWNVxgQtjuf9u4/Bp4+pUOiA+FmK6RHuv7OQFXscPEh5+SymoTNgU2lHZ3YDHewQ/Zrz2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=P/mwpttbBiJ1j+ijRfj0lL3JkmPkfI17TaIfPepKjjg=; b=lGMUNs+ZSA67XLuSIBTTXlFs6pgMmp+m8+jc5uaDjGxTbl0FUcI859dVDGua0y9FZGZo69YruMPiIJ3tX1bKEtCvxzp8fkVccYmpWQqZ1K/wgVk3LXXS6beUcmx2I+AHLBtK0tQMc5R05tKnDyFh+eyvW7Wf1tC7QGK/SVZN0pqDBZPDcBX6f/9avth0XXoUJDYosMzfdGZXPttAa7VjL5CN63cfpto7YE6H0CL4x7tXICWzTpDLBEZM1zgCrxWy0rSjjXb6FTt9ugdMuUC6nUUllCM6T7EdTfXJCxibAj176qnA+RlJVXAuC8EBMplQQjjSfTpgy1YyEme6cFR3PQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mit.edu; dmarc=pass action=none header.from=mit.edu; dkim=pass header.d=mit.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P/mwpttbBiJ1j+ijRfj0lL3JkmPkfI17TaIfPepKjjg=; b=h6Ozq6NAK1smu3x5MuD6/EnEdGkm0nsgvOu3Q17hQokIaW+jpCWievmkuekG5qkiI4r9lf8VtKhZ0FKP9kzUy0sj3SxMAKGqCJ0NdYEpZV+y2wYiRQfVpiaUpCjMJh7qbIeKY8PQ0iTMTSvmA2uYDDK9h0c8rsU1j/rmQDoZii4= Received: from DS7PR01MB7712.prod.exchangelabs.com (2603:10b6:8:7b::17) by CY4PR01MB3270.prod.exchangelabs.com (2603:10b6:903:de::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.19; Mon, 20 Feb 2023 11:47:30 +0000 Received: from DS7PR01MB7712.prod.exchangelabs.com ([fe80::beb1:405b:1793:e719]) by DS7PR01MB7712.prod.exchangelabs.com ([fe80::beb1:405b:1793:e719%8]) with mapi id 15.20.6111.020; Mon, 20 Feb 2023 11:47:30 +0000 From: John F Carr To: Mark Millard , bob prohaska CC: "freebsd-arm@freebsd.org" Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Thread-Topic: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Thread-Index: AQHZROYpEDD0/PiPO0yNgT9ZhfjMLq7XVMCAgAACv4CAAGDhAA== Date: Mon, 20 Feb 2023 11:47:30 +0000 Message-ID: <1DB17CD4-63B5-4FA2-ADC6-6ED817A09CCB@mit.edu> References: <202302192054.31JKsq7w079295@chez.mckusick.com> <3DD8EEC2-6135-42A0-A80C-F195CAAC025E@yahoo.com> <20230219222328.GA55941@www.zefox.net> <2F5B20E9-AFF8-42F6-9E1F-50BBDF4E1B79@yahoo.com> <20230220044544.GB57936@www.zefox.net> <9CEF4E7A-2F13-454F-A04A-A6C5A80FD4B7@yahoo.com> <268392B4-58FE-49EE-9B1D-6DA632757DFA@yahoo.com> In-Reply-To: <268392B4-58FE-49EE-9B1D-6DA632757DFA@yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DS7PR01MB7712:EE_|CY4PR01MB3270:EE_ x-ms-office365-filtering-correlation-id: d31a4166-0a63-4efa-ec0b-08db13383f57 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZU8hbIIaE7FMWZ58OIkqSK1Ryesne+/wAScJhfjX28UnKhb/WOPAWfoXgF+h6VhwzM5puukmUlWWcjPWxOTUSBEucxhZaXvXY8eCGCTLvMn8Rv3RVpuevt1csIj622p33xWDr4Dfx5/E5icfEYWrIb0CmSYQDYvQr+Uk2gS/q1HDtgzd+g5N5qAEQx5qLQxe2jJHNOWFt/aF4yPkdb8nooZfuoIz4EvPKaAXM2x5w80UmAUzBLTfKirA9QCDztUVjPzAjJJJJ8w0H7Au7ARfGQ9uie0IzmwXahbJYV6+e4hhATY+Ntv6rwBSxkl8C4zzukZ89gqzBaE34pyzpF0rW1kfYFVT5X7/j5Oi3QI0SKJbt59Se6cC3+OoqfzGcCMGP6osMC4qWzX6QvjEKuYN6MrE/4y5h7areHiyfAJJnhHOhNIa92b8JfAAINkReCSxQLiSL1TslkvTGZQ8l+YZmfHasUAGq5RgmFUWPJAq2lcPt8gJdtDZLVSkJru/Nx5jjw/sS++1Cj5/dGsnc9g9bMqKqjht+P/UMKitow8swFFjHOwXq1QXM3cYaG41a+61KA4nnLSV0hBiCDu1RGQbkqv6ndoNMSrtU9ck//PR4NRQnefHUkWaNpIj4irGEcINUrl5TaBZD6P4QSPyasvKkhXOEsb1ztFx7EQRVV3fb5Xo9SclLbLKKMZyllRvr/yB x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR01MB7712.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230025)(4636009)(366004)(39860400002)(136003)(396003)(376002)(346002)(451199018)(86362001)(36756003)(33656002)(38070700005)(66476007)(66556008)(41300700001)(66446008)(64756008)(4326008)(66946007)(8676002)(76116006)(8936002)(5660300002)(91956017)(966005)(6486002)(316002)(786003)(110136005)(83380400001)(2906002)(122000001)(75432002)(38100700002)(26005)(53546011)(6512007)(186003)(6506007)(478600001)(71200400001)(2616005);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/pa1sWnVxQq476UFAbrp9a1Tee/JNa176vygLhfLweWzPFsaZBrKlTEZohud?= =?us-ascii?Q?VDMRo17xES2dM0mvPmcWx2I9BZ2uALnkg5DHUMCNsFtoLJZtqHVQyt64K+yl?= =?us-ascii?Q?jne58g/bWQiopRoN4v/7FSAY3gxaCm9ZZGSUYdmlxx9v5VUFKPaVWUlyIJ04?= =?us-ascii?Q?0XwVOE1jPgdMv2XWG3xSGSTqjwhGuieMgKOdMAbIIeEe2K8Y0qNgR6cbwM6V?= =?us-ascii?Q?c7s7g8emAW6EyFJYmaUP+9RqDhXO+TglvWnl0sj5JhcU8PE8rsqfhbWP9Yw5?= =?us-ascii?Q?1l0HPZIA1ixmz9r4b4ILHM8uT7WExa4v6X4R9QqncV5Bke/8GDGg59VvYiCX?= =?us-ascii?Q?GFenr9Tb8iS7ybSZjVhaz1dIzuDGwYkEGY7jCqv+9mxCmqxg/I/9BQwnDykl?= =?us-ascii?Q?4iOuTHEbROkBsXzdlrT/icG/pcoG/s2naNQefatbTLJiReqRCbGw3Bbs0PhA?= =?us-ascii?Q?NbUHiWUSl53/Z0YTsZqoFpCYJHAoqWT//tt57b8hRMg4S9PqmYJwHeSq9L11?= =?us-ascii?Q?z1eQ6WfipIIGK8Ps+p1CmIa977XRGG2vVb0H8pnieonYeQ69ASWBFIjer00F?= =?us-ascii?Q?IFWF4pyhAJxem1HlcodFP6T2/vluEFCxJc5vPqMdzM7nlRA38+f/tWBL8Fxe?= =?us-ascii?Q?gn11t6LGHJR2SKFdAa1LFr/PTvIdx0Fl4A6GWqSxmPJWRIGvCkn91l+XcTQe?= =?us-ascii?Q?s8vUJY3/ZlS/FbxdhykUFnkgytV9LrDsBpNQQcoaXKIhUoZ82R//j0j3hDC2?= =?us-ascii?Q?b8aepRuJiaNvrRm0aQfplCq9r59fGH1k30drf0goP3a+sAqL8hxSEHuBAQC3?= =?us-ascii?Q?lu4ANXIJ0TJGGO12of45tGq3nh0+0OuvIVMAE9C0QBHx6XO4M/gdXo9nPAOK?= =?us-ascii?Q?b5n6TsCR0eoAWYhG/xXFdaBTAb77b0pp7XD190umS0PFlyhyvAoeT+XcPqrE?= =?us-ascii?Q?PbxyJEbOc+9b/lSqzBxM0mc7zl7breBFu9AkWFAcB2BqeaO8dKU/bDO3MFhP?= =?us-ascii?Q?myBDnyNuypl78T0aVYHItrKORB/4vNQ5+nO6LyPW4XKd8mUQXNYfPxzqttk5?= =?us-ascii?Q?OuWxrAjoWmgffH8zryO+FKaRlNZJY4mgxe5bG9Iyo+8rfMavLDn1h5cXEOde?= =?us-ascii?Q?PtVMnMbGa+MjPP3sN3CuZR6gejugXu6UiD0cI/wfD9GbmKgWwOP9r0owHGa+?= =?us-ascii?Q?6vhR2zEipUf0zxW6JUObEojRvaED7AzXXLe/BkO2ZcFjxlOvbxt61nMoyKfJ?= =?us-ascii?Q?fVfxYZI0ogf/K2UHlnHnbfSfBBATqkHdXJX3uavGcnMAILfTeM+11TRO7H9a?= =?us-ascii?Q?KIWqLxrLWybWmg6DpjzID8ckSyWa+dZ9zuxSp9GvQujqXhWFZY1vEqJTXAtN?= =?us-ascii?Q?OftyCfM6A4x+PvgcnFeCMYbM0+XItTZzuFEArZAVlFWrssPj95dGRtKZnzO5?= =?us-ascii?Q?fjG2PCa707G8WtlzcuI93h6mKq0Dv/UmL+AA6Fo0wyhnbSMtL0y+ivzkMn2H?= =?us-ascii?Q?UOMW+Av7LIb5TdgRc7HFSP5XDmUU28/JI1dzaI1xeveryUgvwZraP9dmr0dH?= =?us-ascii?Q?FkdO7FCexU7zjFrxqmzfIRAIQ1m1BJk0pyJ6pMlT?= Content-Type: text/plain; charset="us-ascii" Content-ID: <3EC407DE5020E143864D7FB22EA1005B@prod.exchangelabs.com> 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 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DS7PR01MB7712.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: d31a4166-0a63-4efa-ec0b-08db13383f57 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2023 11:47:30.4567 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jLZmTqlGWOrc5y7xPjTEO/eF/OUEqTKpk63D7+qoN9dObZ7eI9of/5et9FkXfJW2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR01MB3270 X-OriginatorOrg: mit.edu X-Rspamd-Queue-Id: 4PL0yz2xsqz3Ln8 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On Feb 20, 2023, at 01:00, Mark Millard wrote: >=20 > On Feb 19, 2023, at 21:50, Mark Millard wrote: >=20 >> On Feb 19, 2023, at 20:45, bob prohaska wrote: >>=20 >>> On Sun, Feb 19, 2023 at 02:35:15PM -0800, Mark Millard wrote: >>>>=20 >>>> Kirk likely monitors the freebsd-fs list. >>>=20 >>> I didn't notice there was such a list 8-\ >>>=20 >>>> Kirk likely does not monitor the freebsd-arm list. >>>> None of us thought to switch to freebsd-fs at the >>>> time. The only part of your context that ended up >>>> to be arm specific was original buildworld crash. >>>> You definitely started in an appropriate place >>>> (freebsd-arm). After the crash, the rest was more >>>> general relative to platforms and more specific >>>> relative to file system handling (UFS support). >>>>=20 >>>> I do not see any reason for any of this exchange >>>> to go to any lists, given the current status. >>>=20 >>> Alas, the story's not over yet 8-( =20 >>>=20 >>> After getting the disk fsck'd and booting once more, >>> an attempt to buildworld using a fresh /usr/src >>> and empty /usr/obj crashed again, >>=20 >> I'm confused. The original crash was reported to be >> on a RPi2B using a armv7 kernel, or so I thought. >> (The RPi3B was for later fsck_ffs activity for the >> media's UFS.) >>=20 >> This new material indicates a RPi3B arm64 (aarch64) >> context for this buildworld failure. Is it the same >> media as for the prior buildworld failure? >>=20 >>> in I think the >>> same way. This time some notes have been collected >>> at >>> http://www.zefox.net/~fbsd/rpi3/scsi_status_error/readme >>>=20 >>> To a casual glance, it looks like a hardware error. >>> But, the machine seems to work fine until it's running >>> buildworld, and then crashes during a relatively easy >>> part of buildworld. The initial error message is: >>>=20 >>> bob@pelorus:/usr/src % (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 43 = 29 d6 40 00 00 40 00=20 >>> (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error >>> (da0:umass-sim0:0:0:0): SCSI status: Check Condition >>> (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered = read error) >>> (da0:umass-sim0:0:0:0): Error 5, Unretryable error >>=20 >> A description of "Media Error" from seagate is: >>=20 >> Medium Error - Indicates the command terminated with a nonrecovered erro= r condition, probably caused by a flaw in the medium or an error in the rec= orded data. >>=20 >> To compare/contrast with other alternatives, see: >>=20 >> https://www.seagate.com/support/kb/scsi-sense-key-chart-196259en/ >>=20 >> A more extensive list with asc/ascq involved as well is at: >>=20 >> https://en.wikipedia.org/wiki/Key_Code_Qualifier/ >>=20 >> Allowing more comparison/contrast with other classifications. >>=20 >> It indicates: >>=20 >> 3 11 00 Medium Error - unrecovered read error >>=20 >> (matching the reported text). >>=20 >>> SCSI errors are not unknown, but they usually succeed on retry. >>> It's not obvious why this is treated as un-retryable.=20 >>=20 >> Because that is what the "3 11 00" combination involved >> means. The drive is reporting that. It is not a FreeBSD >> driver choice of handling. >>=20 >> (I'm not expert at drive internals, so I take it at face >> value.) >>=20 >>> Are there any simple tests that might help decide what's wrong? >>> It's likely that re-running buildworld will reproduce the crash. >>=20 >> See the https://en.wikipedia.org/wiki/Key_Code_Qualifier/ >> description material for some background information? >>=20 >>> I've placed the results of smartctl -a at the end of the notes.=20 >>> The interpretation isn't self evident, hopefully someone else >>> can lend an eye. I'll try smartctl -t after a good night's sleep.=20 >>=20 >> man smartctl reports: >>=20 >> UNC: UNCorrectable Error in Data >>=20 >> The 3 examples of: >>=20 >> After command completion occurred, registers were: >> ER ST SC SN CL CH DH >> -- -- -- -- -- -- -- >> 40 51 00 ff ff ff 0f Error: UNC at LBA =3D 0x0fffffff =3D 268435455 >>=20 >> indicate UNC. All 3 list the same LBA value. >=20 > Turns out that the LBA value is likely garbage, given the > size of your drive (> 128 GiBytes): But we have an address from the SCSI command: READ(10). CDB: 28 00 43 29 d6= 40 00 00 40 00=20 Decoded that says read, starting block 0x4329d640, length 0x40 blocks. If = block size is 512 bytes that is about half a terabyte into the disk. This shell command should replicate the read: # dd if=3D/dev/da0 of=3D/dev/null bs=3D32768 count=3D1 skip=3D17606489 The device name (if=3D) comes from the error message "da0:umass-sim0:0:0:0"= . The block size (bs=3D) matches the read request in the failed SCSI comma= nd. The skip count is 0x4329d640 (disk block) / 64 (number of disk blocks = per dd block). If you reproduce the error with dd you can try a binary search over the 64 = block range until you find the block that failed. From nobody Mon Feb 20 12:32:42 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 4PL1zP5LgWz3skwb for ; Mon, 20 Feb 2023 12:33:05 +0000 (UTC) (envelope-from bT.qgau58od30=jhw5ihzmj7vm=vtuedscjfi@em790814.fubar.geek.nz) Received: from e2i580.smtp2go.com (e2i580.smtp2go.com [103.2.142.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PL1zN256Dz3hTg for ; Mon, 20 Feb 2023 12:33:04 +0000 (UTC) (envelope-from bT.qgau58od30=jhw5ihzmj7vm=vtuedscjfi@em790814.fubar.geek.nz) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=smtpservice.net header.s=mgy720.a1-4.dyn header.b="g/sZpdqC"; dkim=pass header.d=fubar.geek.nz header.s=s790814 header.b=Bd5oLRcQ; spf=pass (mx1.freebsd.org: domain of "bT.qgau58od30=jhw5ihzmj7vm=vtuedscjfi@em790814.fubar.geek.nz" designates 103.2.142.68 as permitted sender) smtp.mailfrom="bT.qgau58od30=jhw5ihzmj7vm=vtuedscjfi@em790814.fubar.geek.nz"; dmarc=pass (policy=none) header.from=fubar.geek.nz DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=mgy720.a1-4.dyn; x=1676897283; h=Feedback-ID: X-Smtpcorp-Track:To:Date:Subject:Message-Id:From:Reply-To:Sender: List-Unsubscribe; bh=Sv9TNIdFtL//RROt9IUC/3XP7seFrHDLqIGxgg/j7uo=; b=g/sZpdqC PhaHMr62NtP+h/g0jrmHKhRqDh10OQcO6770YJkX5xHCso26AS4UAQQsUK7eHspQMUwaKp892rL0o fnIMZ07ifApotGrc7tO6j4QeqLOiIAkej/3jqstfXLko7zgmkNH04yqNR2r9swFXY2drRYprv+8zn IQJF/tAgDFnaPo7WXvEwVUdmTmD9Uryklth6LTYZTzZrtCcr0x+IAKIj08m4H3O2NhSHnMa70XxuS 0LKiXq8f+5JSkVoNvTWqvUsor1gDidKKmdvaURF8JYNTiyPsks7ShKVYBDkSvRPTJekwn8fSTh9bT eY58wQAFsxgf3lmQ8o7eJYWI2w==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1676896383; h=from : subject : to : message-id : date; bh=Sv9TNIdFtL//RROt9IUC/3XP7seFrHDLqIGxgg/j7uo=; b=Bd5oLRcQANCsEkm7S5+ooGh11Fg2q6vy+yw1Vymha0o7N/jePeFtjarrePrQqwJXbxkL+ tTo1Eb2KL9+Y8sQXm02ZcsiLcCg/seYvTTIHS/jMLl9lzFoOj+pFy4pO6bt5PtFH5VtMxxV VcI2AZdwTuHmrHUebTGGXJ1ydxa9Cq/5Sz5Or4LPDDKeK7pk6vWNzSo1w9svaOnbpLkbEEz RTuiTPYDrIrObNKgkyBH+mmL/91lB/3merg2jgs46B2zsb/Ryf360QaRHdkpk9rMLbPePOL Zj5fMiOn9tjQ5CQrQlTbJ/PAwlUDkg+EOzZHF9nWgBDOJWOMGYTlj7joKkUw== Received: from [10.176.58.103] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2-S2G) (envelope-from ) id 1pU5Lo-qt4KYR-31; Mon, 20 Feb 2023 12:33:00 +0000 Received: from [10.162.55.164] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96-S2G) (envelope-from ) id 1pU5Ln-9EGhf6-2a; Mon, 20 Feb 2023 12:32:59 +0000 Received: from smtpclient.apple (cpc91210-cmbg18-2-0-cust37.5-4.cable.virginm.net [81.102.44.38]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id 19AB41D4FC; Mon, 20 Feb 2023 12:32:55 +0000 (UTC) From: Andrew Turner Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8B4575DD-EC51-4B1A-8535-DCF534833113" 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 \(3731.400.51.1.1\)) Subject: Re: Armv7 panic on -current, rpi2 buildworld Date: Mon, 20 Feb 2023 12:32:42 +0000 In-Reply-To: Cc: bob prohaska , "freebsd-arm@freebsd.org" To: Mark Millard References: <20230215025741.GA32086@www.zefox.net> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Smtpcorp-Track: 1pl5Ln9EGhf62a.87h6B3__IFjKM Feedback-ID: 790814m:790814amQcrys:790814seVw_yQjFp X-Report-Abuse: Please forward a copy of this message, including all headers, to X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; FORGED_SENDER(0.30)[andrew@fubar.geek.nz,bT.qgau58od30=jhw5ihzmj7vm=vtuedscjfi@em790814.fubar.geek.nz]; RCVD_IN_DNSWL_MED(-0.20)[103.2.142.68:from]; R_SPF_ALLOW(-0.20)[+ip4:103.2.140.0/22]; R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=s790814]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_PERMFAIL(0.00)[smtpservice.net:s=mgy720.a1-4.dyn]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_MIXED(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_NEQ_ENVFROM(0.00)[andrew@fubar.geek.nz,bT.qgau58od30=jhw5ihzmj7vm=vtuedscjfi@em790814.fubar.geek.nz]; RCVD_COUNT_THREE(0.00)[4]; FREEMAIL_TO(0.00)[yahoo.com]; DKIM_TRACE(0.00)[smtpservice.net:~,fubar.geek.nz:+]; ASN(0.00)[asn:23352, ipnet:103.2.140.0/22, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[103.2.142.68:from]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4PL1zN256Dz3hTg X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_8B4575DD-EC51-4B1A-8535-DCF534833113 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There were = conditional branch instructions that may mean the function to save the = VFP state was not being run. Andrew > On 16 Feb 2023, at 19:35, Mark Millard wrote: >=20 > On Feb 14, 2023, at 23:16, Mark Millard > wrote: >=20 >> On Feb 14, 2023, at 20:16, Warner Losh wrote: >>=20 >>> Sorry to top post... what program was dumping core? Looks like a too = strict assert >>=20 >> Just a possible point, given recent kernel floating >> point work: >>=20 >> Because of Bob's note, I tried to do a typical build >> and test of some benchmark programs that I sometimes >> use that involve floating point in some of the >> programs, some use with multithreading involved. (As >> FreeBSD and g++ progress I tend to do this once and >> a while, not as often on armv7 as on aarch64.) >>=20 >> On armv7, I now get a message about a failure of an >> internal cross-check, which also leads to the program >> being stopped early. The messaging from run to run >> varies what the failure is, but the runs should not >> vary and should not fail the cross-checks --and >> previously did not, including when I last tried armv7. >> (Not recently.) >>=20 >> For the specific example failure, the initial serial >> (single thread) test with float involved works but the >> following multi-thread test in the same program fails >> and causes the program to stop when it notices there >> is a problem. >>=20 >> The programs that do not test floating point do not >> fail. These can involve floating point outside the >> algorithm benchmarked, but with no multi-threading >> involved for such and no floating point based cross- >> checks involved. >>=20 >> At this point it is far from obvious to me how I >> would trackdown the specifics of what leads to the >> failed cross-checks. But the above is suggestive of >> there being problems for armv7 handling of saving >> and restoring floating point context for >> multi-threading. I've no clue if such are limited >> to the floating point values or not. >>=20 >>> Warner >>>=20 >>> On Tue, Feb 14, 2023, 7:57 PM bob prohaska = wrote: >>> Building world on an RPi2 armv7, buildworld stopped with >>> bob@www:/usr/src % panic: Called fill_fpregs while the kernel is = using the VFP >>> cpuid =3D 0 >>> time =3D 1676427410 >>> KDB: stack backtrace: >>> db_trace_self() at db_trace_self >>> pc =3D 0xc05e8160 lr =3D 0xc007aa04 = (db_trace_self_wrapper+0x30) >>> sp =3D 0xde2c5790 fp =3D 0xde2c58a8 >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>> pc =3D 0xc007aa04 lr =3D 0xc02e9c54 (vpanic+0x140) >>> sp =3D 0xde2c58b0 fp =3D 0xde2c58d0 >>> r4 =3D 0x00000100 r5 =3D 0x00000000 >>> r6 =3D 0xc07372ef r7 =3D 0xc0b13968 >>> vpanic() at vpanic+0x140 >>> pc =3D 0xc02e9c54 lr =3D 0xc02e9a34 (dump_savectx) >>> sp =3D 0xde2c58d8 fp =3D 0xde2c58dc >>> r4 =3D 0xd70c8600 r5 =3D 0xde2c5e90 >>> r6 =3D 0xc3398090 r7 =3D 0xe0cfc440 >>> r8 =3D 0xc3398080 r9 =3D 0xd70c8600 >>> r10 =3D 0xde2c5960 >>> dump_savectx() at dump_savectx >>> pc =3D 0xc02e9a34 lr =3D 0xc05f51dc (set_regs) >>> sp =3D 0xde2c58e4 fp =3D 0xde2c58f8 >>> set_regs() at set_regs >>> pc =3D 0xc05f51dc lr =3D 0xc026f8f0 = (elf32_get_fpregset+0x2c) >>> sp =3D 0xde2c5900 fp =3D 0xde2c5908 >>> r4 =3D 0xc3398090 r5 =3D 0xc026f8c4 >>> elf32_get_fpregset() at elf32_get_fpregset+0x2c >>> pc =3D 0xc026f8f0 lr =3D 0xc026d848 (elf32_coredump+0x308) >>> sp =3D 0xde2c5910 fp =3D 0xde2c5988 >>> r4 =3D 0xc0902a7c r10 =3D 0xde2c5960 >>> elf32_coredump() at elf32_coredump+0x308 >>> pc =3D 0xc026d848 lr =3D 0xc02eea74 (sigexit+0xce0) >>> sp =3D 0xde2c5990 fp =3D 0xde2c5cf8 >>> r4 =3D 0x0000004e r5 =3D 0xdf580b60 >>> r6 =3D 0xdf580a78 r7 =3D 0xc026d540 >>> r8 =3D 0xdddcb2bc r9 =3D 0xdf580ad4 >>> r10 =3D 0x00000000 >>> sigexit() at sigexit+0xce0 >>> pc =3D 0xc02eea74 lr =3D 0xc02ef36c (postsig+0x128) >>> sp =3D 0xde2c5d00 fp =3D 0xde2c5d88 >>> r4 =3D 0x00000006 r5 =3D 0xdd43fba0 >>> r6 =3D 0xde2c5d20 r7 =3D 0xde2c5d18 >>> r8 =3D 0xdddcb1f8 r9 =3D 0xdf3d9ab8 >>> r10 =3D 0x00000005 >>> postsig() at postsig+0x128 >>> pc =3D 0xc02ef36c lr =3D 0xc02f316c (ast_sig+0x11c) >>> sp =3D 0xde2c5d90 fp =3D 0xde2c5e08 >>> r4 =3D 0xdd43fba0 r5 =3D 0xdddcb2bc >>> r6 =3D 0xc0734d22 r7 =3D 0x00000000 >>> r8 =3D 0xdddcb1f8 r9 =3D 0x00000ab8 >>> r10 =3D 0x22530384 >>> ast_sig() at ast_sig+0x11c >>> pc =3D 0xc02f316c lr =3D 0xc035444c (ast_handler+0xe0) >>> sp =3D 0xde2c5e10 fp =3D 0xde2c5e28 >>> r4 =3D 0xde2c5e40 r5 =3D 0x0000000e >>> r6 =3D 0x00004000 r7 =3D 0xc096b59c >>> r8 =3D 0xdd43fba0 r9 =3D 0x00000001 >>> ast_handler() at ast_handler+0xe0 >>> pc =3D 0xc035444c lr =3D 0xc035435c (ast+0x20) >>> sp =3D 0xde2c5e30 fp =3D 0xde2c5e38 >>> r4 =3D 0xde2c5e40 r5 =3D 0xdd43fba0 >>> r6 =3D 0x00000000 r7 =3D 0x000001b1 >>> r8 =3D 0x22c4b500 r9 =3D 0x00000000 >>> ast() at ast+0x20 >>> pc =3D 0xc035435c lr =3D 0xc05eaa88 (swi_exit+0x3c) >>> sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 >>> r4 =3D 0x60000013 r5 =3D 0xdd43fba0 >>> swi_exit() at swi_exit+0x3c >>> pc =3D 0xc05eaa88 lr =3D 0xc05eaa88 (swi_exit+0x3c) >>> sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 >>> KDB: enter: panic >>> [ thread pid 81621 tid 101111 ] >>> Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! >>> db> bt >>> Tracing pid 81621 tid 101111 td 0xdd43fba0 >>> db_trace_self() at db_trace_self >>> pc =3D 0xc05e8160 lr =3D 0xc00774a0 (db_stack_trace+0x140) >>> sp =3D 0xde2c55d8 fp =3D 0xde2c55f0 >>> db_stack_trace() at db_stack_trace+0x140 >>> pc =3D 0xc00774a0 lr =3D 0xc00770f0 (db_command+0x310) >>> sp =3D 0xde2c55f8 fp =3D 0xde2c56a0 >>> r4 =3D 0xc0745722 r5 =3D 0x00000062 >>> r6 =3D 0x00000000 r10 =3D 0x00000000 >>> db_command() at db_command+0x310 >>> pc =3D 0xc00770f0 lr =3D 0xc0076db8 (db_command_loop+0x64) >>> sp =3D 0xde2c56a8 fp =3D 0xde2c56b8 >>> r4 =3D 0xc07ac186 r5 =3D 0xc07ab7fe >>> r6 =3D 0xc0986f5c r7 =3D 0xc0b13968 >>> r8 =3D 0xc0b23738 r9 =3D 0x00000000 >>> r10 =3D 0x00000001 >>> db_command_loop() at db_command_loop+0x64 >>> pc =3D 0xc0076db8 lr =3D 0xc007ab88 (db_trap+0x128) >>> sp =3D 0xde2c56c0 fp =3D 0xde2c57d8 >>> r4 =3D 0x00000000 r5 =3D 0xc0986f50 >>> r6 =3D 0xc0b23758 r10 =3D 0x00000001 >>> db_trap() at db_trap+0x128 >>> pc =3D 0xc007ab88 lr =3D 0xc033bb84 (kdb_trap+0x258) >>> sp =3D 0xde2c57e0 fp =3D 0xde2c5808 >>> r4 =3D 0xc078390c r5 =3D 0xc08d5270 >>> r6 =3D 0xc0b23758 r7 =3D 0xc0b13968 >>> kdb_trap() at kdb_trap+0x258 >>> pc =3D 0xc033bb84 lr =3D 0xc05eaab8 (exception_exit) >>> sp =3D 0xde2c5810 fp =3D 0xde2c58a8 >>> r4 =3D 0x200000d3 r5 =3D 0x00000000 >>> r6 =3D 0xc07372ef r7 =3D 0xc0b13968 >>> r8 =3D 0xc093fa0c r9 =3D 0xde2c58e4 >>> r10 =3D 0xc0b13a68 >>> exception_exit() at exception_exit >>> pc =3D 0xc05eaab8 lr =3D 0xc033b044 (kdb_enter+0x50) >>> sp =3D 0xde2c58a0 fp =3D 0xde2c58a8 >>> r0 =3D 0x00000000 r1 =3D 0x00000001 >>> r2 =3D 0x00000012 r3 =3D 0x00000000 >>> r4 =3D 0xc0b23748 r5 =3D 0x00000000 >>> r6 =3D 0xc07372ef r7 =3D 0xc0b13968 >>> r8 =3D 0xc093fa0c r9 =3D 0xde2c58e4 >>> r10 =3D 0xc0b13a68 r12 =3D 0x00000000 >>> kdb_enter() at kdb_enter+0x58 >>> pc =3D 0xc033b04c lr =3D 0xc02e9ca0 (vpanic+0x18c) >>> sp =3D 0xde2c58b0 fp =3D 0xde2c58d0 >>> r4 =3D 0x00000100 r10 =3D 0xc0b13a68 >>> vpanic() at vpanic+0x18c >>> pc =3D 0xc02e9ca0 lr =3D 0xc02e9a34 (dump_savectx) >>> sp =3D 0xde2c58d8 fp =3D 0xde2c58dc >>> r4 =3D 0xd70c8600 r5 =3D 0xde2c5e90 >>> r6 =3D 0xc3398090 r7 =3D 0xe0cfc440 >>> r8 =3D 0xc3398080 r9 =3D 0xd70c8600 >>> r10 =3D 0xde2c5960 >>> dump_savectx() at dump_savectx >>> pc =3D 0xc02e9a34 lr =3D 0xc05f51dc (set_regs) >>> sp =3D 0xde2c58e4 fp =3D 0xde2c58f8 >>> set_regs() at set_regs >>> pc =3D 0xc05f51dc lr =3D 0xc026f8f0 = (elf32_get_fpregset+0x2c) >>> sp =3D 0xde2c5900 fp =3D 0xde2c5908 >>> r4 =3D 0xc3398090 r5 =3D 0xc026f8c4 >>> elf32_get_fpregset() at elf32_get_fpregset+0x2c >>> pc =3D 0xc026f8f0 lr =3D 0xc026d848 (elf32_coredump+0x308) >>> sp =3D 0xde2c5910 fp =3D 0xde2c5988 >>> r4 =3D 0xc0902a7c r10 =3D 0xde2c5960 >>> elf32_coredump() at elf32_coredump+0x308 >>> pc =3D 0xc026d848 lr =3D 0xc02eea74 (sigexit+0xce0) >>> sp =3D 0xde2c5990 fp =3D 0xde2c5cf8 >>> r4 =3D 0x0000004e r5 =3D 0xdf580b60 >>> r6 =3D 0xdf580a78 r7 =3D 0xc026d540 >>> r8 =3D 0xdddcb2bc r9 =3D 0xdf580ad4 >>> r10 =3D 0x00000000 >>> sigexit() at sigexit+0xce0 >>> pc =3D 0xc02eea74 lr =3D 0xc02ef36c (postsig+0x128) >>> sp =3D 0xde2c5d00 fp =3D 0xde2c5d88 >>> r4 =3D 0x00000006 r5 =3D 0xdd43fba0 >>> r6 =3D 0xde2c5d20 r7 =3D 0xde2c5d18 >>> r8 =3D 0xdddcb1f8 r9 =3D 0xdf3d9ab8 >>> r10 =3D 0x00000005 >>> postsig() at postsig+0x128 >>> pc =3D 0xc02ef36c lr =3D 0xc02f316c (ast_sig+0x11c) >>> sp =3D 0xde2c5d90 fp =3D 0xde2c5e08 >>> r4 =3D 0xdd43fba0 r5 =3D 0xdddcb2bc >>> r6 =3D 0xc0734d22 r7 =3D 0x00000000 >>> r8 =3D 0xdddcb1f8 r9 =3D 0x00000ab8 >>> r10 =3D 0x22530384 >>> ast_sig() at ast_sig+0x11c >>> pc =3D 0xc02f316c lr =3D 0xc035444c (ast_handler+0xe0) >>> sp =3D 0xde2c5e10 fp =3D 0xde2c5e28 >>> r4 =3D 0xde2c5e40 r5 =3D 0x0000000e >>> r6 =3D 0x00004000 r7 =3D 0xc096b59c >>> r8 =3D 0xdd43fba0 r9 =3D 0x00000001 >>> ast_handler() at ast_handler+0xe0 >>> pc =3D 0xc035444c lr =3D 0xc035435c (ast+0x20) >>> sp =3D 0xde2c5e30 fp =3D 0xde2c5e38 >>> r4 =3D 0xde2c5e40 r5 =3D 0xdd43fba0 >>> r6 =3D 0x00000000 r7 =3D 0x000001b1 >>> r8 =3D 0x22c4b500 r9 =3D 0x00000000 >>> ast() at ast+0x20 >>> pc =3D 0xc035435c lr =3D 0xc05eaa88 (swi_exit+0x3c) >>> sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 >>> r4 =3D 0x60000013 r5 =3D 0xdd43fba0 >>> swi_exit() at swi_exit+0x3c >>> pc =3D 0xc05eaa88 lr =3D 0xc05eaa88 (swi_exit+0x3c) >>> sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 >>> db>=20 >>>=20 >>> The machine was last updated about a week ago, the >>> sources were updated earlier today. This panic is >>> new to me. >>=20 >=20 > I now have a small C++ program that, when aborted > by SIGABRT on armv7 (say via control-\), gets the > above type of FreeBSD crash while trying to produce > the *.core file (debug style armv7 kernel in use). >=20 > I've sent the authors of the recent > VFP-use-in-armv7-kernel changes the details, also: > Warner L. . >=20 > I previously sent them a small C program that gets a > KASSERT based panic for a debug armv7 kernel when > run under gdb or lldb with a breakpoint at a > specific routine. >=20 > In general, looks like armv7 floating point use is now > problematical on main's [so: 14's] armv7 kernel until > more work is done. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com --Apple-Mail=_8B4575DD-EC51-4B1A-8535-DCF534833113 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Can you try = with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There were = conditional branch instructions that may mean the function to save the = VFP state was not being = run.

Andrew

On 16 Feb 2023, at 19:35, Mark Millard = <marklmi@yahoo.com> wrote:

On Feb 14, 2023, at 23:16, Mark Millard = <marklmi@yahoo.com> wrote:

On Feb 14, 2023, = at 20:16, Warner Losh <imp@bsdimp.com> wrote:

Sorry to top post... what program was dumping core? Looks = like a too strict assert

Just a possible point, = given recent kernel floating
point work:

Because of Bob's = note, I tried to do a typical build
and test of some benchmark = programs that I sometimes
use that involve floating point in some of = the
programs, some use with multithreading involved. (As
FreeBSD = and g++ progress I tend to do this once and
a while, not as often on = armv7 as on aarch64.)

On armv7, I now get a message about a = failure of an
internal cross-check, which also leads to the = program
being stopped early. The messaging from run to run
varies = what the failure is, but the runs should not
vary and should not fail = the cross-checks --and
previously did not, including when I last = tried armv7.
(Not recently.)

For the specific example failure, = the initial serial
(single thread) test with float involved works but = the
following multi-thread test in the same program fails
and = causes the program to stop when it notices there
is a = problem.

The programs that do not test floating point do = not
fail. These can involve floating point outside the
algorithm = benchmarked, but with no multi-threading
involved for such and no = floating point based cross-
checks involved.

At this point it = is far from obvious to me how I
would trackdown the specifics of what = leads to the
failed cross-checks. But the above is suggestive = of
there being problems for armv7 handling of saving
and restoring = floating point context for
multi-threading. I've no clue if such are = limited
to the floating point values or not.

Warner

On Tue, Feb 14, 2023, 7:57 PM bob prohaska = <fbsd@www.zefox.net> wrote:
Building world on an RPi2 armv7, = buildworld stopped with
bob@www:/usr/src % panic: Called fill_fpregs = while the kernel is using the VFP
cpuid =3D 0
time =3D = 1676427410
KDB: stack backtrace:
db_trace_self() at = db_trace_self
       pc =3D = 0xc05e8160  lr =3D 0xc007aa04 = (db_trace_self_wrapper+0x30)
       = sp =3D 0xde2c5790  fp =3D 0xde2c58a8
db_trace_self_wrapper() at = db_trace_self_wrapper+0x30
       pc= =3D 0xc007aa04  lr =3D 0xc02e9c54 = (vpanic+0x140)
       sp =3D = 0xde2c58b0  fp =3D = 0xde2c58d0
       r4 =3D = 0x00000100  r5 =3D = 0x00000000
       r6 =3D = 0xc07372ef  r7 =3D 0xc0b13968
vpanic() at = vpanic+0x140
       pc =3D = 0xc02e9c54  lr =3D 0xc02e9a34 = (dump_savectx)
       sp =3D = 0xde2c58d8  fp =3D = 0xde2c58dc
       r4 =3D = 0xd70c8600  r5 =3D = 0xde2c5e90
       r6 =3D = 0xc3398090  r7 =3D = 0xe0cfc440
       r8 =3D = 0xc3398080  r9 =3D = 0xd70c8600
      r10 =3D = 0xde2c5960
dump_savectx() at = dump_savectx
       pc =3D = 0xc02e9a34  lr =3D 0xc05f51dc = (set_regs)
       sp =3D = 0xde2c58e4  fp =3D 0xde2c58f8
set_regs() at = set_regs
       pc =3D 0xc05f51dc =  lr =3D 0xc026f8f0 = (elf32_get_fpregset+0x2c)
       sp = =3D 0xde2c5900  fp =3D = 0xde2c5908
       r4 =3D = 0xc3398090  r5 =3D 0xc026f8c4
elf32_get_fpregset() at = elf32_get_fpregset+0x2c
       pc = =3D 0xc026f8f0  lr =3D 0xc026d848 = (elf32_coredump+0x308)
       sp =3D= 0xde2c5910  fp =3D = 0xde2c5988
       r4 =3D = 0xc0902a7c r10 =3D 0xde2c5960
elf32_coredump() at = elf32_coredump+0x308
       pc =3D = 0xc026d848  lr =3D 0xc02eea74 = (sigexit+0xce0)
       sp =3D = 0xde2c5990  fp =3D = 0xde2c5cf8
       r4 =3D = 0x0000004e  r5 =3D = 0xdf580b60
       r6 =3D = 0xdf580a78  r7 =3D = 0xc026d540
       r8 =3D = 0xdddcb2bc  r9 =3D = 0xdf580ad4
      r10 =3D = 0x00000000
sigexit() at = sigexit+0xce0
       pc =3D = 0xc02eea74  lr =3D 0xc02ef36c = (postsig+0x128)
       sp =3D = 0xde2c5d00  fp =3D = 0xde2c5d88
       r4 =3D = 0x00000006  r5 =3D = 0xdd43fba0
       r6 =3D = 0xde2c5d20  r7 =3D = 0xde2c5d18
       r8 =3D = 0xdddcb1f8  r9 =3D = 0xdf3d9ab8
      r10 =3D = 0x00000005
postsig() at = postsig+0x128
       pc =3D = 0xc02ef36c  lr =3D 0xc02f316c = (ast_sig+0x11c)
       sp =3D = 0xde2c5d90  fp =3D = 0xde2c5e08
       r4 =3D = 0xdd43fba0  r5 =3D = 0xdddcb2bc
       r6 =3D = 0xc0734d22  r7 =3D = 0x00000000
       r8 =3D = 0xdddcb1f8  r9 =3D = 0x00000ab8
      r10 =3D = 0x22530384
ast_sig() at = ast_sig+0x11c
       pc =3D = 0xc02f316c  lr =3D 0xc035444c = (ast_handler+0xe0)
       sp =3D = 0xde2c5e10  fp =3D = 0xde2c5e28
       r4 =3D = 0xde2c5e40  r5 =3D = 0x0000000e
       r6 =3D = 0x00004000  r7 =3D = 0xc096b59c
       r8 =3D = 0xdd43fba0  r9 =3D 0x00000001
ast_handler() at = ast_handler+0xe0
       pc =3D = 0xc035444c  lr =3D 0xc035435c = (ast+0x20)
       sp =3D = 0xde2c5e30  fp =3D = 0xde2c5e38
       r4 =3D = 0xde2c5e40  r5 =3D = 0xdd43fba0
       r6 =3D = 0x00000000  r7 =3D = 0x000001b1
       r8 =3D = 0x22c4b500  r9 =3D 0x00000000
ast() at = ast+0x20
       pc =3D 0xc035435c =  lr =3D 0xc05eaa88 = (swi_exit+0x3c)
       sp =3D = 0xde2c5e40  fp =3D = 0xbb9fbe38
       r4 =3D = 0x60000013  r5 =3D 0xdd43fba0
swi_exit() at = swi_exit+0x3c
       pc =3D = 0xc05eaa88  lr =3D 0xc05eaa88 = (swi_exit+0x3c)
       sp =3D = 0xde2c5e40  fp =3D 0xbb9fbe38
KDB: enter: panic
[ thread pid = 81621 tid 101111 ]
Stopped at =      kdb_enter+0x54: ldrb =    r15, [r15, r15, ror r15]!
db> bt
Tracing pid = 81621 tid 101111 td 0xdd43fba0
db_trace_self() at = db_trace_self
       pc =3D = 0xc05e8160  lr =3D 0xc00774a0 = (db_stack_trace+0x140)
       sp =3D= 0xde2c55d8  fp =3D 0xde2c55f0
db_stack_trace() at = db_stack_trace+0x140
       pc =3D = 0xc00774a0  lr =3D 0xc00770f0 = (db_command+0x310)
       sp =3D = 0xde2c55f8  fp =3D = 0xde2c56a0
       r4 =3D = 0xc0745722  r5 =3D = 0x00000062
       r6 =3D = 0x00000000 r10 =3D 0x00000000
db_command() at = db_command+0x310
       pc =3D = 0xc00770f0  lr =3D 0xc0076db8 = (db_command_loop+0x64)
       sp =3D= 0xde2c56a8  fp =3D = 0xde2c56b8
       r4 =3D = 0xc07ac186  r5 =3D = 0xc07ab7fe
       r6 =3D = 0xc0986f5c  r7 =3D = 0xc0b13968
       r8 =3D = 0xc0b23738  r9 =3D = 0x00000000
      r10 =3D = 0x00000001
db_command_loop() at = db_command_loop+0x64
       pc =3D = 0xc0076db8  lr =3D 0xc007ab88 = (db_trap+0x128)
       sp =3D = 0xde2c56c0  fp =3D = 0xde2c57d8
       r4 =3D = 0x00000000  r5 =3D = 0xc0986f50
       r6 =3D = 0xc0b23758 r10 =3D 0x00000001
db_trap() at = db_trap+0x128
       pc =3D = 0xc007ab88  lr =3D 0xc033bb84 = (kdb_trap+0x258)
       sp =3D = 0xde2c57e0  fp =3D = 0xde2c5808
       r4 =3D = 0xc078390c  r5 =3D = 0xc08d5270
       r6 =3D = 0xc0b23758  r7 =3D 0xc0b13968
kdb_trap() at = kdb_trap+0x258
       pc =3D = 0xc033bb84  lr =3D 0xc05eaab8 = (exception_exit)
       sp =3D = 0xde2c5810  fp =3D = 0xde2c58a8
       r4 =3D = 0x200000d3  r5 =3D = 0x00000000
       r6 =3D = 0xc07372ef  r7 =3D = 0xc0b13968
       r8 =3D = 0xc093fa0c  r9 =3D = 0xde2c58e4
      r10 =3D = 0xc0b13a68
exception_exit() at = exception_exit
       pc =3D = 0xc05eaab8  lr =3D 0xc033b044 = (kdb_enter+0x50)
       sp =3D = 0xde2c58a0  fp =3D = 0xde2c58a8
       r0 =3D = 0x00000000  r1 =3D = 0x00000001
       r2 =3D = 0x00000012  r3 =3D = 0x00000000
       r4 =3D = 0xc0b23748  r5 =3D = 0x00000000
       r6 =3D = 0xc07372ef  r7 =3D = 0xc0b13968
       r8 =3D = 0xc093fa0c  r9 =3D = 0xde2c58e4
      r10 =3D 0xc0b13a68 r12 = =3D 0x00000000
kdb_enter() at = kdb_enter+0x58
       pc =3D = 0xc033b04c  lr =3D 0xc02e9ca0 = (vpanic+0x18c)
       sp =3D = 0xde2c58b0  fp =3D = 0xde2c58d0
       r4 =3D = 0x00000100 r10 =3D 0xc0b13a68
vpanic() at = vpanic+0x18c
       pc =3D = 0xc02e9ca0  lr =3D 0xc02e9a34 = (dump_savectx)
       sp =3D = 0xde2c58d8  fp =3D = 0xde2c58dc
       r4 =3D = 0xd70c8600  r5 =3D = 0xde2c5e90
       r6 =3D = 0xc3398090  r7 =3D = 0xe0cfc440
       r8 =3D = 0xc3398080  r9 =3D = 0xd70c8600
      r10 =3D = 0xde2c5960
dump_savectx() at = dump_savectx
       pc =3D = 0xc02e9a34  lr =3D 0xc05f51dc = (set_regs)
       sp =3D = 0xde2c58e4  fp =3D 0xde2c58f8
set_regs() at = set_regs
       pc =3D 0xc05f51dc =  lr =3D 0xc026f8f0 = (elf32_get_fpregset+0x2c)
       sp = =3D 0xde2c5900  fp =3D = 0xde2c5908
       r4 =3D = 0xc3398090  r5 =3D 0xc026f8c4
elf32_get_fpregset() at = elf32_get_fpregset+0x2c
       pc = =3D 0xc026f8f0  lr =3D 0xc026d848 = (elf32_coredump+0x308)
       sp =3D= 0xde2c5910  fp =3D = 0xde2c5988
       r4 =3D = 0xc0902a7c r10 =3D 0xde2c5960
elf32_coredump() at = elf32_coredump+0x308
       pc =3D = 0xc026d848  lr =3D 0xc02eea74 = (sigexit+0xce0)
       sp =3D = 0xde2c5990  fp =3D = 0xde2c5cf8
       r4 =3D = 0x0000004e  r5 =3D = 0xdf580b60
       r6 =3D = 0xdf580a78  r7 =3D = 0xc026d540
       r8 =3D = 0xdddcb2bc  r9 =3D = 0xdf580ad4
      r10 =3D = 0x00000000
sigexit() at = sigexit+0xce0
       pc =3D = 0xc02eea74  lr =3D 0xc02ef36c = (postsig+0x128)
       sp =3D = 0xde2c5d00  fp =3D = 0xde2c5d88
       r4 =3D = 0x00000006  r5 =3D = 0xdd43fba0
       r6 =3D = 0xde2c5d20  r7 =3D = 0xde2c5d18
       r8 =3D = 0xdddcb1f8  r9 =3D = 0xdf3d9ab8
      r10 =3D = 0x00000005
postsig() at = postsig+0x128
       pc =3D = 0xc02ef36c  lr =3D 0xc02f316c = (ast_sig+0x11c)
       sp =3D = 0xde2c5d90  fp =3D = 0xde2c5e08
       r4 =3D = 0xdd43fba0  r5 =3D = 0xdddcb2bc
       r6 =3D = 0xc0734d22  r7 =3D = 0x00000000
       r8 =3D = 0xdddcb1f8  r9 =3D = 0x00000ab8
      r10 =3D = 0x22530384
ast_sig() at = ast_sig+0x11c
       pc =3D = 0xc02f316c  lr =3D 0xc035444c = (ast_handler+0xe0)
       sp =3D = 0xde2c5e10  fp =3D = 0xde2c5e28
       r4 =3D = 0xde2c5e40  r5 =3D = 0x0000000e
       r6 =3D = 0x00004000  r7 =3D = 0xc096b59c
       r8 =3D = 0xdd43fba0  r9 =3D 0x00000001
ast_handler() at = ast_handler+0xe0
       pc =3D = 0xc035444c  lr =3D 0xc035435c = (ast+0x20)
       sp =3D = 0xde2c5e30  fp =3D = 0xde2c5e38
       r4 =3D = 0xde2c5e40  r5 =3D = 0xdd43fba0
       r6 =3D = 0x00000000  r7 =3D = 0x000001b1
       r8 =3D = 0x22c4b500  r9 =3D 0x00000000
ast() at = ast+0x20
       pc =3D 0xc035435c =  lr =3D 0xc05eaa88 = (swi_exit+0x3c)
       sp =3D = 0xde2c5e40  fp =3D = 0xbb9fbe38
       r4 =3D = 0x60000013  r5 =3D 0xdd43fba0
swi_exit() at = swi_exit+0x3c
       pc =3D = 0xc05eaa88  lr =3D 0xc05eaa88 = (swi_exit+0x3c)
       sp =3D = 0xde2c5e40  fp =3D 0xbb9fbe38
db> 

The machine was = last updated about a week ago, the
sources were updated earlier = today. This panic is
new to me.


I now have a small C++ program that, when = aborted
by SIGABRT on armv7 (say = via control-\), gets the
above = type of FreeBSD crash while trying to produce
the *.core file (debug style armv7 kernel = in use).

I've sent the authors of = the recent
VFP-use-in-armv7-kernel = changes the details, also:
Warner = L. .

I previously sent them a = small C program that gets a
KASSERT = based panic for a debug armv7 kernel when
run = under gdb or lldb with a breakpoint at a
specific routine.

In = general, looks like armv7 floating point use is now
problematical on main's [so: 14's] armv7 = kernel until
more work is = done.

=3D=3D=3D
Mark Millard
marklmi = at yahoo.com

= --Apple-Mail=_8B4575DD-EC51-4B1A-8535-DCF534833113-- From nobody Mon Feb 20 13:15:41 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 4PL2xD1SLGz3snS7 for ; Mon, 20 Feb 2023 13:16:16 +0000 (UTC) (envelope-from kd@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 4PL2xD1CNJz3mNk; Mon, 20 Feb 2023 13:16:16 +0000 (UTC) (envelope-from kd@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676898976; 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=EdHeF7TShRJKpjjt65nYqu1VhNs1eMQktGet3aINhbo=; b=aTULvRrqqVDrE2CCvSjs6njw/fF//donDDRL7flSjpOOsFLmfcCx43VwgQVlmLM+BRtI2U mvia7r0oGXWuPENGWS77NhdIGOu+DfJxSirq82x5nnrw5TxHTTfd4kzMU6O5ovZiAZFWdq Yd3hUMCbvbk2/7k8aRDysuVBvi9WtfOnmD6g1lKS3NNkBcKmnjoePF2RPZf6q2dHC2kv3m ASbe0YBGHDtJPB6A1vFjsLtVnV1y64BSDL5KracsgoB+7zRqgAgBQF5O7bWNC78Y7mXJJg B57HZ9lT0rcHeR7xhFOHsmEwv7lplZtX5Uzyjm12mApSM7mFxiQq6I42aTNXvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676898976; 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=EdHeF7TShRJKpjjt65nYqu1VhNs1eMQktGet3aINhbo=; b=FyJwnbjE42J6PNLwKreIo3nVCkOwz56lbkdZ2p4M2iUAOQCPsUbfLQ7v6LxN4WmtqwK8tP TOxA2V+hVzMLUoZGnSsCNGhcYa1wF32vdores7dxqy1SMPWaVSsXcBk18Ia/pxIdo7r8IC mNJxE33lfQWBsVMilDowstD6TNOvt6HnElZWsBjfMNQBcswAKJjcl97Vbc2+yoppn/aFDy FZSVP00AJ+sNTrET13y06Ehs25stllJjk6p76w1E2mjtZGZsc8HmpEzAD753zkvpzyc0Q6 jFq/lKi82yHeedMvswge3npSE3+g3UPf1Bpqnna+G20VIlc0FhWnomScl0SrNg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676898976; a=rsa-sha256; cv=none; b=DraaAcTNByXK62GA8LreWdIbbhaf/i66uVVg5Av6dAKrFzaY8mgjkcQcNXiNWUtWPBqmHt 8tJKQGRm+nMakgeg8VLqojDwayO0h/X5Xo1hguhH6zLBZnf8a4cpszcgrQUvOMVW31ONvP k+FMPEh0yzFO5Q1tjCxxozLpifXAPqc/lS8u7Y6P80swLXBdNJFXFy0ZIMFKa7RS28F4Pt CvJdLkzAS9FVCt68/OWFneTa+qPcYvJ8vCxlOyKFLj2d0xhfjbU7NQSXBE8+d8wCKkX7Nl 2uFmDhFIL3Iv4KU71gB43rMUae+E/FX8WgBvN4DAT7v9Yy1OVJA6Le3yVTY6iQ== Received: from [192.168.1.3] (46.205.209.129.nat.ftth.dynamic.t-mobile.pl [46.205.209.129]) (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) (Authenticated sender: kd) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PL2xC0qztz1487; Mon, 20 Feb 2023 13:16:14 +0000 (UTC) (envelope-from kd@FreeBSD.org) Content-Type: multipart/alternative; boundary="------------Bx1W1MM91A08eSxCXrODBxBs" Message-ID: <85ed9a05-e4ea-2811-1701-b8f2e982e3b1@FreeBSD.org> Date: Mon, 20 Feb 2023 14:15:41 +0100 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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: Armv7 panic on -current, rpi2 buildworld Content-Language: en-US To: Andrew Turner Cc: Mark Millard , bob prohaska , "freebsd-arm@freebsd.org" References: <20230215025741.GA32086@www.zefox.net> From: =?UTF-8?Q?Kornel_Dul=c4=99ba?= In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------Bx1W1MM91A08eSxCXrODBxBs Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit > Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There were > conditional branch instructions that may mean the function to save the > VFP state was not being run. I'm currently debugging this and applying 24abb6b82102eec577eff9bd8dd7726e8cab89f4 didn't quite help. (I've tested it with dbl_and_ull_via_async that Mark shared in another thread.) The root cause is located in vfp_save_state. It's called during the dump, right before the assert is triggered: 359         /* 360          * savectx() will be called on panic with dumppcb as an argument, 361          * dumppcb doesn't have pcb_vfpsaved set, so set it to save 362          * the VFP registers. 363          */ 364         if (pcb->pcb_vfpsaved == NULL) 365                 pcb->pcb_vfpsaved = &pcb->pcb_vfpstate; Here pcb_vfpsaved == NULL, since the VFP has never been used in the kernel. This triggers the KASSERT in get_vfpcontext, causing the panic. Note that arm64 has very similar logic, so I wonder if a similar panic could be observed there. Any thoughts? > > Andrew > >> On 16 Feb 2023, at 19:35, Mark Millard wrote: >> >> On Feb 14, 2023, at 23:16, Mark Millard wrote: >> >>> On Feb 14, 2023, at 20:16, Warner Losh wrote: >>> >>>> Sorry to top post... what program was dumping core? Looks like a >>>> too strict assert >>> >>> Just a possible point, given recent kernel floating >>> point work: >>> >>> Because of Bob's note, I tried to do a typical build >>> and test of some benchmark programs that I sometimes >>> use that involve floating point in some of the >>> programs, some use with multithreading involved. (As >>> FreeBSD and g++ progress I tend to do this once and >>> a while, not as often on armv7 as on aarch64.) >>> >>> On armv7, I now get a message about a failure of an >>> internal cross-check, which also leads to the program >>> being stopped early. The messaging from run to run >>> varies what the failure is, but the runs should not >>> vary and should not fail the cross-checks --and >>> previously did not, including when I last tried armv7. >>> (Not recently.) >>> >>> For the specific example failure, the initial serial >>> (single thread) test with float involved works but the >>> following multi-thread test in the same program fails >>> and causes the program to stop when it notices there >>> is a problem. >>> >>> The programs that do not test floating point do not >>> fail. These can involve floating point outside the >>> algorithm benchmarked, but with no multi-threading >>> involved for such and no floating point based cross- >>> checks involved. >>> >>> At this point it is far from obvious to me how I >>> would trackdown the specifics of what leads to the >>> failed cross-checks. But the above is suggestive of >>> there being problems for armv7 handling of saving >>> and restoring floating point context for >>> multi-threading. I've no clue if such are limited >>> to the floating point values or not. >>> >>>> Warner >>>> >>>> On Tue, Feb 14, 2023, 7:57 PM bob prohaska wrote: >>>> Building world on an RPi2 armv7, buildworld stopped with >>>> bob@www:/usr/src % panic: Called fill_fpregs while the kernel is >>>> using the VFP >>>> cpuid = 0 >>>> time = 1676427410 >>>> KDB: stack backtrace: >>>> db_trace_self() at db_trace_self >>>>        pc = 0xc05e8160  lr = 0xc007aa04 (db_trace_self_wrapper+0x30) >>>>        sp = 0xde2c5790  fp = 0xde2c58a8 >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >>>>        pc = 0xc007aa04  lr = 0xc02e9c54 (vpanic+0x140) >>>>        sp = 0xde2c58b0  fp = 0xde2c58d0 >>>>        r4 = 0x00000100  r5 = 0x00000000 >>>>        r6 = 0xc07372ef  r7 = 0xc0b13968 >>>> vpanic() at vpanic+0x140 >>>>        pc = 0xc02e9c54  lr = 0xc02e9a34 (dump_savectx) >>>>        sp = 0xde2c58d8  fp = 0xde2c58dc >>>>        r4 = 0xd70c8600  r5 = 0xde2c5e90 >>>>        r6 = 0xc3398090  r7 = 0xe0cfc440 >>>>        r8 = 0xc3398080  r9 = 0xd70c8600 >>>>       r10 = 0xde2c5960 >>>> dump_savectx() at dump_savectx >>>>        pc = 0xc02e9a34  lr = 0xc05f51dc (set_regs) >>>>        sp = 0xde2c58e4  fp = 0xde2c58f8 >>>> set_regs() at set_regs >>>>        pc = 0xc05f51dc  lr = 0xc026f8f0 (elf32_get_fpregset+0x2c) >>>>        sp = 0xde2c5900  fp = 0xde2c5908 >>>>        r4 = 0xc3398090  r5 = 0xc026f8c4 >>>> elf32_get_fpregset() at elf32_get_fpregset+0x2c >>>>        pc = 0xc026f8f0  lr = 0xc026d848 (elf32_coredump+0x308) >>>>        sp = 0xde2c5910  fp = 0xde2c5988 >>>>        r4 = 0xc0902a7c r10 = 0xde2c5960 >>>> elf32_coredump() at elf32_coredump+0x308 >>>>        pc = 0xc026d848  lr = 0xc02eea74 (sigexit+0xce0) >>>>        sp = 0xde2c5990  fp = 0xde2c5cf8 >>>>        r4 = 0x0000004e  r5 = 0xdf580b60 >>>>        r6 = 0xdf580a78  r7 = 0xc026d540 >>>>        r8 = 0xdddcb2bc  r9 = 0xdf580ad4 >>>>       r10 = 0x00000000 >>>> sigexit() at sigexit+0xce0 >>>>        pc = 0xc02eea74  lr = 0xc02ef36c (postsig+0x128) >>>>        sp = 0xde2c5d00  fp = 0xde2c5d88 >>>>        r4 = 0x00000006  r5 = 0xdd43fba0 >>>>        r6 = 0xde2c5d20  r7 = 0xde2c5d18 >>>>        r8 = 0xdddcb1f8  r9 = 0xdf3d9ab8 >>>>       r10 = 0x00000005 >>>> postsig() at postsig+0x128 >>>>        pc = 0xc02ef36c  lr = 0xc02f316c (ast_sig+0x11c) >>>>        sp = 0xde2c5d90  fp = 0xde2c5e08 >>>>        r4 = 0xdd43fba0  r5 = 0xdddcb2bc >>>>        r6 = 0xc0734d22  r7 = 0x00000000 >>>>        r8 = 0xdddcb1f8  r9 = 0x00000ab8 >>>>       r10 = 0x22530384 >>>> ast_sig() at ast_sig+0x11c >>>>        pc = 0xc02f316c  lr = 0xc035444c (ast_handler+0xe0) >>>>        sp = 0xde2c5e10  fp = 0xde2c5e28 >>>>        r4 = 0xde2c5e40  r5 = 0x0000000e >>>>        r6 = 0x00004000  r7 = 0xc096b59c >>>>        r8 = 0xdd43fba0  r9 = 0x00000001 >>>> ast_handler() at ast_handler+0xe0 >>>>        pc = 0xc035444c  lr = 0xc035435c (ast+0x20) >>>>        sp = 0xde2c5e30  fp = 0xde2c5e38 >>>>        r4 = 0xde2c5e40  r5 = 0xdd43fba0 >>>>        r6 = 0x00000000  r7 = 0x000001b1 >>>>        r8 = 0x22c4b500  r9 = 0x00000000 >>>> ast() at ast+0x20 >>>>        pc = 0xc035435c  lr = 0xc05eaa88 (swi_exit+0x3c) >>>>        sp = 0xde2c5e40  fp = 0xbb9fbe38 >>>>        r4 = 0x60000013  r5 = 0xdd43fba0 >>>> swi_exit() at swi_exit+0x3c >>>>        pc = 0xc05eaa88  lr = 0xc05eaa88 (swi_exit+0x3c) >>>>        sp = 0xde2c5e40  fp = 0xbb9fbe38 >>>> KDB: enter: panic >>>> [ thread pid 81621 tid 101111 ] >>>> Stopped at      kdb_enter+0x54: ldrb    r15, [r15, r15, ror r15]! >>>> db> bt >>>> Tracing pid 81621 tid 101111 td 0xdd43fba0 >>>> db_trace_self() at db_trace_self >>>>        pc = 0xc05e8160  lr = 0xc00774a0 (db_stack_trace+0x140) >>>>        sp = 0xde2c55d8  fp = 0xde2c55f0 >>>> db_stack_trace() at db_stack_trace+0x140 >>>>        pc = 0xc00774a0  lr = 0xc00770f0 (db_command+0x310) >>>>        sp = 0xde2c55f8  fp = 0xde2c56a0 >>>>        r4 = 0xc0745722  r5 = 0x00000062 >>>>        r6 = 0x00000000 r10 = 0x00000000 >>>> db_command() at db_command+0x310 >>>>        pc = 0xc00770f0  lr = 0xc0076db8 (db_command_loop+0x64) >>>>        sp = 0xde2c56a8  fp = 0xde2c56b8 >>>>        r4 = 0xc07ac186  r5 = 0xc07ab7fe >>>>        r6 = 0xc0986f5c  r7 = 0xc0b13968 >>>>        r8 = 0xc0b23738  r9 = 0x00000000 >>>>       r10 = 0x00000001 >>>> db_command_loop() at db_command_loop+0x64 >>>>        pc = 0xc0076db8  lr = 0xc007ab88 (db_trap+0x128) >>>>        sp = 0xde2c56c0  fp = 0xde2c57d8 >>>>        r4 = 0x00000000  r5 = 0xc0986f50 >>>>        r6 = 0xc0b23758 r10 = 0x00000001 >>>> db_trap() at db_trap+0x128 >>>>        pc = 0xc007ab88  lr = 0xc033bb84 (kdb_trap+0x258) >>>>        sp = 0xde2c57e0  fp = 0xde2c5808 >>>>        r4 = 0xc078390c  r5 = 0xc08d5270 >>>>        r6 = 0xc0b23758  r7 = 0xc0b13968 >>>> kdb_trap() at kdb_trap+0x258 >>>>        pc = 0xc033bb84  lr = 0xc05eaab8 (exception_exit) >>>>        sp = 0xde2c5810  fp = 0xde2c58a8 >>>>        r4 = 0x200000d3  r5 = 0x00000000 >>>>        r6 = 0xc07372ef  r7 = 0xc0b13968 >>>>        r8 = 0xc093fa0c  r9 = 0xde2c58e4 >>>>       r10 = 0xc0b13a68 >>>> exception_exit() at exception_exit >>>>        pc = 0xc05eaab8  lr = 0xc033b044 (kdb_enter+0x50) >>>>        sp = 0xde2c58a0  fp = 0xde2c58a8 >>>>        r0 = 0x00000000  r1 = 0x00000001 >>>>        r2 = 0x00000012  r3 = 0x00000000 >>>>        r4 = 0xc0b23748  r5 = 0x00000000 >>>>        r6 = 0xc07372ef  r7 = 0xc0b13968 >>>>        r8 = 0xc093fa0c  r9 = 0xde2c58e4 >>>>       r10 = 0xc0b13a68 r12 = 0x00000000 >>>> kdb_enter() at kdb_enter+0x58 >>>>        pc = 0xc033b04c  lr = 0xc02e9ca0 (vpanic+0x18c) >>>>        sp = 0xde2c58b0  fp = 0xde2c58d0 >>>>        r4 = 0x00000100 r10 = 0xc0b13a68 >>>> vpanic() at vpanic+0x18c >>>>        pc = 0xc02e9ca0  lr = 0xc02e9a34 (dump_savectx) >>>>        sp = 0xde2c58d8  fp = 0xde2c58dc >>>>        r4 = 0xd70c8600  r5 = 0xde2c5e90 >>>>        r6 = 0xc3398090  r7 = 0xe0cfc440 >>>>        r8 = 0xc3398080  r9 = 0xd70c8600 >>>>       r10 = 0xde2c5960 >>>> dump_savectx() at dump_savectx >>>>        pc = 0xc02e9a34  lr = 0xc05f51dc (set_regs) >>>>        sp = 0xde2c58e4  fp = 0xde2c58f8 >>>> set_regs() at set_regs >>>>        pc = 0xc05f51dc  lr = 0xc026f8f0 (elf32_get_fpregset+0x2c) >>>>        sp = 0xde2c5900  fp = 0xde2c5908 >>>>        r4 = 0xc3398090  r5 = 0xc026f8c4 >>>> elf32_get_fpregset() at elf32_get_fpregset+0x2c >>>>        pc = 0xc026f8f0  lr = 0xc026d848 (elf32_coredump+0x308) >>>>        sp = 0xde2c5910  fp = 0xde2c5988 >>>>        r4 = 0xc0902a7c r10 = 0xde2c5960 >>>> elf32_coredump() at elf32_coredump+0x308 >>>>        pc = 0xc026d848  lr = 0xc02eea74 (sigexit+0xce0) >>>>        sp = 0xde2c5990  fp = 0xde2c5cf8 >>>>        r4 = 0x0000004e  r5 = 0xdf580b60 >>>>        r6 = 0xdf580a78  r7 = 0xc026d540 >>>>        r8 = 0xdddcb2bc  r9 = 0xdf580ad4 >>>>       r10 = 0x00000000 >>>> sigexit() at sigexit+0xce0 >>>>        pc = 0xc02eea74  lr = 0xc02ef36c (postsig+0x128) >>>>        sp = 0xde2c5d00  fp = 0xde2c5d88 >>>>        r4 = 0x00000006  r5 = 0xdd43fba0 >>>>        r6 = 0xde2c5d20  r7 = 0xde2c5d18 >>>>        r8 = 0xdddcb1f8  r9 = 0xdf3d9ab8 >>>>       r10 = 0x00000005 >>>> postsig() at postsig+0x128 >>>>        pc = 0xc02ef36c  lr = 0xc02f316c (ast_sig+0x11c) >>>>        sp = 0xde2c5d90  fp = 0xde2c5e08 >>>>        r4 = 0xdd43fba0  r5 = 0xdddcb2bc >>>>        r6 = 0xc0734d22  r7 = 0x00000000 >>>>        r8 = 0xdddcb1f8  r9 = 0x00000ab8 >>>>       r10 = 0x22530384 >>>> ast_sig() at ast_sig+0x11c >>>>        pc = 0xc02f316c  lr = 0xc035444c (ast_handler+0xe0) >>>>        sp = 0xde2c5e10  fp = 0xde2c5e28 >>>>        r4 = 0xde2c5e40  r5 = 0x0000000e >>>>        r6 = 0x00004000  r7 = 0xc096b59c >>>>        r8 = 0xdd43fba0  r9 = 0x00000001 >>>> ast_handler() at ast_handler+0xe0 >>>>        pc = 0xc035444c  lr = 0xc035435c (ast+0x20) >>>>        sp = 0xde2c5e30  fp = 0xde2c5e38 >>>>        r4 = 0xde2c5e40  r5 = 0xdd43fba0 >>>>        r6 = 0x00000000  r7 = 0x000001b1 >>>>        r8 = 0x22c4b500  r9 = 0x00000000 >>>> ast() at ast+0x20 >>>>        pc = 0xc035435c  lr = 0xc05eaa88 (swi_exit+0x3c) >>>>        sp = 0xde2c5e40  fp = 0xbb9fbe38 >>>>        r4 = 0x60000013  r5 = 0xdd43fba0 >>>> swi_exit() at swi_exit+0x3c >>>>        pc = 0xc05eaa88  lr = 0xc05eaa88 (swi_exit+0x3c) >>>>        sp = 0xde2c5e40  fp = 0xbb9fbe38 >>>> db> >>>> >>>> The machine was last updated about a week ago, the >>>> sources were updated earlier today. This panic is >>>> new to me. >>> >> >> I now have a small C++ program that, when aborted >> by SIGABRT on armv7 (say via control-\), gets the >> above type of FreeBSD crash while trying to produce >> the *.core file (debug style armv7 kernel in use). >> >> I've sent the authors of the recent >> VFP-use-in-armv7-kernel changes the details, also: >> Warner L. . >> >> I previously sent them a small C program that gets a >> KASSERT based panic for a debug armv7 kernel when >> run under gdb or lldb with a breakpoint at a >> specific routine. >> >> In general, looks like armv7 floating point use is now >> problematical on main's [so: 14's] armv7 kernel until >> more work is done. >> >> === >> Mark Millard >> marklmi atyahoo.com > --------------Bx1W1MM91A08eSxCXrODBxBs Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There were conditional branch instructions that may mean the function to save the VFP state was not being run.

I'm currently debugging this and applying 24abb6b82102eec577eff9bd8dd7726e8cab89f4 didn't quite help.
(I've tested it with dbl_and_ull_via_async that Mark shared in another thread.)
The root cause is located in vfp_save_state. It's called during the dump, right before the assert is triggered:

359         /*
360          * savectx() will be called on panic with dumppcb as an argument,
361          * dumppcb doesn't have pcb_vfpsaved set, so set it to save
362          * the VFP registers.
363          */
364         if (pcb->pcb_vfpsaved == NULL)
365                 pcb->pcb_vfpsaved = &pcb->pcb_vfpstate;

Here pcb_vfpsaved == NULL, since the VFP has never been used in the kernel.
This triggers the KASSERT in get_vfpcontext, causing the panic.
Note that arm64 has very similar logic, so I wonder if a similar panic could be observed there.
Any thoughts?


Andrew

On 16 Feb 2023, at 19:35, Mark Millard <marklmi@yahoo.com> wrote:

On Feb 14, 2023, at 23:16, Mark Millard <marklmi@yahoo.com> wrote:

On Feb 14, 2023, at 20:16, Warner Losh <imp@bsdimp.com> wrote:

Sorry to top post... what program was dumping core? Looks like a too strict assert

Just a possible point, given recent kernel floating
point work:

Because of Bob's note, I tried to do a typical build
and test of some benchmark programs that I sometimes
use that involve floating point in some of the
programs, some use with multithreading involved. (As
FreeBSD and g++ progress I tend to do this once and
a while, not as often on armv7 as on aarch64.)

On armv7, I now get a message about a failure of an
internal cross-check, which also leads to the program
being stopped early. The messaging from run to run
varies what the failure is, but the runs should not
vary and should not fail the cross-checks --and
previously did not, including when I last tried armv7.
(Not recently.)

For the specific example failure, the initial serial
(single thread) test with float involved works but the
following multi-thread test in the same program fails
and causes the program to stop when it notices there
is a problem.

The programs that do not test floating point do not
fail. These can involve floating point outside the
algorithm benchmarked, but with no multi-threading
involved for such and no floating point based cross-
checks involved.

At this point it is far from obvious to me how I
would trackdown the specifics of what leads to the
failed cross-checks. But the above is suggestive of
there being problems for armv7 handling of saving
and restoring floating point context for
multi-threading. I've no clue if such are limited
to the floating point values or not.

Warner

On Tue, Feb 14, 2023, 7:57 PM bob prohaska <fbsd@www.zefox.net> wrote:
Building world on an RPi2 armv7, buildworld stopped with
bob@www:/usr/src % panic: Called fill_fpregs while the kernel is using the VFP
cpuid = 0
time = 1676427410
KDB: stack backtrace:
db_trace_self() at db_trace_self
       pc = 0xc05e8160  lr = 0xc007aa04 (db_trace_self_wrapper+0x30)
       sp = 0xde2c5790  fp = 0xde2c58a8
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
       pc = 0xc007aa04  lr = 0xc02e9c54 (vpanic+0x140)
       sp = 0xde2c58b0  fp = 0xde2c58d0
       r4 = 0x00000100  r5 = 0x00000000
       r6 = 0xc07372ef  r7 = 0xc0b13968
vpanic() at vpanic+0x140
       pc = 0xc02e9c54  lr = 0xc02e9a34 (dump_savectx)
       sp = 0xde2c58d8  fp = 0xde2c58dc
       r4 = 0xd70c8600  r5 = 0xde2c5e90
       r6 = 0xc3398090  r7 = 0xe0cfc440
       r8 = 0xc3398080  r9 = 0xd70c8600
      r10 = 0xde2c5960
dump_savectx() at dump_savectx
       pc = 0xc02e9a34  lr = 0xc05f51dc (set_regs)
       sp = 0xde2c58e4  fp = 0xde2c58f8
set_regs() at set_regs
       pc = 0xc05f51dc  lr = 0xc026f8f0 (elf32_get_fpregset+0x2c)
       sp = 0xde2c5900  fp = 0xde2c5908
       r4 = 0xc3398090  r5 = 0xc026f8c4
elf32_get_fpregset() at elf32_get_fpregset+0x2c
       pc = 0xc026f8f0  lr = 0xc026d848 (elf32_coredump+0x308)
       sp = 0xde2c5910  fp = 0xde2c5988
       r4 = 0xc0902a7c r10 = 0xde2c5960
elf32_coredump() at elf32_coredump+0x308
       pc = 0xc026d848  lr = 0xc02eea74 (sigexit+0xce0)
       sp = 0xde2c5990  fp = 0xde2c5cf8
       r4 = 0x0000004e  r5 = 0xdf580b60
       r6 = 0xdf580a78  r7 = 0xc026d540
       r8 = 0xdddcb2bc  r9 = 0xdf580ad4
      r10 = 0x00000000
sigexit() at sigexit+0xce0
       pc = 0xc02eea74  lr = 0xc02ef36c (postsig+0x128)
       sp = 0xde2c5d00  fp = 0xde2c5d88
       r4 = 0x00000006  r5 = 0xdd43fba0
       r6 = 0xde2c5d20  r7 = 0xde2c5d18
       r8 = 0xdddcb1f8  r9 = 0xdf3d9ab8
      r10 = 0x00000005
postsig() at postsig+0x128
       pc = 0xc02ef36c  lr = 0xc02f316c (ast_sig+0x11c)
       sp = 0xde2c5d90  fp = 0xde2c5e08
       r4 = 0xdd43fba0  r5 = 0xdddcb2bc
       r6 = 0xc0734d22  r7 = 0x00000000
       r8 = 0xdddcb1f8  r9 = 0x00000ab8
      r10 = 0x22530384
ast_sig() at ast_sig+0x11c
       pc = 0xc02f316c  lr = 0xc035444c (ast_handler+0xe0)
       sp = 0xde2c5e10  fp = 0xde2c5e28
       r4 = 0xde2c5e40  r5 = 0x0000000e
       r6 = 0x00004000  r7 = 0xc096b59c
       r8 = 0xdd43fba0  r9 = 0x00000001
ast_handler() at ast_handler+0xe0
       pc = 0xc035444c  lr = 0xc035435c (ast+0x20)
       sp = 0xde2c5e30  fp = 0xde2c5e38
       r4 = 0xde2c5e40  r5 = 0xdd43fba0
       r6 = 0x00000000  r7 = 0x000001b1
       r8 = 0x22c4b500  r9 = 0x00000000
ast() at ast+0x20
       pc = 0xc035435c  lr = 0xc05eaa88 (swi_exit+0x3c)
       sp = 0xde2c5e40  fp = 0xbb9fbe38
       r4 = 0x60000013  r5 = 0xdd43fba0
swi_exit() at swi_exit+0x3c
       pc = 0xc05eaa88  lr = 0xc05eaa88 (swi_exit+0x3c)
       sp = 0xde2c5e40  fp = 0xbb9fbe38
KDB: enter: panic
[ thread pid 81621 tid 101111 ]
Stopped at      kdb_enter+0x54: ldrb    r15, [r15, r15, ror r15]!
db> bt
Tracing pid 81621 tid 101111 td 0xdd43fba0
db_trace_self() at db_trace_self
       pc = 0xc05e8160  lr = 0xc00774a0 (db_stack_trace+0x140)
       sp = 0xde2c55d8  fp = 0xde2c55f0
db_stack_trace() at db_stack_trace+0x140
       pc = 0xc00774a0  lr = 0xc00770f0 (db_command+0x310)
       sp = 0xde2c55f8  fp = 0xde2c56a0
       r4 = 0xc0745722  r5 = 0x00000062
       r6 = 0x00000000 r10 = 0x00000000
db_command() at db_command+0x310
       pc = 0xc00770f0  lr = 0xc0076db8 (db_command_loop+0x64)
       sp = 0xde2c56a8  fp = 0xde2c56b8
       r4 = 0xc07ac186  r5 = 0xc07ab7fe
       r6 = 0xc0986f5c  r7 = 0xc0b13968
       r8 = 0xc0b23738  r9 = 0x00000000
      r10 = 0x00000001
db_command_loop() at db_command_loop+0x64
       pc = 0xc0076db8  lr = 0xc007ab88 (db_trap+0x128)
       sp = 0xde2c56c0  fp = 0xde2c57d8
       r4 = 0x00000000  r5 = 0xc0986f50
       r6 = 0xc0b23758 r10 = 0x00000001
db_trap() at db_trap+0x128
       pc = 0xc007ab88  lr = 0xc033bb84 (kdb_trap+0x258)
       sp = 0xde2c57e0  fp = 0xde2c5808
       r4 = 0xc078390c  r5 = 0xc08d5270
       r6 = 0xc0b23758  r7 = 0xc0b13968
kdb_trap() at kdb_trap+0x258
       pc = 0xc033bb84  lr = 0xc05eaab8 (exception_exit)
       sp = 0xde2c5810  fp = 0xde2c58a8
       r4 = 0x200000d3  r5 = 0x00000000
       r6 = 0xc07372ef  r7 = 0xc0b13968
       r8 = 0xc093fa0c  r9 = 0xde2c58e4
      r10 = 0xc0b13a68
exception_exit() at exception_exit
       pc = 0xc05eaab8  lr = 0xc033b044 (kdb_enter+0x50)
       sp = 0xde2c58a0  fp = 0xde2c58a8
       r0 = 0x00000000  r1 = 0x00000001
       r2 = 0x00000012  r3 = 0x00000000
       r4 = 0xc0b23748  r5 = 0x00000000
       r6 = 0xc07372ef  r7 = 0xc0b13968
       r8 = 0xc093fa0c  r9 = 0xde2c58e4
      r10 = 0xc0b13a68 r12 = 0x00000000
kdb_enter() at kdb_enter+0x58
       pc = 0xc033b04c  lr = 0xc02e9ca0 (vpanic+0x18c)
       sp = 0xde2c58b0  fp = 0xde2c58d0
       r4 = 0x00000100 r10 = 0xc0b13a68
vpanic() at vpanic+0x18c
       pc = 0xc02e9ca0  lr = 0xc02e9a34 (dump_savectx)
       sp = 0xde2c58d8  fp = 0xde2c58dc
       r4 = 0xd70c8600  r5 = 0xde2c5e90
       r6 = 0xc3398090  r7 = 0xe0cfc440
       r8 = 0xc3398080  r9 = 0xd70c8600
      r10 = 0xde2c5960
dump_savectx() at dump_savectx
       pc = 0xc02e9a34  lr = 0xc05f51dc (set_regs)
       sp = 0xde2c58e4  fp = 0xde2c58f8
set_regs() at set_regs
       pc = 0xc05f51dc  lr = 0xc026f8f0 (elf32_get_fpregset+0x2c)
       sp = 0xde2c5900  fp = 0xde2c5908
       r4 = 0xc3398090  r5 = 0xc026f8c4
elf32_get_fpregset() at elf32_get_fpregset+0x2c
       pc = 0xc026f8f0  lr = 0xc026d848 (elf32_coredump+0x308)
       sp = 0xde2c5910  fp = 0xde2c5988
       r4 = 0xc0902a7c r10 = 0xde2c5960
elf32_coredump() at elf32_coredump+0x308
       pc = 0xc026d848  lr = 0xc02eea74 (sigexit+0xce0)
       sp = 0xde2c5990  fp = 0xde2c5cf8
       r4 = 0x0000004e  r5 = 0xdf580b60
       r6 = 0xdf580a78  r7 = 0xc026d540
       r8 = 0xdddcb2bc  r9 = 0xdf580ad4
      r10 = 0x00000000
sigexit() at sigexit+0xce0
       pc = 0xc02eea74  lr = 0xc02ef36c (postsig+0x128)
       sp = 0xde2c5d00  fp = 0xde2c5d88
       r4 = 0x00000006  r5 = 0xdd43fba0
       r6 = 0xde2c5d20  r7 = 0xde2c5d18
       r8 = 0xdddcb1f8  r9 = 0xdf3d9ab8
      r10 = 0x00000005
postsig() at postsig+0x128
       pc = 0xc02ef36c  lr = 0xc02f316c (ast_sig+0x11c)
       sp = 0xde2c5d90  fp = 0xde2c5e08
       r4 = 0xdd43fba0  r5 = 0xdddcb2bc
       r6 = 0xc0734d22  r7 = 0x00000000
       r8 = 0xdddcb1f8  r9 = 0x00000ab8
      r10 = 0x22530384
ast_sig() at ast_sig+0x11c
       pc = 0xc02f316c  lr = 0xc035444c (ast_handler+0xe0)
       sp = 0xde2c5e10  fp = 0xde2c5e28
       r4 = 0xde2c5e40  r5 = 0x0000000e
       r6 = 0x00004000  r7 = 0xc096b59c
       r8 = 0xdd43fba0  r9 = 0x00000001
ast_handler() at ast_handler+0xe0
       pc = 0xc035444c  lr = 0xc035435c (ast+0x20)
       sp = 0xde2c5e30  fp = 0xde2c5e38
       r4 = 0xde2c5e40  r5 = 0xdd43fba0
       r6 = 0x00000000  r7 = 0x000001b1
       r8 = 0x22c4b500  r9 = 0x00000000
ast() at ast+0x20
       pc = 0xc035435c  lr = 0xc05eaa88 (swi_exit+0x3c)
       sp = 0xde2c5e40  fp = 0xbb9fbe38
       r4 = 0x60000013  r5 = 0xdd43fba0
swi_exit() at swi_exit+0x3c
       pc = 0xc05eaa88  lr = 0xc05eaa88 (swi_exit+0x3c)
       sp = 0xde2c5e40  fp = 0xbb9fbe38
db> 

The machine was last updated about a week ago, the
sources were updated earlier today. This panic is
new to me.


I now have a small C++ program that, when aborted
by SIGABRT on armv7 (say via control-\), gets the
above type of FreeBSD crash while trying to produce
the *.core file (debug style armv7 kernel in use).

I've sent the authors of the recent
VFP-use-in-armv7-kernel changes the details, also:
Warner L. .

I previously sent them a small C program that gets a
KASSERT based panic for a debug armv7 kernel when
run under gdb or lldb with a breakpoint at a
specific routine.

In general, looks like armv7 floating point use is now
problematical on main's [so: 14's] armv7 kernel until
more work is done.

===
Mark Millard
marklmi at yahoo.com

--------------Bx1W1MM91A08eSxCXrODBxBs-- From nobody Mon Feb 20 13:32:08 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 4PL3Hx42p8z3spJq for ; Mon, 20 Feb 2023 13:32:29 +0000 (UTC) (envelope-from bT.76ezg8od30=anxr0ibkqrgo=87og0k8ent@em790814.fubar.geek.nz) Received: from e2i580.smtp2go.com (e2i580.smtp2go.com [103.2.142.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4PL3Hx3WjQz3p9g for ; Mon, 20 Feb 2023 13:32:29 +0000 (UTC) (envelope-from bT.76ezg8od30=anxr0ibkqrgo=87og0k8ent@em790814.fubar.geek.nz) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=mgy720.a1-4.dyn; x=1676900849; h=Feedback-ID: X-Smtpcorp-Track:To:Date:Subject:Message-Id:From:Reply-To:Sender: List-Unsubscribe; bh=gXhCe45N/3A8l/ZV5mX4O1w0h9PYRczMZiXtpOiSYto=; b=E9ZEnD7a OKGKcAipSZ3QOyi8fl1vgT5kKMScWS3mSLpHrXB/kwhds499nGoZkeBZl9P2GuSGKE/yXDnacuY4x u1VlounVdMcE/97c5WjYvyun46sC+hmQozLObbj6+A/SroSioxAR2yyc+u7WiYoQXK9qwEYpWG5/l KaRCf59r4DOQjFkVKyVmIlagtKFxYqojYvBEQT8ETJjBkCK2yjQbK6y2oQVtrP7XZyy2zOe0m5EtT vKA3csnAdBwcCVaxamch53kKDMgSn+OQniMGYHe+hAB9eKRPGJMAbeysZMpoby2qRK4l9Ktx0D438 Ymq4C+RTVhVqSmk2Xo9NfjcbgA==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1676899949; h=from : subject : to : message-id : date; bh=gXhCe45N/3A8l/ZV5mX4O1w0h9PYRczMZiXtpOiSYto=; b=TwP6Z6uwMweaflkUsZa9/4J1PUmGzJi89zJKa7Sy+GVTngjuNFS7tqpgjSiZ0me6sWNw9 szYydT/o0opSnttUjPtTEdeZg9nbdQ9zuCJut1PEWnnQc/qp6ZERzUhTRMcip31kMOQkBVJ xRM7eym0itIBu2LjKkuVLd2/Xmf8FxAPpOC3boBJpN+tHFyvFhp6cyqq98NFwnG1+6m1LWO TUG/ounTrXGU9hzOcGfYrWHV3C7IJtFM5gSyw6u0QqpVzp7M6rZg17FUSr53q0luLaPsz8K W/DxpHXBdA5p36FsTvUHGIHiehswgmG99rkYJBqCCyyJHqVfCm3A6Xch1RtA== Received: from [10.176.58.103] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2-S2G) (envelope-from ) id 1pU6HK-qt4IeL-Ej; Mon, 20 Feb 2023 13:32:26 +0000 Received: from [10.162.55.164] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96-S2G) (envelope-from ) id 1pU6HK-9EIKpW-0i; Mon, 20 Feb 2023 13:32:26 +0000 Received: from smtpclient.apple (cpc91210-cmbg18-2-0-cust37.5-4.cable.virginm.net [81.102.44.38]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id BAEE91D59E; Mon, 20 Feb 2023 13:32:21 +0000 (UTC) From: Andrew Turner Message-Id: <1572483E-D0CD-4384-BF73-A00FB3640F91@fubar.geek.nz> Content-Type: multipart/alternative; boundary="Apple-Mail=_3F5E9888-8ACF-4672-84A7-D484E2587056" 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 \(3731.400.51.1.1\)) Subject: Re: Armv7 panic on -current, rpi2 buildworld Date: Mon, 20 Feb 2023 13:32:08 +0000 In-Reply-To: <85ed9a05-e4ea-2811-1701-b8f2e982e3b1@FreeBSD.org> Cc: Mark Millard , bob prohaska , "freebsd-arm@freebsd.org" To: =?utf-8?Q?Kornel_Dul=C4=99ba?= References: <20230215025741.GA32086@www.zefox.net> <85ed9a05-e4ea-2811-1701-b8f2e982e3b1@FreeBSD.org> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Smtpcorp-Track: 1pl6HK9EmKpW0i.86ZrB2d0iktzu Feedback-ID: 790814m:790814amQcrys:790814seVw_yQjFp X-Report-Abuse: Please forward a copy of this message, including all headers, to X-Rspamd-Queue-Id: 4PL3Hx3WjQz3p9g X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:23352, ipnet:103.2.140.0/22, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_3F5E9888-8ACF-4672-84A7-D484E2587056 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Feb 2023, at 13:15, Kornel Dul=C4=99ba wrote: >=20 >> Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There were = conditional branch instructions that may mean the function to save the = VFP state was not being run. > I'm currently debugging this and applying = 24abb6b82102eec577eff9bd8dd7726e8cab89f4 didn't quite help. > (I've tested it with dbl_and_ull_via_async that Mark shared in another = thread.) > The root cause is located in vfp_save_state. It's called during the = dump, right before the assert is triggered: >=20 > 359 /* > 360 * savectx() will be called on panic with dumppcb as an = argument, > 361 * dumppcb doesn't have pcb_vfpsaved set, so set it to = save > 362 * the VFP registers. > 363 */ > 364 if (pcb->pcb_vfpsaved =3D=3D NULL) > 365 pcb->pcb_vfpsaved =3D &pcb->pcb_vfpstate; >=20 > Here pcb_vfpsaved =3D=3D NULL, since the VFP has never been used in = the kernel. > This triggers the KASSERT in get_vfpcontext, causing the panic. > Note that arm64 has very similar logic, so I wonder if a similar panic = could be observed there. > Any thoughts? >=20 It looks like cpu_copy_thread is missing setting pcb_vfpsaved so is = likely to be invalid. On arm64 we set the needed data in vfp_new_thread. This was added to = simplify adding SVE support, but could be reused on arm if it=E2=80=99s = useful. Andrew --Apple-Mail=_3F5E9888-8ACF-4672-84A7-D484E2587056 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 20 = Feb 2023, at 13:15, Kornel Dul=C4=99ba <kd@FreeBSD.org> = wrote:

=20 =20
Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? = There were conditional branch instructions that may mean the function to save the VFP state was not being run.

I'm currently = debugging this and applying 24abb6b82102eec577eff9bd8dd7726e8cab89f4 didn't quite help.
(I've tested it with dbl_and_ull_via_async that Mark shared in another thread.)
The root cause is located in vfp_save_state. It's called during the dump, right before the assert is triggered:

359         /*
360          * = savectx() will be called on panic with dumppcb as an argument,
361          * = dumppcb doesn't have pcb_vfpsaved set, so set it to save
362          * the = VFP registers.
363          */
364         if = (pcb->pcb_vfpsaved =3D=3D NULL)
= 365            = ;     pcb->pcb_vfpsaved =3D &pcb->pcb_vfpstate;

Here pcb_vfpsaved =3D=3D NULL, since the VFP has never been used = in the kernel.
This triggers the KASSERT in get_vfpcontext, causing the = panic.
Note that arm64 has very similar logic, so I wonder if a similar panic could be observed there.
Any thoughts?


It looks = like cpu_copy_thread is missing setting pcb_vfpsaved so is = likely to be invalid.

On arm64 we set the = needed data in vfp_new_thread. This was added to simplify adding = SVE support, but could be reused on arm if it=E2=80=99s = useful.

Andrew

= --Apple-Mail=_3F5E9888-8ACF-4672-84A7-D484E2587056-- From nobody Mon Feb 20 13:53:21 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 4PL3m325nSz3sqpq for ; Mon, 20 Feb 2023 13:53:23 +0000 (UTC) (envelope-from kd@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 4PL3m31SMCz3qXt; Mon, 20 Feb 2023 13:53:23 +0000 (UTC) (envelope-from kd@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676901203; 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=Tfv3QfqZx9H7riBYfi58c1yoyilF/y7AdqP4LZb+kbU=; b=J8eBqmLeQ0XW7wzKb7/s72+iGyZI1QQOlRl6ZzYh6193Y+Vnc2lBxXwc/Sp029msrCW80Z 0nmsbgJx39DKzVs+uyq0QG9cmnBG/DpsHATjJLMEHbVNCm7HNu3yT2bhmWw0504b2DS+Je 78kNn3604xOv+87Fuf1McLeGgdbF5nBOA+cZlHwGgoduhjya8trF+dV/oPy322VZnQOMKk oq2LBAIStQTTIxmo1IWH/xOyYQQx6ll8qrVOnmEP14uI8adrsTRTuWq6NitlCiYFwBLeU5 fIyukYmx/PfMz3izoBdZG42Cz6Oq88voTUv9evjwtts7ZSix6CpYOsnSGjScRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676901203; 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=Tfv3QfqZx9H7riBYfi58c1yoyilF/y7AdqP4LZb+kbU=; b=kLWgMRK2HsmXs5C0PfvL67itmnnQux33JFiEbELqaHpCn4ZcOOIPokb3hyWHNQ5n7sAPK8 CqcxMWZOPU8tHRrwLiuMvYNSvwCY0Zx4OPtXlNzTN44F70UZBLqVockgosuuKc0rRPpqTO JJo+GVuvuO/cIqZ0Gea4Uz1McnYzBvW3KxmWPibu2n3lf7y/FSwILMDsfLvpL5oBuKLrKv KWZYN3/vPxtZsu089KtrIs2c2Q0M7jTfb0/EQYSkvvKaxrhJrCEkVkf6Fm33upptI01VxH z3/rmrxnsj9PqLiyKEgWBPVqflLMF6xBsXrHXysqPJEanHyoeYpKKcjjjJEA/w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676901203; a=rsa-sha256; cv=none; b=MBHpkoPj0ZzFj7MQ/cvMnMb42kM3qMkYnoC/jeMZrJULTAYlvCAPOCOnWNKFqyMSlDaS0K iW6RhvrGM6AEaP4W9Fkkum9MABFMvkyNRj7wj47N4oO0aFubWNZj5in3ijsHwtOky5w2LU 1pvNaF+oHLuqbMbET9unV4SGHvsxPIG8fPjlDf+5RaeGW4uaNk/7/zKiR141njoZPEMduD 09QZ6XnSO1hiKKyn7Pe1XcQoqF/PBGY2eERbJyetvRNpKxlesnukHouBFsu5zzYnQl4SK7 rScGSbY5lYlgUEPRKrj3VppByeq863xLS4UK4Ow1D5qVAGe1yynFhZ1G7ju8tw== Received: from [192.168.1.3] (46.205.209.129.nat.ftth.dynamic.t-mobile.pl [46.205.209.129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: kd) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PL3m22RTWz15w2; Mon, 20 Feb 2023 13:53:22 +0000 (UTC) (envelope-from kd@FreeBSD.org) Content-Type: multipart/alternative; boundary="------------XrbroFEUeTXKeUEnFtS0aYSO" Message-ID: <6aafafbd-590e-29c8-d98f-5d776ebff4bc@FreeBSD.org> Date: Mon, 20 Feb 2023 14:53:21 +0100 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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: Armv7 panic on -current, rpi2 buildworld Content-Language: en-US To: Andrew Turner Cc: Mark Millard , bob prohaska , "freebsd-arm@freebsd.org" References: <20230215025741.GA32086@www.zefox.net> <85ed9a05-e4ea-2811-1701-b8f2e982e3b1@FreeBSD.org> <1572483E-D0CD-4384-BF73-A00FB3640F91@fubar.geek.nz> From: =?UTF-8?Q?Kornel_Dul=c4=99ba?= In-Reply-To: <1572483E-D0CD-4384-BF73-A00FB3640F91@fubar.geek.nz> X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------XrbroFEUeTXKeUEnFtS0aYSO Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/20/23 14:32, Andrew Turner wrote: > > >> On 20 Feb 2023, at 13:15, Kornel Dulęba wrote: >> >>> Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There >>> were conditional branch instructions that may mean the function to >>> save the VFP state was not being run. >> >> I'm currently debugging this and applying >> 24abb6b82102eec577eff9bd8dd7726e8cab89f4 didn't quite help. >> (I've tested it with dbl_and_ull_via_async that Mark shared in >> another thread.) >> The root cause is located in vfp_save_state. It's called during the >> dump, right before the assert is triggered: >> >> 359         /* >> 360          * savectx() will be called on panic with dumppcb as an >> argument, >> 361          * dumppcb doesn't have pcb_vfpsaved set, so set it to save >> 362          * the VFP registers. >> 363          */ >> 364         if (pcb->pcb_vfpsaved == NULL) >> 365                 pcb->pcb_vfpsaved = &pcb->pcb_vfpstate; >> >> Here pcb_vfpsaved == NULL, since the VFP has never been used in the >> kernel. >> This triggers the KASSERT in get_vfpcontext, causing the panic. >> Note that arm64 has very similar logic, so I wonder if a similar >> panic could be observed there. >> Any thoughts? >> > > It looks like cpu_copy_thread is missing setting pcb_vfpsaved so is > likely to be invalid. > > On arm64 we set the needed data in vfp_new_thread. This was added to > simplify adding SVE support, but could be reused on arm if it’s useful. Thanks, that's it! With some changes in cpu_copy_thread the assert is no longer triggered. I'll do some more testing, cleanup and will post the patch to phabricator. > > Andrew > --------------XrbroFEUeTXKeUEnFtS0aYSO Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 2/20/23 14:32, Andrew Turner wrote:



On 20 Feb 2023, at 13:15, Kornel Dulęba <kd@FreeBSD.org> wrote:

Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There were conditional branch instructions that may mean the function to save the VFP state was not being run.

I'm currently debugging this and applying 24abb6b82102eec577eff9bd8dd7726e8cab89f4 didn't quite help.
(I've tested it with dbl_and_ull_via_async that Mark shared in another thread.)
The root cause is located in vfp_save_state. It's called during the dump, right before the assert is triggered:

359         /*
360          * savectx() will be called on panic with dumppcb as an argument,
361          * dumppcb doesn't have pcb_vfpsaved set, so set it to save
362          * the VFP registers.
363          */
364         if (pcb->pcb_vfpsaved == NULL)
365                 pcb->pcb_vfpsaved = &pcb->pcb_vfpstate;

Here pcb_vfpsaved == NULL, since the VFP has never been used in the kernel.
This triggers the KASSERT in get_vfpcontext, causing the panic.
Note that arm64 has very similar logic, so I wonder if a similar panic could be observed there.
Any thoughts?


It looks like cpu_copy_thread is missing setting pcb_vfpsaved so is likely to be invalid.

On arm64 we set the needed data in vfp_new_thread. This was added to simplify adding SVE support, but could be reused on arm if it’s useful.
Thanks, that's it!
With some changes in cpu_copy_thread the assert is no longer triggered.
I'll do some more testing, cleanup and will post the patch to phabricator.

Andrew

--------------XrbroFEUeTXKeUEnFtS0aYSO-- From nobody Mon Feb 20 15:17:04 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 4PL5cc678Vz3sx9f for ; Mon, 20 Feb 2023 15:17:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PL5cc3ztmz41ZR for ; Mon, 20 Feb 2023 15:17:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676906224; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T02R9RY1EMRW7cHOtcvtENHPIKj2YDUOlbNcLuVbq4M=; b=cipMRcMDInAm728HwpYvsjadew/PfamPJtUP94nMf8Z6lYfNNMHkVs9pt4VyrHN/siyWrM FLNKKvEX/SpMXx7CHZTPqmPhOb2q4TOlyYHeWhH4Wbn/1Md9lwS17G44kJq/jCAOJhaavU 3Jr0kg1Oum+2Ftf/v75v8QLhDSSai+W0B4emnCpkZ3Uy/jBfYds1YL6EGtHW/+9z+X0nR9 wsYUhwJO5yDUTgkB2eFZdXXytmV06U1IeJls75Ai7I4OQNOP7HJRw0NCV2yOj6NkAQQwK4 g5qVUhhU4hh6eEefk31lZOhSrr3umhUtK1ev2c2sEaupslwGCBnSrcN6qQyZFQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676906224; a=rsa-sha256; cv=none; b=wlQmepKm3qAsyA0pIy+j6w43/gFXXANcT2NrW/IGt0JoNsFay2Ud+7lQQdcKGb6HAcWrNE OSWiRXow5JZZXnjDb6eLYI2i+pUkOq/mBkx4IgSmlsQXVE65f3Zc8/QFhG4Z7gKE5tKL9S k1hrPqfLUeldEZjBHcNyXV1Tx3ejuIbRxh1HFWD0NerTIPkPWJ+81dPzvpQWKozdtrFDgD r3UoeB30sXzzp35Hokf3eaYavG42AoAkbwGbVrObcUxQ6JTqo96KiQrz30j8edp+ubZpbc wbl9758uDO25q0LIsAeXWH7Q3vevypt58r8lz1SO0Lt4xs1stBjed0czqT66tw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4PL5cc34VVzlmC for ; Mon, 20 Feb 2023 15:17:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 31KFH425031445 for ; Mon, 20 Feb 2023 15:17:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 31KFH4EL031444 for freebsd-arm@FreeBSD.org; Mon, 20 Feb 2023 15:17:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 264588] [panic] panic: data abort with spinlock held on arm64 ampere altra under kvm in OCI Date: Mon, 20 Feb 2023 15:17:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dch@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264588 Dave Cottlehuber changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Feb 20 17:07:27 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 4PL83V2dTxz3t4YD for ; Mon, 20 Feb 2023 17:07:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PL83T65VQz4Hjp for ; Mon, 20 Feb 2023 17:07:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 31KH7Ret063369 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Feb 2023 09:07:28 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31KH7Rrv063368; Mon, 20 Feb 2023 09:07:27 -0800 (PST) (envelope-from fbsd) Date: Mon, 20 Feb 2023 09:07:27 -0800 From: bob prohaska To: John F Carr Cc: Mark Millard , "freebsd-arm@freebsd.org" Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230220170727.GC57936@www.zefox.net> References: <202302192054.31JKsq7w079295@chez.mckusick.com> <3DD8EEC2-6135-42A0-A80C-F195CAAC025E@yahoo.com> <20230219222328.GA55941@www.zefox.net> <2F5B20E9-AFF8-42F6-9E1F-50BBDF4E1B79@yahoo.com> <20230220044544.GB57936@www.zefox.net> <9CEF4E7A-2F13-454F-A04A-A6C5A80FD4B7@yahoo.com> <268392B4-58FE-49EE-9B1D-6DA632757DFA@yahoo.com> <1DB17CD4-63B5-4FA2-ADC6-6ED817A09CCB@mit.edu> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1DB17CD4-63B5-4FA2-ADC6-6ED817A09CCB@mit.edu> X-Rspamd-Queue-Id: 4PL83T65VQz4Hjp X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Feb 20, 2023 at 11:47:30AM +0000, John F Carr wrote: > > But we have an address from the SCSI command: READ(10). CDB: 28 00 43 29 d6 40 00 00 40 00 > > Decoded that says read, starting block 0x4329d640, length 0x40 blocks. If block size is 512 bytes that is about half a terabyte into the disk. > > This shell command should replicate the read: > > # dd if=/dev/da0 of=/dev/null bs=32768 count=1 skip=17606489 > > The device name (if=) comes from the error message "da0:umass-sim0:0:0:0". The block size (bs=) matches the read request in the failed SCSI command. The skip count is 0x4329d640 (disk block) / 64 (number of disk blocks per dd block). > > If you reproduce the error with dd you can try a binary search over the 64 block range until you find the block that failed. > I can't reproduce the error using dd: root@pelorus:/usr/ports/sysutils/smartmontools # dd if=/dev/da0 of=/dev/null bs=32768 count=1 skip=17606489 1+0 records in 1+0 records out 32768 bytes transferred in 0.004245 secs (7719010 bytes/sec) root@pelorus:/usr/ports/sysutils/smartmontools # dd if=/dev/da0 of=/dev/null bs=32768 count=1 skip=17606489 1+0 records in 1+0 records out 32768 bytes transferred in 0.004151 secs (7893526 bytes/sec) root@pelorus:/usr/ports/sysutils/smartmontools # dd if=/dev/da0 of=/dev/null bs=32768 count=1 skip=17606489 1+0 records in 1+0 records out 32768 bytes transferred in 0.004139 secs (7917764 bytes/sec) root@pelorus:/usr/ports/sysutils/smartmontools # dd if=/dev/da0 of=/dev/null bs=32768 count=1 skip=17606489 1+0 records in 1+0 records out 32768 bytes transferred in 0.004070 secs (8052034 bytes/sec) root@pelorus:/usr/ports/sysutils/smartmontools # dd if=/dev/da0 of=/dev/null bs=32768 count=1 skip=17606489 1+0 records in 1+0 records out 32768 bytes transferred in 0.004032 secs (8126081 bytes/sec) root@pelorus:/usr/ports/sysutils/smartmontools # Not a peep from the console either. This is a $50 disk from Amazon, so Mark's skepticism isn't entirely unwarranted. Trying the SMART self tests is a bit confusing: root@pelorus:/usr/ports/sysutils/smartmontools # smartctl -t short /dev/da0 smartctl 7.3 2022-02-28 r5338 [FreeBSD 13.2-PRERELEASE arm64] (local build) Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === Sending command: "Execute SMART Short self-test routine immediately in off-line mode". [I didn't ask for an off-line test] Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful. Testing has begun. Please wait 1 minutes for test to complete. Test will complete after Mon Feb 20 08:39:21 2023 PST Use smartctl -X to abort test. root@pelorus:/usr/ports/sysutils/smartmontools # The shell prompt returned immediately, and smartctl -a indicates "Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run." A long test asks me to wait 166 minutes, also returning a prmpt immediately. There's no activity on the disk LED, but since the tests are internal maybe that's normal. I expected some sort of complaint that the test couldn't be done on a mounted and booted disk, but we'll see. For the moment I'm skeptical any testing is being done, as there's no audible activity from the disk. I'll move the disk to another Pi later today unless better ideas emerge from this discussion. Thanks for writing! bob prohaska From nobody Mon Feb 20 17:08:48 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 4PL85x4xCJz3t4ny for ; Mon, 20 Feb 2023 17:09:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 4PL85x291mz4J0Q for ; Mon, 20 Feb 2023 17:09:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676912947; bh=8cEOiC5piBt9tUy8KPwxKmyxCLEI7PQU44zkfKxOt2A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qwNqaL4PIp6Ufy20gDAUuEclzWzGLc9N7M5Apmknq/S7uNfB1vLWGeIwdJHEWWR69bIYBpmwbis6X9lJ+XctMO28zZ4ugXmwhMAaSoL0MXO2pW+JtGzWMU3ubwcuT4CY2pNm4uMaBDtoEiOI3Zo0Q2q3tSja3eRW90QrsOH3jh2SN0DzhHBUQx6AOyGILQXCsH+k8cQ5AYWIrAUv0HOBp7bbYEnbkQcQW7W8xkSa/cAPqRm3inQJcIT7qgfU3fD/GF2Hjh5vhJou9q+aEZ5YeNe43VlhthEWrR8ZMNsN+91aRvHRqhNtTE8kV8Q1cn9brDibDyDy36CeDyntEVKAag== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676912947; bh=l94LSpvUiuVOoz8VlCDImMHQlJ1t6RO3ZvyfzdE2d8Q=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=smaPrGr5Ib2BOT3hsICbpdp6prJQ+q4WhE8kO/KCxyaJzEsj75052v3FXgwtEHNhnnyXoNjo7AuUlYgXfg1Ise6RzQC1D40nbQYnyKfy0TA2UzobEg4EP7mB21MSnEkOfboYzf/nTDi35MfTzW4qPOLNfGVQL26wy01ylEn1BQjGCUaGiZb9UM9CjlTVcwK0eHIdKH2piD30ndhjNo/5LrLq6QsTOhL7Di4FCv1MilwMM4yJJ6PaKhEeuNKuzQh5x2o0WNLB6kl29t8NLEc2fB+OkXIg8UHyZ64+aQAyUCksWXMq9JaZa7wgkkDwjCby5HQfYtE/1dTdSq6R0OIbNQ== X-YMail-OSG: FRkKkMIVM1kSU3gBUQApNnWVicDrRXgozO_Re.7XD.ku6cloUkzh0g7qsiqmdVA uL0yzRmty1pyTCpH0_7w9gULGxb7fBa1.iygPH26WR.zgiYFBYlqQkXCIWbuNjXu4PtbDglrmE_Z fPAryyA29NW5OkLUokEHSQpzPw_mNnWO163hSfLMLn1.sm3pvJVXKny_bxWOc3Qav915b8vzAEcK 3YNyleiX8n_zpGMkoc.vtetTlCHWgyCVUgffisdg0LYD0Ne5LRduoQdZLsFuSFXIKiOEpq_X7XHP Lz0S8U6KXkSA.tcTJTUmE6jWWFyYShhkk88O3WdHUP9zIY8i8D2y3fm5PC77vNH7AR61MGvNQLXJ JOnQIMcQXvMTn_N0xfgvQqRHKxYg5vm0ObsAQqVYK._rJBnBiN3o_ojX9azvG_OmcnR1KGbdwLYv ycqd_HA7ZlBONfF_PiOCN83WxGnr8FuHFfCIcmfR1SuEf1Fc30sc7u9wF7XfsS9eVdN6bRbRn9TN EJp3x94u1StIjLuh8bAKLxZ8fs9grsikSAhoercXMfgnwbhAi4MLsbpe2iV._Tpw72DT374V4oMj LLE2KeJHwf.oZLFh44Hshyrc08OIpAs3auSRWnBUKvho8cERCLAKLaj2LrIfIuZQaRWLggB10L9q hf7lKM7Bp_8iUjRG12iIVD34mCQVXgl7LAvV4RnLBFaQ5bMYXJgzdUWAvxybsJM_CPpArLbswe2s kYgpaALNDWIA9lCM9R_JLEKFWaOLnErUTred1Bj6dXDoThNLJGM8HAGiMWGmL1tOx6n15ufGYMJS u4xqUyZoD7jPQeTkq.I19V7Y4.FJ_Baqm3kzxsawdn9FDQGUzBsKFKMuJZRZx__H8HGwnmtmp_PE obrU2MWe2inLYtIGdvrfzOi7EvI10rex6Fiiz0eVB1xLXNYzpgKmUdrIzlrRX_vjBfAiAf2wbo8a _excgTjAsWaUCt9SSS9B8ifqsDSnwBHNoL0B4iXICjNSoZ8AMrdI48TL0pJexkmADrzGokyqyK2B wc.6FQty.9fEFt9hMc1mzAx2bT4oFwjsIh_4XUyckuqSpBIsynf6zRTdCdhmZO7rAcBbm7luS.qd 0GT1bSZeUllnjdjYi4f5UpHPDGO4lbnHDGYXhBvWJ_B35ZKXh6B79tGMnViAfmX6uG3vQL55Er6t sxgTf2jHXqG6ND1DzNEp1rBGYGNUmYhucXJ53lvqMA4Z9Zfm91NUm9degfgD2w.1qDqouKvfOJ_J z8pnZiAux52pkPHbW7VhBD8Dj.EAPKVrkYv2XBNzRG_cc8Xkb0R7VbruRGE6TIthpnph4Dv3sLar 0Bl9AORjwaH_O.7rw6XFJeHE6gQcJ_gBFga471m2z4U2JPcH3rNGEL2P2WASoi8nPoP3VA40Gw2y xogMFfqWBusJ6TF87vEnYbKeTWfp06v88a51HRyZ8YmVH7WNi0dM4U2ZfLnquxIHn2x.VN_aZN2O sCJwM_h6gcDXG9kScmZM6ZSfu9I6lRyji38D2u9hZEQLpWkXacp4zCWgQBaimxrKPWnFaWbRmRq0 NV.etMQRZayc_aBo9WsgfbfPFHxuN8wGMuntgjHKdWuX6MA4Xnhlx6y.qvD7US1f.RCyVzNFp6X9 AF36c.8wAqtFliAdMjTjaVb6vCHXH0IRLb_sIHE645LT9Ntog.SW9xdQAePeCVFh0OmtQ1l7CzEE yAN2CXmHghhnaQQIlxAfU4PpjoF2EZUaDVZDYdLO8h.8OUZjxHZ52FaviKnPc0Uref3So8al0eDW 5LRpwlsxEHiFZ8uIfOu74Qr.76HPpZuJukjGK1nGHDqsrQAC.eocFaGzpdgXu12cPKFN2W31KQoL MKimCcQjzlZhXsy2A_L2X4ItamSdd55421msjcyPXHxhE4FJ9ewOvm4b.ifFCmSz0RmI0hjcMTBo WOV_A9nWA2lzgmC8Mtx0_kTPRjgPC4ci4nM6BhEcGYOulli6.BkCYGRZ_QvRqoxHV59qfSQFM_4k ULW6YCY14B1hfq5e4mQw1SLtIVEJ5PVCokM1IidjpxtmYeCzQTF_ugePil48Nn0_Yvc7zHOBt7P0 fO4WEuAzqt91yA1bZT5Gi.Y3Bn5zev0mnimlUaWYjRLWMYZIzEablGPQU2i_y4CBUPgejoyNy.Hr 8G0gd4rIUBXer8mN8rWoYRcyKKqcka7s6kjuqX9q_T9ch9fj06gFUfF5C6VVg_6RkMWOrsBRk9ee 4qy3WpcgYWg_mAq3xExw6AVvkvn5Gf2dSJIrPJcfdkTdKNQ1nVNaeb9XgKHNWUiwWXwf3v1kboEQ - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 20 Feb 2023 17:09:07 +0000 Received: by hermes--production-bf1-57c96c66f6-9h4hj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3e10ee2036cc27284988ce638fdf495c; Mon, 20 Feb 2023 17:09:00 +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 \(3731.400.51.1.1\)) Subject: Re: Armv7 panic on -current, rpi2 buildworld From: Mark Millard In-Reply-To: Date: Mon, 20 Feb 2023 09:08:48 -0800 Cc: =?utf-8?Q?Kornel_Dul=C4=99ba?= , bob prohaska , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <71350653-9B4B-4570-A2E4-06CF25A66923@yahoo.com> References: <20230215025741.GA32086@www.zefox.net> To: Andrew Turner X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PL85x291mz4J0Q X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 20, 2023, at 04:32, Andrew Turner wrote: > Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There were = conditional branch instructions that may mean the function to save the = VFP state was not being run. >=20 > Andrew I had eventually produced 3 programs showing different failed results, 2 KASSERT panics and one example of floating point data from the wrong thread eventually showing up (but no KASSERT for the test sequence). I've tested the later one via an armv7 kernel that has: c0681a2c : c0681a2c: e92d4000 stmdb sp!, {lr} c0681a30: e24dd004 sub sp, sp, #4 c0681a34: e2803000 add r3, r0, #0 c0681a38: e883fff0 stm r3, {r4, r5, r6, r7, r8, r9, r10, r11, = r12, sp, lr, pc} c0681a3c: e1a01000 mov r1, r0 c0681a40: e3a00000 mov r0, #0 c0681a44: eb000b10 bl 0xc068468c @ imm =3D = #11328 c0681a48: e28dd004 add sp, sp, #4 c0681a4c: e8bd8000 ldm sp!, {pc} and it still fails: # g++12 -std=3Dc++20 -pedantic -g -O3 -pthread = -Wl,-rpath=3D/usr/local/lib/gcc12 dbl_and_ull_multithread.cpp # ./a.out Thread 1: 23618687.000000 !=3D 4503599659991211 ^C The left hand side for Thread 1 should have had the huge value too. Thread 0 has the smaller floating point/unsigned long long values (that should be mathematically equal in the thread at the point that they are tested). The two threads are independent of each other but are doing the same type of loop --over different numeric ranges. So it looks like "necessary but not suffient" for that test. (I'll leave the code change in place, as I doubt that it is wrong.) Given Kornel D.'s already existing notes, I did not expect either KASSERT failure to be fixed by just this "fixed to be bl" change. (This test was done as part of my already started multi-system environment upgrade sequence from 1400079 based to 1400081 based after a tmpfs fix. So I patched the kernel source that I'd already synchronized the source tree to [somewhat older from yesterday].) FYI: my current source for dbl_and_ull_multithread.cpp looks like the below (whitespace details need not be preserved). llvm15 is still missing std::osyncstream so it is libstdc++ based (and, so, g++ based). // # g++12 -std=3Dc++20 -pedantic -g -O3 -pthread = -Wl,-rpath=3D/usr/local/lib/gcc12 dbl_and_ull_multithread.cpp // # ./a.out // Thread [01]: double_value !=3D unsigned_long_long_value=20 // Use control-C to stop it. #include // std::numeric_limits #include // std::future, std::async, std::launch::async #include // std::to_string #include // std::osyncstream #include // std::cout int main(void) { static_assert(std::numeric_limits::radix=3D=3D2,"double's = radix is not 2 and is unhandled"); constexpr unsigned int ull_width { std::numeric_limits::digits }; constexpr unsigned int dbl_width { = std::numeric_limits::digits }; constexpr unsigned int use_width { (dbl_width; Mon, 20 Feb 2023 23:21:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 4PLJMd259Cz3xkd for ; Mon, 20 Feb 2023 23:21:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Pk6+WiHl; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.206 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=1676935290; bh=4IsbFcB9DkY0rEVstti2KKtRz9Qjqy4cVhzPDAj6DuY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Pk6+WiHlGPZfeqXMLUwmS2CcltHAJcSn6znI+FX/gVO6g4kWN3o8aj97x2/o5D9PzLKnOwfhtHXLtx/vQUPnyGI9/INbrHyGVM4+qcaxFK7ulTujNbwVRYuIUU+Gi94eTs++rqGcFXyCaXucWtxFgNfO1jXTpqImsLONHz251pRlOdFUwDLf8W7PKU98o/SydFCRSmaeW3u2cvxz1OLjKv0ome5aGFIEjiVI44dF/9Q+svsbga/3BmnU/RUwdwSNPxcjaXU6/g9ofw+okYlLSwDS3vwkQukvsbKaBNx7G9pCvAuVdHsLh4pCoAWz9AO8yOhLCFLSydXO37pgqbvf/Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676935290; bh=cZSN+3zx2L8VqCYqQ4a1uMg34v5BUX5z13TZJZOu6u+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cuXSknebNsQENO7yKqARnC5BAWvWjQncEivYy+r3QXQAKjLaMv2GBuoEcFXoiAhsCQevzMZ7gzw+eNCnwWbfzKbV4SVJbEcVc7L5T7tNDocmOGAbAnb3swaFTvwpdxWJNGEIX+/0mArMs44LMRYUYt1cgCZbBVWZVIv/wP9nW4/vXeS9ilgafi/eeNjtk9JcBKBrOQOUx/KP2mfxP+X7TAn/6uPEVZQ34TJAO0x8gAQWcoxx7Ol4JOO+TfYEEzG8TI+Uv+FBrPtm7IKc3BUtcPOgL9j+lK+eTYMugxE8HFmofBr7m0u889yBNdSvaCpeX7l6/EsrOEbeCvmvbQrckA== X-YMail-OSG: GeWix9kVM1l95oj1oLRK78HZTCnWIECme0vY3CCEvT_fBznZ1PS6aoC33l9Z1vt k2lv6w5q.wPOnmVWvPLpkfpBrkX4a1p7lWxCfbfI1wl5pvY6Db.BcDA75TROy6eIyjPQGjKeQ6we kZfKHNlIGWFmTreyN6B67NPNGqZUV7y_w1xDhTYoe9cLhSOXLlsF_9f4mSOZ.HhTcimBL4iKDuP3 udgnVo4Isu5E1hGpGR3w.eaJU2dQ1xRehX8M5sH1CHTt8p5lJ01BXpXgozS1WX5wnkBHgpeMRfMK xLTEcH4js2eEZ8mQ46umxTdItFh0J83HVOPHygr_A_gW6DW.fhV362NpntH_nkux1WT6fmZv6INU UotaNZOtefUoxLL8lHFO75FD2wlZOvgmqfSYHdXOYaP3g4zTtqcQtGLrRgpWSqJJrRM.j8dcNdRG qwD0Zs0NOb272lnTW1bqU2zQ22bwnKfDepwLs6vXLOwFI6.glwXaTLfNv96PT3IHzzcAGsKMuKaq ARbJTxvUY1nhKaYQbkydF1Jjdgzw_TnfncW5zLYc72eMZS2_2JQI16VYf3Xpvjh2Oak3J0zI3O7F 5qqq7HFLVptdBOqcS.em0g9uiCk9UR_UZk.mDw8vORRfQAcoU2Pw9EYkuU8KhxqecZXH2EHR0ae. 0PYcXjiF5A66DmovRP822.okaHbYsfuWhtKD_UFu.bfDsyeWO8mKeFs20yITyEZVfk.tVsaYDXlS gT4ieTLSpFpjnTLGix0xOnAPcdvetsXl39kjZkFiuzGo2VN_SoN5ruKWWGNfG8R2zVup56r0VXjd 2r_FRg7KcMuJG.W44zTiYssQLuy4uVEvRvZRjK8KeA3EIQGpV0a5G6FNb5d96G4mNtgg7lUz7hzS R83insc4JYbvmKew9Pumc5hx9RmizkN0bAk1sNhJ_sKCLB.FqwRu28AXcsKjLNg5cGod0GtjpX1f ik5TIZSYNtwbL5FosqIad3UyjScjBhd9eECJwfE6UXSn21vqJOaOA2Nn3EQVnnYNmd6jf970bzjv 7ydKS5wTtXgFPL1D5EOSRZ3VzrAJEAAF99IpZopYFG6.R5TUGW3PmZXUcY7.LF2Rh20eDExxwpPl Z4ETXgHoYzyaEAVGba0QpMUTmR7q6AtoRRSMtFpvfsalozB6VcmhidpU5R0XKNRpk.Sx1OTRSpj9 CcqIsyXK1TDSjuceXa_4cWNnXdW8qZF9sYrzuiQBki69fBrx0ZDhtjso3E9tvAfb0RBOLX2AUIBt hMIGV701YykSdR3mkl2QiUsj4uA3Z_g927T.Q3_PXNnAqKIByCSyd1ulATtx1NlhJrj9TloktdUS x9RYLyeBgmLiw58HYgBHNnhOietQcH7LteovePhvab5Zi41LyojxWUZ7OcFENfNDPmswXSJ.fjeX 85LeAvekLWoKs.Enrq6CuDu6RiK0wipVUu.m_wPAKUeP8kPoj_Wh2oYvVEr3WmdutA3eoKUqG84J d86s8AJ.QRIUFgtFaMfqB_A5l844NS38SAzNvlFGc1ouj.6NNAYu4XR5qcWQXRbIhyziIhktZD1f lUajQIlRIB0XbKAdDscm_gTMZhvL65eb34grV7bNXmjgIt5qzl7hvT74RLp8H9mCneeQLRbIbEUX JXBTp8SZ_iLBf2obbY3umf4Q6glB.8cT1HiqPoarOpcuE1yO_7x_TZmh_Xft8fYbCjuy.ZdUM9Z9 F0FnknjSIpBUYNSDg8Sqmbx6gF42.Hy6tKLW4s8hq0QeUXMb5doaqf7nbGnyxGt2a1gezJsD0.vp pXR00gd3dn0rZYSqqU9MXmMK7gUrKOggngZoI35KrRi3rf.c.KanfcIJFzQhgNEFz6VdXHEeJNkP Ztx0ulTBXpcRotfK28Fxj2NEKE2B8L5kIVqrcN2du7XdFUkyYMlIZH1_xc0UWvw5Xarz89sYro.6 Upi3gW7VD5xJAqI3C7IJmSA8LoQcFO.5A74ipBxFOf7onaRpujDylpoeQT6F56XDMSYzg8j6Rr_g mwcWZthx8uX2M_l1Sk1jD2EHI1n_.2P3hDtm3mDfH19IY7QmEhOiL9FtDgVlSQrmYubwY3A6sFGm 2qDo._wemIXaM5TWqMM1ZgZcXYTVTvbrnK9CzLbZsBMd1zmhbsWlSFkZZiQJS9CcRKfWISVMGogF _ngzgCcUhMs6O21dtEXW1OfeM72RuTLhG6EhwKnBvq6sn_vPKvkZ_wQKQ.pgxhD.9r3.QmxK6jSd hirlMm2Xbo2yrcyOAqYKxiUlEvs80J72APsNneeGTl6yRHLwDyQDF_QPBfXclwAdaetyS3X0Xqh0 u8A-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 20 Feb 2023 23:21:30 +0000 Received: by hermes--production-gq1-655ddccc9-l45xf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 25d2183bf91763f4c566eaf083f3af30; Mon, 20 Feb 2023 23:21:26 +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 \(3731.400.51.1.1\)) Subject: Re: Armv7 panic on -current, rpi2 buildworld From: Mark Millard In-Reply-To: <71350653-9B4B-4570-A2E4-06CF25A66923@yahoo.com> Date: Mon, 20 Feb 2023 15:21:15 -0800 Cc: =?utf-8?Q?Kornel_Dul=C4=99ba?= , bob prohaska , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <61F904C8-5F01-4E55-B93F-84A569539F43@yahoo.com> References: <20230215025741.GA32086@www.zefox.net> <71350653-9B4B-4570-A2E4-06CF25A66923@yahoo.com> To: Andrew Turner X-Mailer: Apple Mail (2.3731.400.51.1.1) 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)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.206:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.206:from] X-Rspamd-Queue-Id: 4PLJMd259Cz3xkd X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Feb 20, 2023, at 09:08, Mark Millard wrote: > On Feb 20, 2023, at 04:32, Andrew Turner wrote: >=20 >> Can you try with 24abb6b82102eec577eff9bd8dd7726e8cab89f4? There were = conditional branch instructions that may mean the function to save the = VFP state was not being run. >>=20 >> Andrew >=20 > I had eventually produced 3 programs showing different failed > results, 2 KASSERT panics and one example of floating point > data from the wrong thread eventually showing up (but no > KASSERT for the test sequence). >=20 > I've tested the later one via an armv7 kernel that > has: >=20 > c0681a2c : > c0681a2c: e92d4000 stmdb sp!, {lr} > c0681a30: e24dd004 sub sp, sp, #4 > c0681a34: e2803000 add r3, r0, #0 > c0681a38: e883fff0 stm r3, {r4, r5, r6, r7, r8, r9, r10, r11, = r12, sp, lr, pc} > c0681a3c: e1a01000 mov r1, r0 > c0681a40: e3a00000 mov r0, #0 > c0681a44: eb000b10 bl 0xc068468c @ imm =3D = #11328 > c0681a48: e28dd004 add sp, sp, #4 > c0681a4c: e8bd8000 ldm sp!, {pc} >=20 > and it still fails: >=20 > # g++12 -std=3Dc++20 -pedantic -g -O3 -pthread = -Wl,-rpath=3D/usr/local/lib/gcc12 dbl_and_ull_multithread.cpp > # ./a.out > Thread 1: 23618687.000000 !=3D 4503599659991211 > ^C >=20 > The left hand side for Thread 1 should have had the huge value > too. Thread 0 has the smaller floating point/unsigned long long > values (that should be mathematically equal in the thread at > the point that they are tested). The two threads are independent > of each other but are doing the same type of loop --over > different numeric ranges. >=20 > So it looks like "necessary but not suffient" for that > test. (I'll leave the code change in place, as I doubt that > it is wrong.) >=20 > Given Kornel D.'s already existing notes, I did not expect > either KASSERT failure to be fixed by just this "fixed to be bl" > change. >=20 > (This test was done as part of my already started multi-system > environment upgrade sequence from 1400079 based to 1400081 based > after a tmpfs fix. So I patched the kernel source that I'd > already synchronized the source tree to [somewhat older from > yesterday].) >=20 > . . . >=20 With the savectx blne -> bl change, D38696.diff, and D38698.diff all = applied, all the activities with all 3 of my small example programs for the armv7 = floating point related problems look to be working just fine: no KASSERT's ( = simple_dbl.c and dbl_and_ull_via_async.cpp activities) and no odd values showing up = in a thread ( dbl_and_ull_multithread.cpp runs for minutes at a time). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Feb 21 00:38:51 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 4PLL4q6mPcz3sjSV for ; Tue, 21 Feb 2023 00:38:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PLL4q5XK6z46Tq for ; Tue, 21 Feb 2023 00:38:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676939931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=rddVxZ7XAh+NoEqZGYgwXiQOj+UI9n7ynTbpOyxiqkY=; b=lRm4OWdUumNjs2L9r0CMpU7HbgnNdfRCsSwuX7vF3+UUzIh0YHvMqITWs2XEJN/W4GIEna BeoYYlYAbuVKV3E3sEuEVSxxjNxkDRVGin8STDnesDqL1sazppJC4tu5hqNPGuf7l2yw8l 6OMzm6c1zkvMvzhMW9C4EmomJaMTYXo2ZJhsGajaFacMArO1lCdZ0Ki+c6un3NuZI+diIs DGqvzVLWaAc7yZ+zLfq4ZmPW650E2x7EKMVHD+YaS8m9HnkZYcGL+16ZAUkhix83KBwWYF fm4FlMQq+AzX7mgaB4vbUhi3yycA8MtCQbReZjO7Y8lbdkMRIIPhKP11E1fl7Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676939931; a=rsa-sha256; cv=none; b=oeqJq6qO5kBAfeGx3ZjlhE8K89I0sp5ezqySm4mDfHx02OT7xcCWEbgQ6VMHBmE2XxGR6n bq6VwOgn4Ai/0qRRW9nFk6boeCmhWqkzX6JTmTyfuFWn6HVnFpqmLLSMqyovLbT5Kl7iTR Bl9ZFLRv6vn0QFCu9iISHONBPE31V5o2dwqXtKkGfauP7A6Yrgeh1dYUO0o+koq8Vn9uPi l7BvMetqlp8jJyenkyTSjv7ujMr5m+OsRCLjIcpPowK+qUVWvV0eKtzuaUtSYOLtO2LTUq wtT0+278doFgHiyvjaUrwvJvntHHr+axkNqFka8u9YPCiL5BmBGovpG10ZsA6g== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4PLL4q4W52z11c7 for ; Tue, 21 Feb 2023 00:38:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 31L0cpXb036085 for ; Tue, 21 Feb 2023 00:38:51 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 31L0cpJu036084 for freebsd-arm@FreeBSD.org; Tue, 21 Feb 2023 00:38:51 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 269726] kern.msgbufsize=4587520 in loader.conf, kernel never boots Date: Tue, 21 Feb 2023 00:38:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269726 Bug ID: 269726 Summary: kern.msgbufsize=3D4587520 in loader.conf, kernel never boots Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: bz@FreeBSD.org CC: Andrew@FreeBSD.org, imp@FreeBSD.org Hi, set kern.msgbufsize=3D4587520 in loader.conf on an arm64 system with 16G of= RAM and after boot -v no kernel ever showed up. This is loader.efi from a few weeks ago I assume. I can dig into anything = if needed. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Feb 22 20:48:43 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 4PMStN2Tnvz3sBYB for ; Wed, 22 Feb 2023 20:48:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PMStM6fKjz3JRk for ; Wed, 22 Feb 2023 20:48:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677098923; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=DTnVm+WZVND62VkbVLy9lKQpzBqRrAyW+lfgHdtNW2Y=; b=gtqEatOSOy14SB/AYEaiWTDVQhxleMAqA+R7NVbA7V1+n59lgsJix+LAUU0XmvUy1sLyl8 01MIIx/ypG0/SnvBb1tDS6Dj7qCJjYcvOsvYH03WmwcYf0SoHp6We8xYaiIN3i/OFrbYXM 8dRP7nMcaBkg12+zbiBFnE7suHLB/YyyJ9HCFklMd9YZwFa/889mnGe8vEYd9nDQIDgiQy UslW3g1FXXniokpGVkw559qUicCLKAwCfbwO3ONuOqUD3lhZ/yJmtilRKhSAgAuEAwADYk 951c4CHONCgBvUJdskxYSgc1Ggf08WAXtOIUquw70J7vhS1Mg0QxIMxmQFg+lA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1677098923; a=rsa-sha256; cv=none; b=ixeRH1r4UCy5Kq/q6YArGkNlIUP0msk30r3X1hD/+22RjKK5fGkV8/QCQhzasBPqjlMph7 d3AySjeQijgAKbKgm8+BMgjR7Os9OWu26XBr2b2dfMYsktVjJTD0YhLCnRTevoMF/G0uXV /BXNpP0hwgVua4gmCbFJ5i+WUNWiQOZPh9LUN4o+/tCK4EYdpWBvARG6IJPlRQmAHIoOw3 R6EuT6nggFLZOUJCHdZj0XFCM3YT3pz/l6rEmITbGu4tsYeS29JlWT+7pJMZWnb3Dpfpwz Pb0YxgT9pqXKvdsPhd38tu61sjchDdfIfxuc8YhDdxBX7riSGwo1S02eEnY44A== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4PMStM5PbWzG8s for ; Wed, 22 Feb 2023 20:48:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 31MKmhXG013671 for ; Wed, 22 Feb 2023 20:48:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 31MKmhNN013670 for freebsd-arm@FreeBSD.org; Wed, 22 Feb 2023 20:48:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 269763] 13.2-BETA armv7 build fails in drm_vm (on TEGRA124) Date: Wed, 22 Feb 2023 20:48:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: freebsd@igalic.co X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269763 Bug ID: 269763 Summary: 13.2-BETA armv7 build fails in drm_vm (on TEGRA124) Product: Base System Version: 13.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: freebsd@igalic.co I don't know if TEGRA124 is still a supported KERNCONF, but for 13.2 BETA it currently fails to build: Building /usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys/TEGRA124/d= rm_vm.o --- drm_sysctl.o --- /poudriere/jails/132-release-armv7/usr/src/sys/dev/drm2/drm_sysctl.c:81:47: error: too many arguments provided to function-like macro invocation SYSCTL_FOREACH(oid, SYSCTL_CHILDREN(drioid), oid_link) { ^ /poudriere/jails/132-release-armv7/usr/src/sys/sys/sysctl.h:908:9: note: ma= cro 'SYSCTL_FOREACH' defined here #define SYSCTL_FOREACH(oidp, list) \ ^ /poudriere/jails/132-release-armv7/usr/src/sys/dev/drm2/drm_sysctl.c:81:2: error: use of undeclared identifier 'SYSCTL_FOREACH' SYSCTL_FOREACH(oid, SYSCTL_CHILDREN(drioid), oid_link) { ^ 2 errors generated. *** [drm_sysctl.o] Error code 1 make[2]: stopped in /usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys/TEGRA124 .ERROR_TARGET=3D'drm_sysctl.o' .ERROR_META_FILE=3D'/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.= armv7/sys/TEGRA124/drm_sysctl.o.meta' .MAKE.LEVEL=3D'2' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes ve= rbose curdirOk=3Dyes' _ERROR_CMD=3D'cc -target armv7-gnueabihf-freebsd13.2 --sysroot=3D/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp -B/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/usr/bin = -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/poudriere/jails/132-release-armv7/usr/src/sys -I/poudriere/jails/132-release-armv7/usr/src/sys/contrib/ck/include -I/poudriere/jails/132-release-armv7/usr/src/sys/contrib/libfdt -I/poudriere/jails/132-release-armv7/usr/src/sys/contrib/device-tree/include -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common=20= =20 -march=3Darmv7a -DLINUX_DTS_VERSION=3D\""5.9"\" -funwind-tables -fdebug-prefix-map=3D./machine=3D/poudriere/jails/132-release-armv7/usr/src= /sys/arm/include -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=3Dtautological-compare -Wno-error=3Dempty-body -Wno-error=3Dparentheses-equality -Wno-error=3Dunused-function -Wno-error=3Dpointer-sign -Wno-error=3Dshift-negative-value -Wno-address-of-packed-member -Wno-error=3Dunused-but-set-variable -Wno-format-zero-length -mfpu=3Dnone -std=3Diso9899:1999 -Werror=20 /poudriere/jails/132-release-armv7/usr/src/sys/dev/drm2/drm_sysctl.c; ctfconvert -L VERSION -g drm_sysctl.o;' .CURDIR=3D'/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys= /TEGRA124' .MAKE=3D'make' .OBJDIR=3D'/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys= /TEGRA124' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm' MACHINE_ARCH=3D'armv7' MAKEOBJDIRPREFIX=3D'' MAKESYSPATH=3D'/poudriere/jails/132-release-armv7/usr/src/share/mk' MAKE_VERSION=3D'20210110' PATH=3D'/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/bi= n:/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/usr/sbin= :/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/usr/bin:/= usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/legacy/usr/= sbin:/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/legac= y/usr/bin:/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/= legacy/bin:/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp= /legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/poudriere/jails/132-release-armv7/usr/src' OBJTOP=3D'/poudriere/jails/132-release-armv7/usr/src' .MAKE.MAKEFILES=3D'/poudriere/jails/132-release-armv7/usr/src/share/mk/sys.= mk /poudriere/jails/132-release-armv7/usr/src/share/mk/local.sys.env.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/src.sys.env.mk /poudriere/jails/132-release-armv7/etc/src-env.conf /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.mkopt.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/src.sys.obj.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/auto.obj.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.suffixes.mk /dev/nu= ll /poudriere/jails/132-release-armv7/usr/src/share/mk/local.sys.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/src.sys.mk /poudriere/jails/132-release-armv7/etc/src.conf Makefile /poudriere/jails/132-release-armv7/usr/src/sys/conf/kern.pre.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.own.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.opts.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.cpu.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.compiler.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.linker.mk /poudriere/jails/132-release-armv7/usr/src/sys/conf/kern.opts.mk /poudriere/jails/132-release-armv7/usr/src/sys/conf/kern.post.mk /poudriere/jails/132-release-armv7/usr/src/sys/conf/kern.mk' .PATH=3D'. /usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys/TEGRA124' --- modules-all --- *** [modules-all] Error code 6 make[2]: stopped in /usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys/TEGRA124 .ERROR_TARGET=3D'modules-all' .ERROR_META_FILE=3D'/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.= armv7/sys/TEGRA124/drm_sysctl.o.meta' .MAKE.LEVEL=3D'2' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes ve= rbose curdirOk=3Dyes' _ERROR_CMD=3D'cc -target armv7-gnueabihf-freebsd13.2 --sysroot=3D/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp -B/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/usr/bin = -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/poudriere/jails/132-release-armv7/usr/src/sys -I/poudriere/jails/132-release-armv7/usr/src/sys/contrib/ck/include -I/poudriere/jails/132-release-armv7/usr/src/sys/contrib/libfdt -I/poudriere/jails/132-release-armv7/usr/src/sys/contrib/device-tree/include -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common=20= =20 -march=3Darmv7a -DLINUX_DTS_VERSION=3D\""5.9"\" -funwind-tables -fdebug-prefix-map=3D./machine=3D/poudriere/jails/132-release-armv7/usr/src= /sys/arm/include -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=3Dtautological-compare -Wno-error=3Dempty-body -Wno-error=3Dparentheses-equality -Wno-error=3Dunused-function -Wno-error=3Dpointer-sign -Wno-error=3Dshift-negative-value -Wno-address-of-packed-member -Wno-error=3Dunused-but-set-variable -Wno-format-zero-length -mfpu=3Dnone -std=3Diso9899:1999 -Werror=20 /poudriere/jails/132-release-armv7/usr/src/sys/dev/drm2/drm_sysctl.c; ctfconvert -L VERSION -g drm_sysctl.o;' .CURDIR=3D'/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys= /TEGRA124' .MAKE=3D'make' .OBJDIR=3D'/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys= /TEGRA124' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm' MACHINE_ARCH=3D'armv7' MAKEOBJDIRPREFIX=3D'' MAKESYSPATH=3D'/poudriere/jails/132-release-armv7/usr/src/share/mk' MAKE_VERSION=3D'20210110' PATH=3D'/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/bi= n:/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/usr/sbin= :/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/usr/bin:/= usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/legacy/usr/= sbin:/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/legac= y/usr/bin:/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/= legacy/bin:/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp= /legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/poudriere/jails/132-release-armv7/usr/src' OBJTOP=3D'/poudriere/jails/132-release-armv7/usr/src' .MAKE.MAKEFILES=3D'/poudriere/jails/132-release-armv7/usr/src/share/mk/sys.= mk /poudriere/jails/132-release-armv7/usr/src/share/mk/local.sys.env.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/src.sys.env.mk /poudriere/jails/132-release-armv7/etc/src-env.conf /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.mkopt.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/src.sys.obj.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/auto.obj.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.suffixes.mk /dev/nu= ll /poudriere/jails/132-release-armv7/usr/src/share/mk/local.sys.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/src.sys.mk /poudriere/jails/132-release-armv7/etc/src.conf Makefile /poudriere/jails/132-release-armv7/usr/src/sys/conf/kern.pre.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.own.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.opts.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.cpu.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.compiler.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.linker.mk /poudriere/jails/132-release-armv7/usr/src/sys/conf/kern.opts.mk /poudriere/jails/132-release-armv7/usr/src/sys/conf/kern.post.mk /poudriere/jails/132-release-armv7/usr/src/sys/conf/kern.mk' .PATH=3D'. /usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys/TEGRA124' 2 errors make[2]: stopped in /usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys/TEGRA124 .ERROR_TARGET=3D'modules-all' .ERROR_META_FILE=3D'/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.= armv7/sys/TEGRA124/drm_sysctl.o.meta' .MAKE.LEVEL=3D'2' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes ve= rbose curdirOk=3Dyes' _ERROR_CMD=3D'cc -target armv7-gnueabihf-freebsd13.2 --sysroot=3D/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp -B/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/usr/bin = -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. -I/poudriere/jails/132-release-armv7/usr/src/sys -I/poudriere/jails/132-release-armv7/usr/src/sys/contrib/ck/include -I/poudriere/jails/132-release-armv7/usr/src/sys/contrib/libfdt -I/poudriere/jails/132-release-armv7/usr/src/sys/contrib/device-tree/include -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common=20= =20 -march=3Darmv7a -DLINUX_DTS_VERSION=3D\""5.9"\" -funwind-tables -fdebug-prefix-map=3D./machine=3D/poudriere/jails/132-release-armv7/usr/src= /sys/arm/include -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=3Dtautological-compare -Wno-error=3Dempty-body -Wno-error=3Dparentheses-equality -Wno-error=3Dunused-function -Wno-error=3Dpointer-sign -Wno-error=3Dshift-negative-value -Wno-address-of-packed-member -Wno-error=3Dunused-but-set-variable -Wno-format-zero-length -mfpu=3Dnone -std=3Diso9899:1999 -Werror=20 /poudriere/jails/132-release-armv7/usr/src/sys/dev/drm2/drm_sysctl.c; ctfconvert -L VERSION -g drm_sysctl.o;' .CURDIR=3D'/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys= /TEGRA124' .MAKE=3D'make' .OBJDIR=3D'/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys= /TEGRA124' .TARGETS=3D'all' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm' MACHINE_ARCH=3D'armv7' MAKEOBJDIRPREFIX=3D'' MAKESYSPATH=3D'/poudriere/jails/132-release-armv7/usr/src/share/mk' MAKE_VERSION=3D'20210110' PATH=3D'/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/bi= n:/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/usr/sbin= :/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/usr/bin:/= usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/legacy/usr/= sbin:/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/legac= y/usr/bin:/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp/= legacy/bin:/usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/tmp= /legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/poudriere/jails/132-release-armv7/usr/src' OBJTOP=3D'/poudriere/jails/132-release-armv7/usr/src' .MAKE.MAKEFILES=3D'/poudriere/jails/132-release-armv7/usr/src/share/mk/sys.= mk /poudriere/jails/132-release-armv7/usr/src/share/mk/local.sys.env.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/src.sys.env.mk /poudriere/jails/132-release-armv7/etc/src-env.conf /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.mkopt.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/src.sys.obj.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/auto.obj.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.suffixes.mk /dev/nu= ll /poudriere/jails/132-release-armv7/usr/src/share/mk/local.sys.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/src.sys.mk /poudriere/jails/132-release-armv7/etc/src.conf Makefile /poudriere/jails/132-release-armv7/usr/src/sys/conf/kern.pre.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.own.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.opts.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.cpu.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.compiler.mk /poudriere/jails/132-release-armv7/usr/src/share/mk/bsd.linker.mk /poudriere/jails/132-release-armv7/usr/src/sys/conf/kern.opts.mk /poudriere/jails/132-release-armv7/usr/src/sys/conf/kern.post.mk /poudriere/jails/132-release-armv7/usr/src/sys/conf/kern.mk' .PATH=3D'. /usr/obj/poudriere/jails/132-release-armv7/usr/src/arm.armv7/sys/TEGRA124' make[1]: stopped in /poudriere/jails/132-release-armv7/usr/src make: stopped in /poudriere/jails/132-release-armv7/usr/src --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Feb 23 22:01:36 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 4PN6S94CjNz3sq0c for ; Thu, 23 Feb 2023 22:01:45 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PN6S85gQvz3Qb2 for ; Thu, 23 Feb 2023 22:01:44 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 3.19.118.201 as permitted sender) smtp.mailfrom=mike@karels.net; dmarc=none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.16.1/8.16.1) with ESMTP id 31NM1bJg047332 for ; Thu, 23 Feb 2023 16:01:37 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id +vS7K0Hi92PiuAAAs/W3XQ (envelope-from ) for ; Thu, 23 Feb 2023 16:01:37 -0600 From: Mike Karels To: freebsd-arm Subject: reboot broken on RPi4 on main Date: Thu, 23 Feb 2023 16:01:36 -0600 X-Mailer: MailMate (1.14r5937) Message-ID: 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.99)[-0.995]; R_SPF_ALLOW(-0.20)[+ip4:3.19.118.201]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[mike]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[karels.net]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PN6S85gQvz3Qb2 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Reboot (shutdown -r) is hanging on RPi4 on main as of today’s snapshot. It hangs after printing the Uptime. The initial bootstrap and boot from power-up work. I haven’t tested a snapshot since Jan 1, so I’m not sure when it stopped working. Any ideas what might have broken it? I can bisect the recent snapshots if nothing else. 13.2-BETA2 works, however. Mike From nobody Thu Feb 23 22:10:33 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 4PN6fN29qdz3sqSh for ; Thu, 23 Feb 2023 22:10:36 +0000 (UTC) (envelope-from otis@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 4PN6fN1Ll0z3hyS; Thu, 23 Feb 2023 22:10:36 +0000 (UTC) (envelope-from otis@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677190236; 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=rOAvege2jR6ZL5+wIZE6rJL1LC99GqTj5yrFYMbGZoY=; b=v+QNMJqB8MOAkFOFRDFeFLwjCpW5Kt2LKGHRdbAwVGH0qq+4mhvjlrM9jIwfvzfn/91c/I XqvTqEuDLd+JTsxvtOf1ly/mMFzIP2e9WQ2lnhf22WyPm8PtSfraWLMWQ71+LGeGe9QB9Z 4bcV9T7qWUHKxpz3Bzp123KYj06yaIanVG/2CVWksls3F1T58ScZy0Y1ulWAGcmTJjx0qO dbQ7yfCr3uu8Zy6BzuaS+FbcU1OSoSMkg13iK8sPJLgNDKuqsGGMGWABW40tOrZCpXg1Uh RM4FLylmFYogo259M43n/v8lLyHD+dRFEUWd9QjZCugAG350TDi9mu/FPZTe6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677190236; 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=rOAvege2jR6ZL5+wIZE6rJL1LC99GqTj5yrFYMbGZoY=; b=Ame+ov2j0Td/HMewsDaZNoioU1IqF2sLmGyMIoQgStTgbSHctDeRyzYQKykAOlZoegXd3y WFtSYEmwnvMcgvr3THpbXOO8CJpwfanRl1yonbCNOOL0v7TNteci4XiXF08XF3qmQ5BO7d jXkfp3KHNHFhPeHQKLx4CY/Q2aWjUGJN+IDMBxG7Y7IGvTWRVo+BILXjYZXQ4XVVZxL+e3 adyhN+oigzLXRqx9v7tMYTclbwv/wX2YeNGuLLTglfq+Xs46JADNwFLfb8e5ScfbuChhEz Ap4lo/ha3YePzuHt3Ve+UtHCaI42bwCB80mtmTUwcbl7j0MskwdUL7pziEKJ8Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1677190236; a=rsa-sha256; cv=none; b=mYS7iSK5RnvedmLnDKtXQ5rVjw1bWEUGfv9YPFj5fecX35jQuoSSyG2x3byXvpG4PFaCP4 ew2MZdD/H5IPpEP/Er/UdY5K96AzwJ8vWfLTahGZgxLZSIi3RmGqIQeOZLXWV74DK2plKI 2lwZUGjTJpOfxSuQdRPOKhiZrCfpQVQBXIEpRuJcD9frFDusaEqDD6LLfU9xMHdUUKj7BI Th5epyWhk71z0r1FkqzBIccCYSggu6rNhIQwm8CNNqLb4G5znJsI8YcbOFcjEeVsPd4IXo 7eKYK6BxAXRq1hbPtzH5PzBkM8sI9Ew56Ma85whaDzXbgU7w4Mg7rF/p4nhVYw== Received: from ns2.wilbury.net (ns2.wilbury.net [IPv6:2a01:b200:0:1:f816:3eff:fecd:13e6]) (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 ECDSA (P-256) client-digest SHA256) (Client CN "svc.wilbury.net", Issuer "R3" (verified OK)) (Authenticated sender: otis) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PN6fM6hLvzdT2; Thu, 23 Feb 2023 22:10:35 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtpclient.apple (gw-upc.owhome.net [188.167.168.254]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id DE66345CD83; Thu, 23 Feb 2023 23:10:33 +0100 (CET) Content-Type: text/plain; charset=utf-8 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 \(3696.120.41.1.2\)) Subject: Re: reboot broken on RPi4 on main From: Juraj Lutter In-Reply-To: Date: Thu, 23 Feb 2023 23:10:33 +0100 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <04BF8DA6-CAEB-4E2F-B2F3-1DCE0118C09B@FreeBSD.org> References: To: Mike Karels X-Mailer: Apple Mail (2.3696.120.41.1.2) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on ns2.wilbury.net X-ThisMailContainsUnwantedMimeParts: N > On 23 Feb 2023, at 23:01, Mike Karels wrote: >=20 > Reboot (shutdown -r) is hanging on RPi4 on main as of today=E2=80=99s = snapshot. > It hangs after printing the Uptime. The initial bootstrap and boot = from > power-up work. I haven=E2=80=99t tested a snapshot since Jan 1, so = I=E2=80=99m not sure > when it stopped working. Any ideas what might have broken it? I can = bisect > the recent snapshots if nothing else. >=20 FWIW, Git hash 575e48f1c4eb (1. Feb. 2023) does reboot OK. otis =E2=80=94 Juraj Lutter otis@FreeBSD.org From nobody Thu Feb 23 22:14:22 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 4PN6kl1BZJz3sqv1 for ; Thu, 23 Feb 2023 22:14:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PN6kk4rz1z3jhq for ; Thu, 23 Feb 2023 22:14:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1677190462; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=xr/O+8F2rOnk613Kk8CIOx4M7nVCEvUUrf3C9FNYJqw=; b=GS2HqrYD8ketRnrO7AgeoERDzkyB9N8RsUTadDMpzZXyRlOjzRGytrqCi7HLksxQ3fxu3l hVENXxZydwE21YpBQuE4lpDUg1RlYkpwPTPHd9dqirlLy13dyoYgHIZyJTS7epKTCTj2Eg jST2W+6Rvqsf09wGJK/Q4vnu/Gaq1fjoUoRpcNONy1PQSMhFTd3PXXomT3i1DB1YVmv4C/ JSNLO28F2DRVu0PuF0iKgDpFsFIa5AH/krjAKXYQoFwmzSvsHWY9e58ZFdZtI2t5EVNKBZ 9fgjf1wYbz+JDejEUTSRUzl5gn9dS3q70lLpe653wRvnuIL/SNAmqCF5kkDZTg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1677190462; a=rsa-sha256; cv=none; b=Z/+pdsvvCRCSMf0O7Ss+3iAhds5ng27rXhhkSDIcBF8w2TlxywcNZUlhXvhAVgCWZvt9x5 Up+WRoFKROVl4LJFmU7lh+CdPRhXSV4DX1MJ/Qeo8GYTv3bkzDrbMMLXhWY/8YCwAWqUUj jfGdq+lm/1/A7/tOWS504uuDCOapKp3y6tkTfJ2rER3OG28dhi+jot7gZhBvLU2EP29OA7 CukU8SNMhOzWBfxgcImIARNK0Gbwaa6pOAt4r6pYO2lY2xRxf4mcW0CTXbytBWofbjzyWh K+9vXJ/lnGFkQpAzt/375q1a7jzlrcDR7Yv8JvfP6p6bsDYXOeWjjWA6FiHyEg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4PN6kk3wFjzyyf for ; Thu, 23 Feb 2023 22:14:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 31NMEMrn069457 for ; Thu, 23 Feb 2023 22:14:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 31NMEM1V069456 for freebsd-arm@FreeBSD.org; Thu, 23 Feb 2023 22:14:22 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 269789] 13.2-BETA2 can't self-compile on aarch64 string_view:320:38: error: no member named '__char_traits_length_checked' in namespace 'std' Date: Thu, 23 Feb 2023 22:14:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dch@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.mimetype attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269789 Bug ID: 269789 Summary: 13.2-BETA2 can't self-compile on aarch64 string_view:320:38: error: no member named '__char_traits_length_checked' in namespace 'std' Product: Base System Version: Unspecified Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: dch@freebsd.org Attachment #240353 text/plain mime type: Created attachment 240353 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D240353&action= =3Dedit building 13.2-BETA2 on 13.2-BETA2 using poudriere-devel building from releng/13.2 branch from 13.2-BETA2 on aarch64 bombs out with `/usr/include/c++/v1/string_view:320:38: error: no member named '__char_traits_length_checked' in namespace 'std' during poudriere build fr= om git src. FreeBSD zap09 13.2-BETA2 FreeBSD 13.2-BETA2 metal/13.2-n254515-2a4ea3e56be GENERIC arm64 root@zap09:~ # sysctl hw.model hw.ncpu hw.machine_arch hw.model: ARM Neoverse-N1 r3p1 hw.ncpu: 80 hw.machine_arch: aarch64 Ampere Altra https://deploy.equinix.com/product/servers/c3-large-arm64 14.0-CURRENT (main-n260969-2894c8c96b9b) is fine though. repro: - get an Altra as above or ask dch if needed - install a precompiled 13.2-BETA2 - install poudriere-devel - set GIT_BASEURL in /usr/local/etc/poudriere.conf to github.com/freebsd/freebsd-src # poudriere jail -c -j 13_2_BETA2 -v releng/13.2 -m git+https -b -K GENERIC --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Feb 24 18:40:20 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 4PNdz23Xjzz3tnWL for ; Fri, 24 Feb 2023 18:41:50 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (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 "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PNdz20hX2z3Q2M for ; Fri, 24 Feb 2023 18:41:50 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Authentication-Results: mx1.freebsd.org; none Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.17.1/8.17.1) with ESMTPS id 31OIeKuG059855 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 24 Feb 2023 10:40:20 -0800 (PST) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.17.1/8.17.1/Submit) id 31OIeK3e059854; Fri, 24 Feb 2023 10:40:20 -0800 (PST) (envelope-from warlock) Date: Fri, 24 Feb 2023 10:40:20 -0800 From: John Kennedy To: Mike Karels Cc: freebsd-arm Subject: Re: reboot broken on RPi4 on main Message-ID: References: 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4PNdz20hX2z3Q2M X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Thu, Feb 23, 2023 at 04:01:36PM -0600, Mike Karels wrote: > Reboot (shutdown -r) is hanging on RPi4 on main as of today’s snapshot. > It hangs after printing the Uptime. The initial bootstrap and boot from > power-up work. I haven’t tested a snapshot since Jan 1, so I’m not sure > when it stopped working. Any ideas what might have broken it? I can bisect > the recent snapshots if nothing else. > > 13.2-BETA2 works, however. I've noticed that as well (for 14.x), but don't know exactly when it broke because it's rarely succeeded. From nobody Fri Feb 24 21:05:02 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 4PNj8R1PtMz3twXc; Fri, 24 Feb 2023 21:05:11 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PNj8Q2BQcz3tBQ; Fri, 24 Feb 2023 21:05:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 31OL53v4008207 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 24 Feb 2023 13:05:03 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 31OL53w4008206; Fri, 24 Feb 2023 13:05:03 -0800 (PST) (envelope-from fbsd) Date: Fri, 24 Feb 2023 13:05:02 -0800 From: bob prohaska To: freebsd-current@freebsd.org Cc: freebsd-arm@freebsd.org Subject: Timekeeping problem in /usr/src on new RPI aarch64 snapshot Message-ID: <20230224210502.GA8127@www.zefox.net> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [-0.69 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.59)[-0.594]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-arm@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[zefox.net]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PNj8Q2BQcz3tBQ X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N After installing FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img on a Pi3 and setting up the hard disk to use separate swap and /usr partitions an oddity came to light regarding dates. The image file was written to disk the night of the 23rd, from a Pi3 with a correctly-set time and date. It was left idle overnight, configured the morning of the 24th and booted without issue. It then cloned -current into /usr/src, at which point the time was noticed to be wrong, apparently fast. It turned out ntpdate wasn't running, so it was started and then tzsetup run. After a reboot the time reported correctly. However, make buildworld in /usr/src triggers an exhortation to "check your time" and refuses run further. running date on the system reports Fri Feb 24 12:49:41 PST 2023 but ls -l /usr/src reports time around Feb 24 19:10 an obvious inconsistency. Presumably just waiting until the system clock catches up with the /usr/src timestamps will fix the error. Is there a better method? Still, the date and time handling don't seem quite right. In at least one earlier instance it appeared that tzsetup altered the reported timeszone without shifting the time stamp by the UTC/PDT offset. I always thought timestamps were internally in UTC+timezone, displayed with the right offset. It looks to a casual observer like something else is going on. An earlier fiasco (on this same Pi3) included wildly wrong timestamps in a filesystem. The Pi3 has no hardware clock, how does it set time when booted without a reference? Thanks for reading, bob prohaska From nobody Fri Feb 24 21:52:48 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 4PNkCf1Mk0z3v05b for ; Fri, 24 Feb 2023 21:53:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (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 4PNkCf06nRz4207 for ; Fri, 24 Feb 2023 21:53:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677275579; bh=c8rpSQm39LKxmY7wLZwap7TztJClQlXvdFlQsGXHPe8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=AVs/Z08lq7Z+1Ig9rsAIWRdSbDHE8GRtcY6eISEcQ9k6gibcfiqipXiXzl0wlW69EgmM+tRiq72vL4FyEejz7RTTN4N0sVV5bgO0Iwnh27Ap0hULh3YBOc3ERCf76dAmEdz4ynpUoNtMbtO3BZD/+iXwHj5IebZc3zbCjWY8iL49oYoc0ShPhSKFjBLJhgdD2wKMzeZLrc8Wkz3FN1s3C8d9R+uXthAzSwdX+j64IDb3i4bpVoyLdN9f2Q89dMgpsrZjDBOWUy/3dw332p++Ye4yaHomoEJ9qC82xS2ZsdF4quzgFbEh7Hhsa4rUeQOj0tENRQGN95sdptgCkwl4tA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677275579; bh=9DFmdAMg+4SwQb2EcHxH9he09GsE7DfmawB1mNMwyfD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=l27p5sw+prnLHVsqWN7/W1r+mAOeher/pb4Fze3FVsBuS9J/hGRNGHy+yEKcOME7ncVrmakUPHlaYSjkv5gTAyRa/7zCB+b3BoBJh/EIWemspFOID/I/UwjV1JAim4Vm8RsqfeltIppb5vb5URHEwTZSOK0pWEv+/Sh4IDEvIh5H4cb2Aktl0HyKE4Kl91w2xatxPRijT3rkOqCRfhVEDdTQClBfbrRfTFDLPE5juHHrBzC1Rxf5Y9HfI1IbnKNejp3waLYp8Qq/xXkV9abu3pw3v5dzxgwKIaF66josjVBDXhEQmvhmb3VVBgvtvByTT86LuCCQEMgKlFfY5v8X2w== X-YMail-OSG: i2YYsXoVM1ltLSDr5p00_k23L6klgBQ1W4UYPzQ7Fh9N1oFChYOoC40D3ODbVmd H02FanCFNM6LFyCSCoeA_Bhvgz5t9pkwFfTa6h.hjX6t9nws4dBUuQwnjO0hpDiGm_ZgZFCFRj36 BbBBP_2TedUzZhAEoByTHRqH.13yg86ES.G8m27c7gMNqnV5kh0nYev2uT1OyezUp94Kljnhegyy sO5zeuFGBKpeT_s_lH86quuJ3ESj7v5_TJtQ0P7.Jkjugy_AH2yayr0uqLs6nfWb1C8z9pcl6sS_ UnjYvIvXDUK56UjMyKj46MZw.GCHtVHg60Qr9myc1LicSbIQtO_QrBBEFYKCkYdb0JY8Yz4ogCmg 3j0MLlUrApu_vC0Q2Or6.qt2d3ZhWtagdri2BnDRcRRpyA7lHRdkD2k1W.tbT_f8Mjo_dRJBFlzq RpFHnS.AxfeB_1xn8EUZzZpK47hDnYGbog8GREHNMmEPELZFMTqoCyg8N6H8ZcG5au0OgG.Qk8cP 4au7Sj3Cq5XpkKFwwa7_JpS2vbmeJU5Qs9Uo9axwGzSpRibR8l1lmyeu5lI9QW_NraB8qqaD9HlV amfUfDWaDAWm80va_6t7.UIw1BWUeAhtY0SGNLA25VvPEzByBzKgPu.Ow.7g31wu97wdNo7m2J22 33.gO6gpuq6ysJyq548DnO1FfdYBlM3pwPE0Noad4qLH2SNuSQsuniGMKA3G6JwC8pA877StAXVG P6obuWus3lEVdnI8FowvXpkOB4dk7ktp9ZhEyKGRcEWlpICudccc2tPoGOXjPfJDgZAqKvnCqTNR AQFx4bbbS6N1IIYLQlxnq6JvZoGUVV3kZquxpgynQcTSjTg97ry_UoRkHqs0d84Ab6pRzylaW5gi 2xBqrgDv9IBIBjnIiZBR0Rz5lfhj4yaXnHOwZYk1HPaC0mAQTObreVZ9bl9VRu8d27raRUxqw9FB 6ty2j7Oix09c2BngFr.Bbnnvyr0KtEQdQTzxN3Xp7DcKuLyKmoWDTZtjvMeML.FtiH16MlqStiWp Yzwi9fFCq45ERxBFve7VB_.IJslEfiVfAUZ.mCWYrvkBlWXnUq0MXaOrfV_HGmBhZV6veHlrC244 QiVbdylXnpYgAGGIq7dI0UFknhl4rTzcbxiS5d1JVgcamRIj7yT8XBOo_lmhMcWKKLOE_ANrCiQy 3Yaya_0Y_47A0w2lGRfNHrdLmOOplCHrlLZng2nwKjZ6wEPRTKwTECH5K.bVj7Y2Hvp2krHdWblE gSvZHcS8Rw_Zcj3qgZ3eLawhIVxzZHZ5sl8XCA2kfPukjqLYRcQ1z4PSneVvSPmvMSkES0BpyfBV E_Xd7JvoTPGYxkDfzhaf_wOzWvD8gtLXRosv0AQAsj94U08GhLQ7uyS1ZU2caBcpSLi7abSlmSeR Dbw4beEo1VCZ66W8O5FZIPV2KAKh_5KsJ4.qWz5.46j2Q7NKt_mLmL5oDx1U5pW3jRtxlhvUyS3f IFNOxjhZWqRajxVSxW59BVDtt57iJgDJDebTJBR4ZaiH07GqrekScDAKF0UbOpaE9uZyG8DM5wCo Q5x.Vn6ioqXVmz9JLgCoIv4yVyEdszwz03QuUEpJkMv84.1WfqYXfcxkNNXhKHQz.kkvtGxkZ1bV iM83D0xJ6pVGfqeQyzGbH2wz2ocdvns5.LjCg7EwYqYeQp2zjigyi7KpNuJB1iM_lAO2M3UPuEoG ZwYK4mrefRrH4IK0EwiO68kqpl7mesm2Y2nrjRsK4AauYk2veTYBMd8HJeNzxjjIi7ICbUm49ouj nxDUtNEdScxBAdmXvjbGPl6ZwKQK8rp7ZVEGLXcoZL0uWQmtKbL7slz8nlhweSvnxGrKcGgg1dYN Ap06ruHydLDUxLGISSEJG.NLMQZhRuebO4Lpm.JrOasi.KGq80xv3vJ.KtHehRdSp2ohmmB3dPlC 3R0ocNSPLW1uXfdF1XmMzsSDVILVst9CpTfvqvRa8fJal9uSagZxCSvwa1XW5PRWm24Tb.aB2B5u zr_D5MKNIRQ9zdENSmMiJqkgrO0qCuX8Oh8AKvMT2ppDfi4BFdqHWR1OEXZfXK3FqOalg17BYXhg PXVrlWB8VbOHCF0jeWEmtkZuYE80EAHg8KFVgPBzlCGAulXuc9v_lxbTqQPG9fnO9EIpM6Xe54Fh n408Z42vrA9m36V6wQk7TL8O1ARcFV6uAvAqY0VlS3.DoA5Qq151ij51ExRV78jqmzyN4wWlSApd nLTw.mYPJzA6ji4zA02zwYR3YPkxxoFyBOWCM3GcohNpTxhRWG72H_zX4URzERKFmjsQxcpFflze s X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Feb 2023 21:52:59 +0000 Received: by hermes--production-gq1-655ddccc9-nql2v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7c31e287324c0c661d251f2dfc915b40; Fri, 24 Feb 2023 21:52:58 +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 \(3731.400.51.1.1\)) Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot From: Mark Millard In-Reply-To: <20230224210502.GA8127@www.zefox.net> Date: Fri, 24 Feb 2023 13:52:48 -0800 Cc: Current FreeBSD , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230224210502.GA8127@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PNkCf06nRz4207 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 24, 2023, at 13:05, bob prohaska wrote: > After installing=20 > = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img > on a Pi3 and setting up the hard disk to use separate swap and /usr = partitions > an oddity came to light regarding dates. >=20 > The image file was written to disk the night of the 23rd, from a Pi3 = with > a correctly-set time and date. It was left idle overnight, configured = the > morning of the 24th and booted without issue. It then cloned -current = into > /usr/src, at which point the time was noticed to be wrong, apparently = fast. >=20 > It turned out ntpdate wasn't running, so it was started and then = tzsetup > run. After a reboot the time reported correctly.=20 >=20 > However, make buildworld in /usr/src triggers an exhortation to "check > your time" and refuses run further.=20 >=20 > running date on the system reports > Fri Feb 24 12:49:41 PST 2023 > but ls -l /usr/src reports time around=20 > Feb 24 19:10 > an obvious inconsistency. >=20 > Presumably just waiting until the system clock catches > up with the /usr/src timestamps will fix the error. Is > there a better method? >=20 > Still, the date and time handling don't seem quite right.=20 > In at least one earlier instance it appeared that tzsetup=20 > altered the reported timeszone without shifting the time > stamp by the UTC/PDT offset. I always thought timestamps > were internally in UTC+timezone, displayed with the right > offset. It looks to a casual observer like something else > is going on.=20 >=20 > An earlier fiasco (on this same Pi3) included wildly wrong > timestamps in a filesystem. The Pi3 has no hardware clock, > how does it set time when booted without a reference? There are 2 files involved: /etc/localtime Current zoneinfo file, see tzsetup(8) and = zic(8). /etc/wall_cmos_clock Empty file. Its presence indicates that the machine's CMOS clock is set to local time, = while its absence indicates a UTC CMOS clock. An oddity here is that there is no existing CMOS clock but the /etc/wall_cmos_clock status still has consequences, as I remember. Various related man pages are: adjkerntz(8) tzseteup(8) zic(8) =46rom an RPi4B: # ls -Tld /etc/wall_cmos_clock ls: /etc/wall_cmos_clock: No such file or directory # sysctl machdep.wall_cmos_clock machdep.wall_cmos_clock: 0 (So: As if a CMOS clock was using UTC time.) # strings /etc/localtime | tail -1 PST8PDT,M3.2.0,M11.1.0 # sysctl machdep.adjkerntz machdep.adjkerntz: 0 # date Fri Feb 24 13:42:52 PST 2023 (Matching the local time.) So, as configured, /etc/localtime is used to specify covert kernel UTC to local time as needed: no addition non-zero offsets. As I remember, things can be odd with file systems from Windows variants and the time stamps interpretation. Keeping such matching vs. not can get into the choice of if /etc/wall_cmos_clock is to exist or not. It can be a seprate issue if time tracking is off rate or some such. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 24 23:18:56 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 4PNm766W8mz3v4GN for ; Fri, 24 Feb 2023 23:19:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (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 4PNm754T1Xz4F5R for ; Fri, 24 Feb 2023 23:19:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="Z/mBkBOh"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 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=1677280752; bh=CIZr8rUTX5Ed/7tb0JW2wl8hr8555LOzKoVzuBOBtjc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Z/mBkBOhTuFsIdffgd/2UxNv007JO9UdbQrs/FNHt42JlfK9aQX6HCwnJWiITNOY6UtrTwusnr6XNXYtXLB62UCIyUyX5JblAZn2ljcZ19LdplfAzUTKQ2eKXVgxIeCEHtVifBadn2F9RlkZ+QBSIZHEs0SFAWQZe616I86uc5CuNNbCFpeqibyEQAVgIJPFmZ3NKg5oZcQX3IHJgJsZLMMLj/Zw1N5C3T5NTS4cRGZTVYOiuSOX81iXCLdkrAB/j9eGS4P4PAMqPknz0WUPVXzCBCzkaB9X7qgWx1iZIPesedn9kfY5xnVn6hCAFMYbDo4ZayLDIS6BxqIvAKGp5g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677280752; bh=HI/b2pwtowmigxQAuIxtGqRHGQt5BXQWJrbfaaJfvJU=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sQ7wLrD8IjNDJf+9hXWcHPXuCqxS59e5YY9Ui3V4EP7cszMmNftCQ1OkG2t6v05X3XEkiax+jlhhmKw+44wluyCqXR8dyLtd6Bzch3BhHFaouf6BEjtgS57U7g/9BXjKZqXuKrw8KXvZigCM89zcbx09P5qMyy1p3CfUwaBehOnF+Y7hS5erl96xp+3cZYUq2q4TAtYVsoY7J9yhn6RuI+CofWrQmwroHJQHECyHNjiXf5cz/LiKSdtoeeHoYEtBbN3ybWTKC7BwzC2blzvtfnt4QSGEVvimK9wXRHZREMV81oFbshFccvuaqyR0lez4zoJcTsQzJx08NUtst6G7vw== X-YMail-OSG: zvdats8VM1kTK9muE2KTwWl_PDIGAdrYDzNQguenZ9VFlTvMfCANZnXETUzAMMn cd0PWym0DtKGs1WoSJqUlXDdOQvHI_0b0c59d_2rgHcmKN7qNxF.sx8rmF2Y4N3Iwq9OyGsWiBaQ rF73EC74aZ5MU0qKw0HRbwypUxeGU4RedqWOyyxg2YfsOSQr9VqkpomdiBOZjVFs_gUp2W.uTkCj qVT6TemyMK9vZ.DO67UKsy8e0HAiqPg3mrB3BaGnBUGIc0FLePMJIjVZuafQvqnVp5HNmT69C9gJ BOPz6.lZaxj0VCM1jAR.SJ2ywaL5RnsERvgqDl_ZFbawqu5esdipv7E7mkO3qC.Cc_949nlcjAbU 67H8.FxeuCsUZhrda_MAlLDvpSukA2ge7hi6CWca27x2oXSK1r8kLsIqav9QtGWrAXmKtdsnauE6 zClLUnZOdAtzHyMqAq2x7.j2pL64EOQv5BdFIrrLamFgTDpOK3V.5haBNpOvJTg6j4ucTsimS9Jx xf84bdaUgAGrwOYvYsrNpN6Eqzwum1sKle6c24goWOF22vJ90TTVF_TO1SVdvsz0p9XMmlbmAuMD 2g2_2T7qdv8oi_6tk1WuGRNcxx1A_5HoHg66BDo9NrNIEJ_JhohfyhZs7sJ7cgtTXvNnNMaYyOV2 m07lEQBCFx8wh7TIA_c0U2GS2mwsAo8TdPjWRXKhyX87LTYJl9cOMat6bfloZ8pFNm9ksmBiayBJ f4E9Do67vpkhzKDrPStPcwNqfH14g1JQhiuBfWpaoX85tscj65AGeAUdT2omQMqA_TBS9CMPuJlm lP6pRmzcZHQ4_JW8Jn8_opC2c67s0iQHKsZOScIzuZ0UGH9z8xy9o0s6gZEAtiA0U4X_3s7ly8PD 0fBBGb6bHqhcBjowG8SJTF3ODUFj_urSy4hbOtmuOQdhVdbnx30O6FGb_Jm2Em3K67u9P0wXs.jp J.YeNMAx4DC2TFzJrvRcTO1VxC6dojKSg41GfzXdKJg.8tNhi3A5pT4V4_ji2CSolZH3yTCIoAyb zno6fhYRz00Y9l9P4nMeWIJ.GbHhRqQUhs_t.DchRMN5TArJ9HS68uScBpEvY3scx_OLEMyuJJeo sL7YpG83zyVpP4yBIZTot6yuJfuWWc7Fb3Lzfk2asII9rfNggqfU8HbTWv2AbQU2YdXID83H276P .cPM0QJpVhroZQWBrOG3w14FHv113scDlArwPsvbPIk26wFmJJe_nuzT95WceQsHA8yyyTFw7aG4 ueFy0sq04JLyN1HoNZxJ1DDgwIIYMdi7P_lk8Cc7GIjezq8jorNE06SszTNacU.7ZFZzBub3LmQ6 csVCiu1HxayxY5t8RIUODFRws3uqEc1XD8C7NcEZGNWvF9JmmvTV14eRpU7H3ppjkoDRiUBAaMDX CoiOVkdxOLYVAb3L5oFZA8g6qIGeIns09Z3sk85.F6XHMo4n_6ZOM5vJfa5KuFB04Dz5VEtpUtth UozzN2sVePRalm8K368YfpV7Xf7nfXINxM6iKCMrdzl53VEIjWyroIonlzra60NYSo.qa4a9UELx gExlzbp8X6fBZj0QVcUHNBONVg3GZEVF3lpY7IAQR0oTdgyAG7lIze8S.ntX.yC9ZpsFBTHdW4eb Blu_fPNzJBBD9dzrttBIdz1HDkt6k8Kj.7237Pd7tkZ2ygvspE8Kwa.DcnLn1tuztUK_7ThnQwpJ LZAvqtwNenlQe.GrMYTPnZTx.8OR3e213K1uMQ4abF7u15o9YzLucFAqU0o2ZBx79m_jEnuoOHqU 9AVIG6qdMPmFJYY3egvWbvvwbWM_EnLWazuAmagfUeYcPeQlobDj8HREcJfEW_t3sW12UJK__e7j 4Mm_xX1znTfEBFpTgzpYQMhI3aBPxDwvLo7SV_dHfKmCqQ0u1UPPV2oznu2dVptEwIaQprpvOuNf sINj6_bmwv7zY0BGMKt1S1Git.qxv31so9m7jDT4Nhs9coiB1uCffPBHRIs6qysXt4_.YJQ5MP2D r0NWtZkj20OBOaQdr5Qpjhe7htTXYniwXfT921.OPNkc.ZzgfOjtGMlVBy3lqiXB_DAHry.EBdQk BGZ9pdefOHBxVVAZWjWxqI2Q4SnsFqrcyz59fXIuA6JWHWeNeW0o14HJAIq1ddw4WURcivM6FGDK yirF13ANjUHN1CnDoxlNfNHnaxQxvUgafPoFBG0S1nQcRvIJbaA0iV3i2AhsdjekHEm4NDvFDu_p OJcLBEAaB5x4Ifh3SZKHo9ZIdHNqoaRNZb24YNwoi61P5rBE7TIQKd3ADyQYUTmY9JU7RUpzaxf. pgA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Feb 2023 23:19:12 +0000 Received: by hermes--production-ne1-746bc6c6c4-fgv82 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 35c6c89ece5a5b7f43f33858f016c5c2; Fri, 24 Feb 2023 23:19:09 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 \(3731.400.51.1.1\)) Subject: Re: reboot broken on RPi4 on main From: Mark Millard In-Reply-To: Date: Fri, 24 Feb 2023 15:18:56 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mike Karels X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4PNm754T1Xz4F5R X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Feb 23, 2023, at 14:01, Mike Karels wrote: > Reboot (shutdown -r) is hanging on RPi4 on main as of today=E2=80=99s = snapshot. > It hangs after printing the Uptime. The initial bootstrap and boot = from > power-up work. I haven=E2=80=99t tested a snapshot since Jan 1, so = I=E2=80=99m not sure > when it stopped working. Any ideas what might have broken it? I can = bisect > the recent snapshots if nothing else. >=20 > 13.2-BETA2 works, however. For reference . . . While it is a personal build instead of a snapshot, I see the "shutdown -r now" hang problem for my build based on: # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ d04c86717c8c (HEAD -> main, freebsd/main, freebsd/HEAD) bsd.sys.mk: Add = NO_WSTRICT_PROTOTYPES like in kernel branch: main merge-base: d04c86717c8ca3aa1bd9d8927a37a1f5443925b5 merge-base: CommitDate: 2023-02-19 07:02:12 +0000 n261026 (--first-parent --count for merge-base) The context has a "B0T" 8 GiByte RPi4B. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 24 23:21:09 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 4PNm9N0Gxvz3v49p; Fri, 24 Feb 2023 23:21:12 +0000 (UTC) (envelope-from SRS0=RvKr=6U=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 4PNm9M5KCLz4Fft; Fri, 24 Feb 2023 23:21:11 +0000 (UTC) (envelope-from SRS0=RvKr=6U=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Date: Sat, 25 Feb 2023 00:21:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1677280870; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=slq6LhIvHBK8955ssKcR8rkKQwtEeLy4YJK1j6RDNnc=; b=aPjEKoZHReZ8/mFDYRPb2uLRe8wh4Lza4tDIazJbJPoM/BDC69+eLanc0HZJjfPn54EOE3 gf9hNzD+VG07OECsrrahcFkMIREF2BfAKKKFJ2oqDUp6wA9Q2sPZ67vYfSHcWFcgxxIZx5 eLZDNqljrTrjc5YMAvClOhSKzAgfCIaR1bRlz4wK9l2wP+jvSSYWKZFETfuM2XM+TwD97B epv8J1/Sas5YSoA3W++I2SO3vfFiXe+qWxc5RrG+oYgi9+8AnQllcLTAZWno+/KQEGV4ZS iRHIBoUCWUwkdr0PQ4vkhmaeDWHSW489Aj8rdIBoyzopKLWwsqSgmP2MZDEhCw== From: Ronald Klop To: freebsd-arm@freebsd.org, bob prohaska , freebsd-current@freebsd.org Message-ID: <1216867532.11893.1677280869319@localhost> In-Reply-To: <20230224210502.GA8127@www.zefox.net> Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot 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 Content-Type: multipart/alternative; boundary="----=_Part_11892_113718381.1677280869315" X-Mailer: Realworks (645.67) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4PNm9M5KCLz4Fft X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N ------=_Part_11892_113718381.1677280869315 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Van: bob prohaska Datum: 24 februari 2023 22:05 Aan: freebsd-current@freebsd.org CC: freebsd-arm@freebsd.org Onderwerp: Timekeeping problem in /usr/src on new RPI aarch64 snapshot >=20 >=20 > After installing=20 > FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img > on a Pi3 and setting up the hard disk to use separate swap and /usr parti= tions > an oddity came to light regarding dates. >=20 > The image file was written to disk the night of the 23rd, from a Pi3 with > a correctly-set time and date. It was left idle overnight, configured the > morning of the 24th and booted without issue. It then cloned -current int= o > /usr/src, at which point the time was noticed to be wrong, apparently fas= t. >=20 > It turned out ntpdate wasn't running, so it was started and then tzsetup > run. After a reboot the time reported correctly.=20 >=20 > However, make buildworld in /usr/src triggers an exhortation to "check > your time" and refuses run further.=20 >=20 > running date on the system reports > Fri Feb 24 12:49:41 PST 2023 > but ls -l /usr/src reports time around=20 > Feb 24 19:10 > an obvious inconsistency. > =20 > Presumably just waiting until the system clock catches > up with the /usr/src timestamps will fix the error. Is > there a better method? >=20 > Still, the date and time handling don't seem quite right.=20 > In at least one earlier instance it appeared that tzsetup=20 > altered the reported timeszone without shifting the time > stamp by the UTC/PDT offset. I always thought timestamps > were internally in UTC+timezone, displayed with the right > offset. It looks to a casual observer like something else > is going on.=20 >=20 > An earlier fiasco (on this same Pi3) included wildly wrong > timestamps in a filesystem. The Pi3 has no hardware clock, > how does it set time when booted without a reference? >=20 > Thanks for reading, >=20 > bob prohaska >=20 >=20 >=20 >=20 >=20 >=20 UFS stores the current timestamp in the superblock of the FS on clean shutd= own/unmount. On boot it reads the time from the timestamp in the superblock= of the root FS. Of coarse this timestamp is behind for the duration that t= he machine was off or rebooting so you need to adjust that using ntp.=20 For ZFS root you can use the fakertc port to do something similar.=20 You can use the command =E2=80=9Ctouch=E2=80=9C to manipulate the time of y= our /usr/src dir.=20 Regards, Ronald ------=_Part_11892_113718381.1677280869315 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Van: bob prohaska &= lt;fbsd@www.zefox.net>
Datum: 24 februari 2023 22:05=
Aan: freebsd-current@freebsd.org
CC: freebsd-arm@freebsd.org
Onderwerp: Timekeeping probl= em in /usr/src on new RPI aarch64 snapshot

After installing
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img
on a Pi3 and setting up the hard disk to use separate swap and /usr partiti= ons
an oddity came to light regarding dates.

The image file was written to disk the night of the 23rd, from a Pi3 with a correctly-set time and date. It was left idle overnight, configured the morning of the 24th and booted without issue. It then cloned -current into<= br> /usr/src, at which point the time was noticed to be wrong, apparently fast.=

It turned out ntpdate wasn't running, so it was started and then tzsetup run. After a reboot the time reported correctly.

However, make buildworld in /usr/src triggers an exhortation to "check
your time" and refuses run further.

running date on the system reports
Fri Feb 24 12:49:41 PST 2023
but ls -l /usr/src reports time around
Feb 24 19:10
an obvious inconsistency.
 
Presumably just waiting until the system clock catches
up with the /usr/src timestamps will fix the error. Is
there a better method?

Still, the date and time handling don't seem quite right.
In at least one earlier instance it appeared that tzsetup
altered the reported timeszone without shifting the time
stamp by the UTC/PDT offset. I always thought timestamps
were internally in UTC+timezone, displayed with the right
offset. It looks to a casual observer like something else
is going on.

An earlier fiasco (on this same Pi3) included wildly wrong
timestamps in a filesystem. The Pi3 has no hardware clock,
how does it set time when booted without a reference?

Thanks for reading,

bob prohaska



UFS stores the current timestamp in the superblock of the = FS on clean shutdown/unmount. On boot it reads the time from the timestamp = in the superblock of the root FS. Of coarse this timestamp is behind for th= e duration that the machine was off or rebooting so you need to adjust that= using ntp. 
For ZFS root you can use the fakertc port to do somet= hing similar. 

You can use the command =E2=80= =9Ctouch=E2=80=9C to manipulate the time of your /usr/src dir. 
Regards,
Ronald

------=_Part_11892_113718381.1677280869315-- From nobody Sat Feb 25 01:45:01 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 4PNqMf75W1z3vBtV for ; Sat, 25 Feb 2023 01:45:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 4PNqMd5lc8z3Gwx for ; Sat, 25 Feb 2023 01:45:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Wab8IGcE; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 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=1677289515; bh=7hAs2/vI1rdjQ1MTDFzqQbavzhoK5deqv2fO1W5HjVo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Wab8IGcEFR+KXbHuearN9bClpi4+nZGiIFzA8Xu4MoF8Y96s0Zmmyix+FhYXYWAui4uDjUNhUAwzzS4a1E+WyfmYal2ZFTu6yqys6kj98HZrtU2fUJeukPPKS/BkEulmp0VKbpjCtTwVZJs8YbDilUfuxjs6EDfiJIKhTRJguZEPSRqHOv7T1kIvwbLD+h6CKg6hWqm5oUShtsiaEWsEaJwXjE5P90qt8ooq8l+3SYqCjstG6Tkm8g6xJ9NDhaXXLjInamZWSnH047NXmbMAw8MbmpnOzc2kpQPSn1UAl+cxQJ04rxKGsEnmA1GWNZGa1QxlYYoFwph1XWAr0rHaiw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677289515; bh=ISrE1ioJnp6nu6awHLGNAfsimmKImgELZkYeD9AnWnt=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pJMZiUhWyUO1EkVXUAZdR/RqZcle2kjqu8BHju6y6V5uiyhBj34kVtdwzV7gOIPSbeaaOGkwBQtW9D9xaKd18ZifXHV/3kf0mN8KXQ8HSnyZAHBUOFT8yvv1i4vrSMQ9t869BWsVg1RNvWT2t2NzByNGIWiFLG1SAXH9hwvYUDWGPJouI6WaG49erB40VLZjKhcMDlY1RFbNgFR9h0avVTpAdhloVyaaf+flq49jY9fYstDMkTjqzBohNkIZgCoTyT3dSGudHdtObGwXbEgWQvkYfh4ZlXXEZUEky/R5ZS9yqtc2eaQ4Wc8FO0tjzOjELHvAPQ9X1p0pLoHoSrqvcQ== X-YMail-OSG: YmwXeAgVM1mfBgHuq2YZxyHf9.3SGf.JWjHnI9p4f4s26OXqL4wfgjEaNeRNMsx FyOmPRg1Lq8rODNw3aOpqnWp5nAwsGoZB.zLgyFg.gPfTd0gD3lac05dNus4Tx5H15o2EPjH1xVp 9sNw6TH25Bres2F_ZWX3yb8.eZs7d9n_E5_tbeg3kL8l9AxRDgrZitGlEHYYbANtyjZ_mUnYXqVa Z.FfNBS3jjr5AL._wrsRmHEdlAJy1CvzHyLq6YNz0BoIZ_y69z5e_if2v67EQTex.YGuk_g15Aof 6.F3AwlGe9tqg673Cz8BMO.qUV0c7JvgKnPHsVikBWDPRBj9ojAGRuj9jqaCJ2U9K9Vrc.8gedZO uKH_bH.xgzn00eONMS32KLduHid93jGpuqPembY80Vb.W3ogPqjCMs.PzxUpKNIiBfOQ6EbRQrvN mODmqRbyqQKUdbFuiS8GzuSo9Sy9jogVUPDDVP.kPxu9yB8tOqqErtR635vaQEe.D9zlvAHDugu1 Sr7R7FWoEgf5yM2wxN7QXCn7bNO7WIZbIwjd0_UWFKX3Bx4qggkyMBUch4w.KRTcts3Nf6CtM7Ei 2poyQ8BzHvV4GD8NmaUjj2GJxUoQNXL1vyW.OCJHTt04rjEGqEOBH.eGmMFukNVz515ZyN4eYqgj S89bZ0OwwRGklsv51ubAYaX7e.8_F5gUyIb3GqF2cw.kSrcg2VszATowFmqRhMZvt9IxORCbn2Ih M9VN0WxzG5t15bNh8hnUWQKpeeZmq1haBwMt9KY2SWfQ4.PbFqZvTxTEPPpywM9p_AW61V6bzTFj _yBLx0WiPAIS6lfeMPRE58famQ6w9ltj8m_bQzpuOoE1y5Dfu0Wvbk_vi.mazx3lf.xIhpyutP34 qmyT6agfWprmZlxvNYJsPW86x6GrXLJrIqa_uh8ZUN5p.iQx6stUqqTHGFtSVV0FU_YVgrTS29va mAeIQjWZghpxdK6eH92QUu_1N1g1dNBq4SDzbq7FA.xf3NfKrze7TFl4xSgkcrKvg.b45zoDkWUX NxlJCPBhs3XP8t36Zg1baEKu2hVOUw93SeVKVJaS7gU0MLW6N2LbbMRNkepi8.diEfLoLwu09wd8 oB1u.DpE46rUAkIXNqNPy418V6bSOBucznNlGgMAQBxjyxB8ZDV3fT2d5ilIjruWmWtPbkSNH5J_ PHyIXAWpffIuDjZDs9hK2oDU24dmPUKx142rwHS_fe2siUDXnQ2QOho9Lgz7pZNqPjsb0xngmVuQ i4u.BW7g9fE36XnWuHDUoMRRYOkxqbd6SnrTEhqx.yZ.GMDcIND03nPlpRATNdr8rCjZaDbwEx8m u9trck78Z1uzt9pmiLQdkp07K_7QKDZXJmwuyGE5hAfW_xvncDs_DNDarXLg6YQ_khYY5SCN2cLk 5Fnon8gClaEG.I4NjXdreO6hYKQ6tK.YuDaCEjmMl6fwx_ll0s2lzRgepxI0fnf2KucecUTGyDew EL75lwbb7Jsnh3Bs8Yjk.tb2Q7xsULTXM96p8PFulgTrjnW5UWWa0dLn0egBR4ReyT747K9oORn6 Ck0Kipr8sTruK0bq7WMAzKW181.Snlxqn0d_Zxi6L8jSiyINMzyp7EvWfC92zo_dCB6BSI8sNpEH w87OHrSseM5u1vk0l6vdoj.ty_krr2hAvdxd_yg0ckNl60.w7_fPCYraAp9qudmMvy0wsJmrULWy AXMGJQfxOHc1I12pCy94YT5dmXkOH3N0dRQ.trbVycV5Pwruc9bswGZe9xtUIXHXo6C3wU4Topq. tZlQXi77XF37teSUwoo9HTbluBW517DHcAjTQw2gCUy.R6GaNCr.SVBX2B1hIIR5oNYE1kGBqH9C iBdy5LRdOvq1xiVvotCoAhaCWGdq2UojnFCh0m6bMJ.W_8GpXWyp62EfXfwy1SlMPYxQORiT5S2Y n_hrJPl31m3QFJB__N5DeMOnX7g7gXzRbU5.2PXcittX.N_BAFfY_aY0SiggTuROF.Q1mbfqK9py AvkuGnte5ORpuym7_LUx0_lrqaBJbg6q2zs0GwM3jgJKsyXDDXE7iGCYokFuIuUdP_gN6NJ7SuUM oKapiQ0geZmgEfhYqZxF0aR.k7C1jUIacRU751CAp.2b_tBgx6qHqY6EnHIzYOAnmsP5iu.h8lU1 o0nAsJapa9fmm_My97mI6fl2AnqhLXglSYAByWDpTmlL10muZO0UFjtHAGmdTZE8R.6gjOxZacKa rvFGPYXTQvut0NUUY4OlsnP3rCkeHYKWDzQbJVXjSsC.rjoJVP8rnnkIwsAgUxrWNR25NiQvddzy d X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 25 Feb 2023 01:45:15 +0000 Received: by hermes--production-gq1-655ddccc9-9226q (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b05f247ed645a7eb96419d083945f2f6; Sat, 25 Feb 2023 01:45:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 \(3731.400.51.1.1\)) Subject: Re: reboot broken on RPi4 on main From: Mark Millard In-Reply-To: Date: Fri, 24 Feb 2023 17:45:01 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <9EA91B94-87E4-47B8-A4E2-60D556E64276@yahoo.com> References: To: Mike Karels X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.42 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.916]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4PNqMd5lc8z3Gwx X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Feb 24, 2023, at 15:18, Mark Millard wrote: > On Feb 23, 2023, at 14:01, Mike Karels wrote: >=20 >> Reboot (shutdown -r) is hanging on RPi4 on main as of today=E2=80=99s = snapshot. >> It hangs after printing the Uptime. The initial bootstrap and boot = from >> power-up work. I haven=E2=80=99t tested a snapshot since Jan 1, so = I=E2=80=99m not sure >> when it stopped working. Any ideas what might have broken it? I can = bisect >> the recent snapshots if nothing else. >>=20 >> 13.2-BETA2 works, however. >=20 > For reference . . . >=20 > While it is a personal build instead of a snapshot, > I see the "shutdown -r now" hang problem for my build > based on: >=20 > # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ > d04c86717c8c (HEAD -> main, freebsd/main, freebsd/HEAD) bsd.sys.mk: = Add NO_WSTRICT_PROTOTYPES like in kernel > branch: main > merge-base: d04c86717c8ca3aa1bd9d8927a37a1f5443925b5 > merge-base: CommitDate: 2023-02-19 07:02:12 +0000 > n261026 (--first-parent --count for merge-base) >=20 > The context has a "B0T" 8 GiByte RPi4B. For the artifact builds available for arm64, testing the kernels: The last that has "shutdown -r now" working on the RPi4B I'm using: =E2=80=A2 git: 8b418c83d175 - main - cp: Adjust the sparse file = tests. Dag-Erling Sm=C3=B8rgrav ( = https://artifact.ci.freebsd.org/snapshot/main/8b418c83d175fde3b1f65210509d= dcf2ac248d9f/arm64/aarch64/kernel.txz ) No arm64 artifacts after that until . . . The first that has "shutdown -r now" failing on the same RPi4B: =E2=80=A2 git: ded5f2954e1a - main - nfsd: Fix handling of the error = case for nfsvno_open Rick Macklem ( = https://artifact.ci.freebsd.org/snapshot/main/ded5f2954e1a1bb7748646888938= af767ee6257a/arm64/aarch64/kernel.txz ) So the range is limited to (including those end points): (All are 2023-Feb-08 artifact builds.) =E2=80=A2 git: 8b418c83d175 - main - cp: Adjust the sparse file = tests. Dag-Erling Sm=C3=B8rgrav=20 =E2=80=A2 git: 87d405eab911 - main - iommu_gas: initialize start_gap = as first node Doug Moore=20 =E2=80=A2 git: 8c784bb8cf36 - main - lua: Update to 5.4.4 Warner = Losh=20 =E2=80=A2 git: 5fff09660e06 - main - geli: split the initalization = of HMAC Gordon Tetlow=20 =E2=80=A2 git: 81ad626541db - main - Merge llvm-project main = llvmorg-15-init-15358-g53dc0f10787 Dimitry Andric=20 =E2=80=A2 git: 753f127f3ace - main - Merge llvm-project main = llvmorg-15-init-16436-g18a6ab5b8d1f Dimitry Andric=20 =E2=80=A2 git: fcaf7f8644a9 - main - Merge llvm-project main = llvmorg-15-init-17485-ga3e38b4a206b Dimitry Andric=20 =E2=80=A2 git: 972a253a57b6 - main - Merge llvm-project main = llvmorg-15-init-17826-g1f8ae9d7e7e4 Dimitry Andric=20 =E2=80=A2 git: 61cfbce3347e - main - Merge llvm-project release/15.x = llvmorg-15.0.0-rc2-40-gfbd2950d8d0d Dimitry Andric=20 =E2=80=A2 git: a4a491e2238b - main - Merge llvm-project release/15.x = llvmorg-15.0.0-9-g1c73596d3454 Dimitry Andric=20 =E2=80=A2 git: 6246ae0b85d8 - main - Merge llvm-project release/15.x = llvmorg-15.0.2-10-gf3c5289e7846 Dimitry Andric=20 =E2=80=A2 git: f3fd488f1e19 - main - Merge llvm-project release/15.x = llvmorg-15.0.6-0-g088f33605d8a Dimitry Andric=20 =E2=80=A2 git: 50d7464c3fe6 - main - Merge llvm-project release/15.x = llvmorg-15.0.7-0-g8dfdcc7b7bf6 Dimitry Andric=20 =E2=80=A2 git: 3264f6b88fce - main - Bump __FreeBSD_version for llvm = 15.0.7 merge Dimitry Andric=20 =E2=80=A2 git: 89a072d11cd2 - main - Makefile.amd64: remove = construct that serves no purpose Warner Losh=20 =E2=80=A2 git: ae1dca798e0f - main - e1000: fix I219 hang on reset = Kevin Bowling=20 =E2=80=A2 git: 647f2d2bc0cb - main - e1000: bump driver version = Kevin Bowling=20 =E2=80=A2 git: 48bfd3597654 - main - Add nproc(1) Mateusz Guzik=20 =E2=80=A2 git: 1d03c3578d05 - main - arm: add an interrupt rman to = nexus Mitchell Horne=20 =E2=80=A2 git: f9bdaab95ec4 - main - ofwbus: remove handling of = resources from ofwbus Mitchell Horne=20 =E2=80=A2 git: e6cf1a0826c9 - main - physmem: add ram0 pseudo-driver = Mitchell Horne=20 =E2=80=A2 git: fa3f6655421f - main - netmap: drop redundant if_mtu = assignment Vincenzo Maffione=20 =E2=80=A2 git: ded5f2954e1a - main - nfsd: Fix handling of the error = case for nfsvno_open Rick Macklem Notable are the llvm15 commits and the changes that some arm code: =E2=80=A2 git: 1d03c3578d05 - main - arm: add an interrupt rman to nexus = Mitchell Horne=20 =E2=80=A2 git: f9bdaab95ec4 - main - ofwbus: remove handling of = resources from ofwbus Mitchell Horne=20 https://artifact.ci.freebsd.org/snapshot/ helps avoid as many builds being involved in exploring. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Feb 25 06:16:54 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 4PNxPL4707z3vSmv for ; Sat, 25 Feb 2023 06:17:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4PNxPK2dTfz3rdR for ; Sat, 25 Feb 2023 06:17:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="uSMVE/QF"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 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=1677305826; bh=qozNXE5SzDhoj+WFnkJScpXERmiWhtLjyE4q3BK6v+Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=uSMVE/QF4Mtagz/hiG5QBekXl9/7BYuOOq8cyVqT945j1Qk8UJg0mXfp2YRCFkmuaaAhUwq4I0mztoWtzR5o+dygLfBcNeHUayFzV6m4Dm0m4zICYu+50pIoHOe5Vdevl5TW2qGFpglmo6KcOvKRb03z7bMvkT2QkUQz1xjVl+Bhl8DgNHNeMnXEMioMojte3uy2mrsk9FkCHYDFpCgwjdPHpXSpE/ePsghhRiD03qNzRCCfNGyK4WZ3/fem5sfncaVFh8SFpN7sCHDTuGg6SDYmz6PKxyYjd0b41pmvF0Fqx4amH28vgLPsOqrSjcnpm0BWWJuCBOrBcmv7E5TBYw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677305826; bh=fy/RhyTlC9cUuNqsBrcpYexMHmR1dj41tS7oFF55Zwx=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qRFKOfH3coduod5J/SSG1taUkZYLtIqkFfyIznT2YJ17h9j/w+UvDx4vVAMxbV9FKktx9/YfXzJyBBDNKmGnYiK3LhL+cXnFQdlxVFGQRFI6VWnBlmeb78jqMA4YCnsDDsCq2yAjCiHSSk+AxhkXyz/DJZJQJUkSot7k6xtOz0HyxUPmOZYjXTyu/qjKd959sLeI1iP+mBIR0CpEPE2ahKF0k7DbpSMN6YvCja8/iCdxvUAoRZDyu6xdUZX7UAC56AtGatI+9vBAdx6ZoUV32KROibXJ5b7HF4L8tuQMgyP1wOhoTVO1KM6rFL0GfeopqPMC7W8827zeOsIGF9X39A== X-YMail-OSG: yfK7ijEVM1kHzha_1PHShfcRX2iWpCvn9RiI6bK8aRpmk5EZx0n1ew9Y37dbMlm DEA96YEpvFUaSRF.Zk96EyYR68HJDkniFn1yz6L5MfoF02cCqZM3BkQgRP0QZ_WG3qJkX6hcsEAD ScXzTtF5OiCnR7gLa2GBbnqilYlkw37k.atInklq2CCnzlVQfHwhZlneB67sNSiZY_25Qumzpe3A ooGzh.fYR25WpaXC_J0HvwsGOxbTOrNM1CjHkMiaAmh.ECK.XR1kB0GE.pvCVeNSy3dcn7rZM6DJ sovxjtHBCAdKf6p08OhMn6LQgoYxsjc4hXFoCuWu1MF7oMCzbdtRZpBsdRCuI8iWxYz4TuiYHDcW UnQyt3nnIcWXyRSYZnI167QwOpzxFt9V3nf0YWb2TIvtVoxdNZHbs9_G0.dE3yXlOvBmFuiY4LUI Ea0Oa96fI1_bV_dGH2ZSAX7gQylD1LQjsnDpYsVZcZiDXtLRvZn1bhhcdDXy8XspBqiL4BGm1Gt8 lvjMQj63EV8CXlDvJrRb.2lW_knDWI7ygTOXnxisZuWptZVKLmVLSenzaj2qpyNVlGczW7ecA7gg Zj5rW1ZYphAay3uaQ7ChxUzZdKw3jDgyg6B331n8tE9B0eYeRST6QEHcTR72Rb1MWs.zHK1zpC70 R1PptcOucp7iqhOe.5vCE00obJeRywc0Mamis9ny2tDm3aEYQJon9_vLyVTNW2fA0yWCyt76Hrih AzzkG4ZvjnHRkbgUt2Q6IR67du4Qx7C7Ga61hSJuM2FK49ObjyFPgYhk3RlDmqD8PCIDj.ED1CtL 0vjRN0zyOrGS87baHW06qG39O6fdVAePwAwx.M3BmC8j9heRuZNopQzOXmS_UUdJeA7Xkefyyr7m _wNxQDR_wxUrrKRM6PPO3RnTtHbK2Fgd3NhSEjPGAoskHI3Fl.RNGNe0NrDbLkMC4DBjx1WhKH2A n55fCdSaJBClEcUXmIDEuBtblQ5kMYcBGx12dHQr2V7Jc7DD2WgY4OE83LKc3t2ZBz.3ENPp.VTq SvOMaYTDnXDfGYT.dcyS27myjnu5DUy1XOmqXT5jWzPp2Ql15tDy9oH0tTDpKv.uzpYR1yAmmd3u 2SU2a2W3vQVz1N1s7chD9A5cnC0.fLWhY50i1vxyHyiJHhfRKUw2sYDenQZSTPY.A8v_KimpYL.v cjmHMTPwryGgRAhWhVQUWxJVmYvlJgbvMQcg9juzQCSRsiklAy19usaz0ETxFUWMZ4aI00bCT6mN VWq1eMHHI3ylhw0uVTuDHfg23fsFEFZxKwOdLbFAFQWLhOZrgdL8l20.MAkafc3GWRzYFMnqS17X hVkbOwDTO5r4zF8ho4Ia4YCYdB_1_RPNQf_dSp8BiifYfSNLBoILAPpheTz5cVIQC0oSC3rQY7RX G4ooAb2j2LY8zuZ0dckmNSuAo9N_d96zhTjdH4VhH9TjRyEdXSNRymreXJHMVA6gGavgMsyf9_w3 AP8v9Qce6Plzm0wIQkIdhcappTxfgqPyPeEHrZAOyhmpzw4KbXfTpGbuvwAYOIzguVMpC1GixwGb jvdvHOyNj8MoaojFaZLB_7L3IwMahlYkKCTLqFtatr7wyKyNjoYjaEOuA7Z4udhIbouN792d5VbF IaY1dVR1V.6CQF1_Zhab4OUpOOSVl3BJl_LmPBqpsgUdmYb80IchZ6aL05tDNRkqIK8lZMqmZEGi X51bn8Cz.IwIniWpmi4f5vCeai1XvymansN7cVHf2NPHq1veS_sDm7gwDZuqikMWahco3dMfQj_z YYDPQTRlJPQPXqsqYhLDNkW1o78rnVaxngIxXigskZubAEm6T_flSJFYBc4A_o5Zul8s_rMIiQcc iOiBkeNpmApZ6jchdHtqpXJXx2sx18qDf1HzmsAlInuVpZacM4gtdtLdwU.XZ07T1KGOBZ_GheZk xY6QdQRtj5CUYoAe3wRE504XHT_sgFgfnonEj7w3516pGRISOSpNWXeaARa6VnKBVJYBNpXOsLB7 5iQxH6HtWkBwUR8do9FR7nBLfpl.hO4S9ZstjADjYN1Q32Ldlog0oY9IBmmK5j3x3hm_5FCkt8d8 ByioK_gDMnk0D3i5QKnYC8XhFtj5B5rAoFcwmATMo6_Jdq_Rks5fAhgnUHkl3tat61Z7P_lj72Ul CO4j9.i.nDghUQlRw16KVX2dJwSocvbOepSE7Y_2TzJ.f7SDaHUWw44R8UgYxAaBpf0WzVuCBSXA e2xJuj8MQh7yaDMEpQaKBNqFlR.uvmAWUif3krNDjgF4faxVQDcfPORL_GeihUpsAiXyp7euY6nd kRSKB X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 25 Feb 2023 06:17:06 +0000 Received: by hermes--production-gq1-655ddccc9-wkdtk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID eba9700fc7f2adb8a94e08203523831f; Sat, 25 Feb 2023 06:17:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 \(3731.400.51.1.1\)) Subject: Re: reboot broken on RPi4 on main [breaks at git: e6cf1a0826c9 - main - physmem: add ram0 pseudo-driver] From: Mark Millard In-Reply-To: <9EA91B94-87E4-47B8-A4E2-60D556E64276@yahoo.com> Date: Fri, 24 Feb 2023 22:16:54 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <4FCD4987-6DAF-4889-B684-B6E464F41144@yahoo.com> References: <9EA91B94-87E4-47B8-A4E2-60D556E64276@yahoo.com> To: Mike Karels , Mitchell Horne X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.25 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.75)[-0.747]; 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]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4PNxPK2dTfz3rdR X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N [The first main version to not reboot RPi4B's is: git: e6cf1a0826c9 - main - physmem: add ram0 pseudo-driver Mitchell = Horne ] On Feb 24, 2023, at 17:45, Mark Millard wrote: > On Feb 24, 2023, at 15:18, Mark Millard wrote: >=20 >> On Feb 23, 2023, at 14:01, Mike Karels wrote: >>=20 >>> Reboot (shutdown -r) is hanging on RPi4 on main as of today=E2=80=99s = snapshot. >>> It hangs after printing the Uptime. The initial bootstrap and boot = from >>> power-up work. I haven=E2=80=99t tested a snapshot since Jan 1, so = I=E2=80=99m not sure >>> when it stopped working. Any ideas what might have broken it? I = can bisect >>> the recent snapshots if nothing else. >>>=20 >>> 13.2-BETA2 works, however. >>=20 >> For reference . . . >>=20 >> While it is a personal build instead of a snapshot, >> I see the "shutdown -r now" hang problem for my build >> based on: >>=20 >> # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ >> d04c86717c8c (HEAD -> main, freebsd/main, freebsd/HEAD) bsd.sys.mk: = Add NO_WSTRICT_PROTOTYPES like in kernel >> branch: main >> merge-base: d04c86717c8ca3aa1bd9d8927a37a1f5443925b5 >> merge-base: CommitDate: 2023-02-19 07:02:12 +0000 >> n261026 (--first-parent --count for merge-base) >>=20 >> The context has a "B0T" 8 GiByte RPi4B. >=20 > For the artifact builds available for arm64, testing > the kernels: >=20 > The last that has "shutdown -r now" working on the RPi4B I'm using: >=20 > =E2=80=A2 git: 8b418c83d175 - main - cp: Adjust the sparse file = tests. Dag-Erling Sm=C3=B8rgrav > ( = https://artifact.ci.freebsd.org/snapshot/main/8b418c83d175fde3b1f65210509d= dcf2ac248d9f/arm64/aarch64/kernel.txz ) >=20 > No arm64 artifacts after that until . . . >=20 > The first that has "shutdown -r now" failing on the same RPi4B: >=20 > =E2=80=A2 git: ded5f2954e1a - main - nfsd: Fix handling of the = error case for nfsvno_open Rick Macklem > ( = https://artifact.ci.freebsd.org/snapshot/main/ded5f2954e1a1bb7748646888938= af767ee6257a/arm64/aarch64/kernel.txz ) >=20 > So the range is limited to (including those end points): > (All are 2023-Feb-08 artifact builds.) >=20 > =E2=80=A2 git: 8b418c83d175 - main - cp: Adjust the sparse file = tests. Dag-Erling Sm=C3=B8rgrav=20 > =E2=80=A2 git: 87d405eab911 - main - iommu_gas: initialize = start_gap as first node Doug Moore=20 > =E2=80=A2 git: 8c784bb8cf36 - main - lua: Update to 5.4.4 Warner = Losh=20 > =E2=80=A2 git: 5fff09660e06 - main - geli: split the initalization = of HMAC Gordon Tetlow=20 > =E2=80=A2 git: 81ad626541db - main - Merge llvm-project main = llvmorg-15-init-15358-g53dc0f10787 Dimitry Andric=20 > =E2=80=A2 git: 753f127f3ace - main - Merge llvm-project main = llvmorg-15-init-16436-g18a6ab5b8d1f Dimitry Andric=20 > =E2=80=A2 git: fcaf7f8644a9 - main - Merge llvm-project main = llvmorg-15-init-17485-ga3e38b4a206b Dimitry Andric=20 > =E2=80=A2 git: 972a253a57b6 - main - Merge llvm-project main = llvmorg-15-init-17826-g1f8ae9d7e7e4 Dimitry Andric=20 > =E2=80=A2 git: 61cfbce3347e - main - Merge llvm-project = release/15.x llvmorg-15.0.0-rc2-40-gfbd2950d8d0d Dimitry Andric=20 > =E2=80=A2 git: a4a491e2238b - main - Merge llvm-project = release/15.x llvmorg-15.0.0-9-g1c73596d3454 Dimitry Andric=20 > =E2=80=A2 git: 6246ae0b85d8 - main - Merge llvm-project = release/15.x llvmorg-15.0.2-10-gf3c5289e7846 Dimitry Andric=20 > =E2=80=A2 git: f3fd488f1e19 - main - Merge llvm-project = release/15.x llvmorg-15.0.6-0-g088f33605d8a Dimitry Andric=20 > =E2=80=A2 git: 50d7464c3fe6 - main - Merge llvm-project = release/15.x llvmorg-15.0.7-0-g8dfdcc7b7bf6 Dimitry Andric=20 > =E2=80=A2 git: 3264f6b88fce - main - Bump __FreeBSD_version for = llvm 15.0.7 merge Dimitry Andric=20 > =E2=80=A2 git: 89a072d11cd2 - main - Makefile.amd64: remove = construct that serves no purpose Warner Losh=20 > =E2=80=A2 git: ae1dca798e0f - main - e1000: fix I219 hang on reset = Kevin Bowling=20 > =E2=80=A2 git: 647f2d2bc0cb - main - e1000: bump driver version = Kevin Bowling=20 > =E2=80=A2 git: 48bfd3597654 - main - Add nproc(1) Mateusz Guzik=20 > =E2=80=A2 git: 1d03c3578d05 - main - arm: add an interrupt rman to = nexus Mitchell Horne=20 My build of the above version works for "shutdown -r now". > =E2=80=A2 git: f9bdaab95ec4 - main - ofwbus: remove handling of = resources from ofwbus Mitchell Horne=20 My build of the above version works for "shutdown -r now". It is the last version to do so. > =E2=80=A2 git: e6cf1a0826c9 - main - physmem: add ram0 = pseudo-driver Mitchell Horne =20 My build of the above version fails for "shutdown -r now": hang-up just after Uptime: . . . message. > =E2=80=A2 git: fa3f6655421f - main - netmap: drop redundant if_mtu = assignment Vincenzo Maffione=20 > =E2=80=A2 git: ded5f2954e1a - main - nfsd: Fix handling of the = error case for nfsvno_open Rick Macklem >=20 > . . . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Feb 25 09:23:58 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 4PP1YC3p34z3svrQ for ; Sat, 25 Feb 2023 09:24:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (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 4PP1YB0s3Jz48vB for ; Sat, 25 Feb 2023 09:24:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=EtSmHeh5; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 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=1677317052; bh=IAv/yWOLyWNTLTKz/5gT3MREDx2UQtrdgVp/kmZX5Pk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=EtSmHeh5mYJ5FchfZ5Ib/IdhQUVsKqh02NzJMXTW1Uin9xeB59pNdAyvAZ59M+Esl9/ds0oKhHMifOz52I5VUh0ULwcCUq7PfeLaLmVJiQHYNTlHC565WF1ecRSiX3ni44vf5Ww7NDg9HD8ebzWQR20TUiyX5Yf8BbgUXCxflQEfGeSHJQOawQOJwQF6EaD04a3BcJee1Nz7mu75SzqJIKNLmyaL1ZyiymKLqgBmc6pgn0YhQzkkDHGjJJzS52eqFFqCVxyVP2+3t0A///0PPuGxkmMKp0MUXVlOSeD5Q2RowTEpnK9yntEy9ZApHwEhHHikINOpQXxINHzUn5t9YA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677317052; bh=k+uP2yXH0U+flxBwGm83UdDqeWuZXj79plTioPgIqET=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=GZ6zJr1fynlrKijS8Se7a/MooTJ7d+mIv3rXpEKrAIvWFkVpSBbj/vfxj2UJ7Yy/xohAd1oYI3KrTL+XxYo7fxEdB2ACS6ogl1wcaBiuWIWkjqIfnWV8qZQ4LjCYblGtGX/u0RHlbjwwwSxdffwV3E8qXS7EKSZrQnf2XJI7LqNKk7zTvIQhV8NmAQqAPnXba88OzDo7K/5sKPn2EONg+LawDHVchw6yf6P/OeQ5ksfmosAH7js96aXpM7PLpka85HGxsWP4H7lEAUcIaD0Yn2vW84dFgR4iBqSYGIYfHoxG6p7wF2Z2hSJNG5xJEYvTfU7WVpTYfHTfW6RbVlsAtA== X-YMail-OSG: SX1.cusVM1lfjE9vUBLWDgiiePt2bJqqzvVwB1OhlYl1iFipiBsqpcI7lnDnW3j p3NHie9DmSsTlnjJJhNfy.um3obad4uxUx19TofJdVnuqvxHzlLDJj73AA585tDdjy0wmv90GXnr meCwrPZsVKjKzuZ9KAojVXjkK7FI96oj4V2egnFd_L1xDBKrG4pgtSf2510lsjWwm6AFjejf1jIi 6wfgqlwfY6t0bksTHz3CaBtOT69zZBiV7HvHlEUJawk8COBhkZc3xPdDyMyjQ0pjgBoMMgNKL5eo B5AWJH_mZbhvsAhJnDb.xohqBMVqhUHLgdhVIiw0Eh3vBrR..NNey54D0LaMxiCSdSJDdGjZB8lB 0AQFBaG5ZuQKXEcDwoafsndjDH.5Z2DTSXFkJ76tDzi1zkk7XUyNejTpgFx508hBqW8ztXyNmERm PDUh4Sad2XGuGgNHECwE4IhqVrtBKRNoM4RYqfNHpBjYXUUzI2GMoFqtwh8aUvfG7cCiT_gO2v.x UpqbAOjykxfZj1kOvZwSs0ljyydvGDye0w_4619a.1Lk9EGDejm0zG_IER0NbVu4ULtIFA6oOD4C rBB5Rn.sUrPGCbo5E4lGkOhR7ugoslU2CCrLyt3GeJB7aARD6fgKvQQv2Fxm.8bF7.TY72eSxuLW XZf.Sl7US_FaYuP27ZGZNUVMZKv1jR1Nx_Reuib9cuvQms9Y29NVIqo88T0Zu.NjweH4yQBK7eJf FbP8gl2koZKr7RKO4p5k2UdlOH68izSYszqaR5GP6cpAsukSd3RAQ_KTh9Ple3HQL7x.qbWqIz_b FP4m8pB.xNyJYNoWomojXfuGEVlLZ8SYkBEYX4KGJJwKURlV8MxX1A6g9EWeGhMgV.an.4z6J.5N kinYWXg0kCkSHRSlGjAVlDWnlGzSQQNFLlszFe3kurGD7dl73kmomCAC41m4QncOF5PN8KIQjzsT sA0pv64CickPqKq52K6SXLlyZS3HO9YKMkyYlLxZA.zGLUgIWV8t3HtVnScrKd4vrAcrbYuMpL59 SelXl4lLlY6N2eLu1ZawonDm6X1hdfFM5aorMh2GBJt4cMg.ySKwAYri6iQOpzV81P2QbWe9gSYL dYSNdb6PkgLpBLm9QpdKhajqsD_YmnXNcw8BFs6fN1a.kY3BOSrwiDoHAnAsCjUZQf2Ja2xA2qIQ bBYUcDhaat9V9k32wUt0Jq2ESDLpGgQmzQbUxQt2RnuX6XRJO2eetogn.dbHWUGCk0ExZBDLxh2e PCAC0NxnvEIFn5nYppi.gNrbQxqjMB8Pl_bx.Ci0SpbhFqpI61Iqd3UW4C5jQti.uY1OdxGVT_XM JMd51YrHEw7qB.GksL74DyQFre226tlMXCU.5sdvbIPGy1HZ3SQqySl17R4iGetyfDavXmZga0UW zcJdVPKks7UtQ0VQZOM4EBaS3uGH4qDE4D9NuCnVTan6kdZzh_SOHgZxylf4CJt6Xg4k9a4GVQu9 GqiOJxC8brdpWJwT.E02SPiNUpRKUeqJrXKGojgEnqDLWskJA3wQpXHYfhhN7FbLqyEluVKMF2B4 o_9eC4GoKw9eiGgenCbLJhXhaVvZ727yKQk40sWLUaONHcGpnoVvv_PlKQuoP3N6g.r_KWCEHxBg SmfSMPysG6kTpFYUp_XvYZ2T397Iw4mmKYi1H7BnUNyjgU01Q3dg1zt6Ha8XXNqba8IfyJMFnJCK 4Ls_.gQfMisaYdnVz4o0hpoVErkrIG8FAznlD9YYa72JpuzLSGX0PlG4gwh6L1TmGetUx3dRyQAA qmgfBhyUWAUyj8daJZ7Lp.ykDwzRioUBs125ozeiDYovH3xz7mnsH_FiwwSWL7itIde1Mwgv_DAq zxGMbdE8DD0qUm6sxbtHTiHIenitBukkuXRCMbzLai8myeIE.Jfnb0WiwA7ghkgbNLqvGjRzMpXL CegidVZgJocJWKHx80twE7uF0FiLbma_QiTMOTj9EfgM1Bs8xW1cW6AWaNyNKb1vE3D5su62MSLC MFe1hlesTF51Tw15FC1Su7EemLkeJ4FrVbtnZ.zy62AgAZujl4qu70lBr_Qqkzf8S10bBhcP1PpN UY_lAVyIDtXHRThMse4MW7u29u3pPsipS2O3ZGhG6P2h1U4u0xuQ3h3Pyl61uGeRJfYEjNEaeSWw hsVkoNROdZRpBhYH2alGRCm0gQxoKXQ_HP.tqv_1YrGh7CxEld7az7CHaCY1WO94.VpZOVwBUqRg klliuznUvhSOejxX30hLS5sESh4wumqNPZDbN1lQHc2b5XsquC9OKCTvDO8dYEKXgj0zaOQTAMy6 aSz10tA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 25 Feb 2023 09:24:12 +0000 Received: by hermes--production-ne1-746bc6c6c4-z5pmw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8141eca147f28839191e5a1dc5d2025f; Sat, 25 Feb 2023 09:24:10 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 \(3731.400.51.1.1\)) Subject: Re: reboot broken on RPi4 on main [breaks at git: e6cf1a0826c9 - main - physmem: add ram0 pseudo-driver] From: Mark Millard In-Reply-To: <4FCD4987-6DAF-4889-B684-B6E464F41144@yahoo.com> Date: Sat, 25 Feb 2023 01:23:58 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <9EA91B94-87E4-47B8-A4E2-60D556E64276@yahoo.com> <4FCD4987-6DAF-4889-B684-B6E464F41144@yahoo.com> To: Mike Karels , Mitchell Horne X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.27 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.77)[-0.765]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.204:from] X-Rspamd-Queue-Id: 4PP1YB0s3Jz48vB X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Feb 24, 2023, at 22:16, Mark Millard wrote: > [The first main version to not reboot RPi4B's is: > git: e6cf1a0826c9 - main - physmem: add ram0 pseudo-driver Mitchell = Horne > ] >=20 > On Feb 24, 2023, at 17:45, Mark Millard wrote: >=20 >> On Feb 24, 2023, at 15:18, Mark Millard wrote: >>=20 >>> On Feb 23, 2023, at 14:01, Mike Karels wrote: >>>=20 >>>> Reboot (shutdown -r) is hanging on RPi4 on main as of today=E2=80=99s= snapshot. >>>> It hangs after printing the Uptime. The initial bootstrap and boot = from >>>> power-up work. I haven=E2=80=99t tested a snapshot since Jan 1, so = I=E2=80=99m not sure >>>> when it stopped working. Any ideas what might have broken it? I = can bisect >>>> the recent snapshots if nothing else. >>>>=20 >>>> 13.2-BETA2 works, however. >>>=20 >>> For reference . . . >>>=20 >>> While it is a personal build instead of a snapshot, >>> I see the "shutdown -r now" hang problem for my build >>> based on: >>>=20 >>> # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ >>> d04c86717c8c (HEAD -> main, freebsd/main, freebsd/HEAD) bsd.sys.mk: = Add NO_WSTRICT_PROTOTYPES like in kernel >>> branch: main >>> merge-base: d04c86717c8ca3aa1bd9d8927a37a1f5443925b5 >>> merge-base: CommitDate: 2023-02-19 07:02:12 +0000 >>> n261026 (--first-parent --count for merge-base) >>>=20 >>> The context has a "B0T" 8 GiByte RPi4B. >>=20 >> For the artifact builds available for arm64, testing >> the kernels: >>=20 >> The last that has "shutdown -r now" working on the RPi4B I'm using: >>=20 >> =E2=80=A2 git: 8b418c83d175 - main - cp: Adjust the sparse file = tests. Dag-Erling Sm=C3=B8rgrav >> ( = https://artifact.ci.freebsd.org/snapshot/main/8b418c83d175fde3b1f65210509d= dcf2ac248d9f/arm64/aarch64/kernel.txz ) >>=20 >> No arm64 artifacts after that until . . . >>=20 >> The first that has "shutdown -r now" failing on the same RPi4B: >>=20 >> =E2=80=A2 git: ded5f2954e1a - main - nfsd: Fix handling of the = error case for nfsvno_open Rick Macklem >> ( = https://artifact.ci.freebsd.org/snapshot/main/ded5f2954e1a1bb7748646888938= af767ee6257a/arm64/aarch64/kernel.txz ) >>=20 >> So the range is limited to (including those end points): >> (All are 2023-Feb-08 artifact builds.) >>=20 >> =E2=80=A2 git: 8b418c83d175 - main - cp: Adjust the sparse file = tests. Dag-Erling Sm=C3=B8rgrav=20 >> =E2=80=A2 git: 87d405eab911 - main - iommu_gas: initialize = start_gap as first node Doug Moore=20 >> =E2=80=A2 git: 8c784bb8cf36 - main - lua: Update to 5.4.4 Warner = Losh=20 >> =E2=80=A2 git: 5fff09660e06 - main - geli: split the initalization = of HMAC Gordon Tetlow=20 >> =E2=80=A2 git: 81ad626541db - main - Merge llvm-project main = llvmorg-15-init-15358-g53dc0f10787 Dimitry Andric=20 >> =E2=80=A2 git: 753f127f3ace - main - Merge llvm-project main = llvmorg-15-init-16436-g18a6ab5b8d1f Dimitry Andric=20 >> =E2=80=A2 git: fcaf7f8644a9 - main - Merge llvm-project main = llvmorg-15-init-17485-ga3e38b4a206b Dimitry Andric=20 >> =E2=80=A2 git: 972a253a57b6 - main - Merge llvm-project main = llvmorg-15-init-17826-g1f8ae9d7e7e4 Dimitry Andric=20 >> =E2=80=A2 git: 61cfbce3347e - main - Merge llvm-project = release/15.x llvmorg-15.0.0-rc2-40-gfbd2950d8d0d Dimitry Andric=20 >> =E2=80=A2 git: a4a491e2238b - main - Merge llvm-project = release/15.x llvmorg-15.0.0-9-g1c73596d3454 Dimitry Andric=20 >> =E2=80=A2 git: 6246ae0b85d8 - main - Merge llvm-project = release/15.x llvmorg-15.0.2-10-gf3c5289e7846 Dimitry Andric=20 >> =E2=80=A2 git: f3fd488f1e19 - main - Merge llvm-project = release/15.x llvmorg-15.0.6-0-g088f33605d8a Dimitry Andric=20 >> =E2=80=A2 git: 50d7464c3fe6 - main - Merge llvm-project = release/15.x llvmorg-15.0.7-0-g8dfdcc7b7bf6 Dimitry Andric=20 >> =E2=80=A2 git: 3264f6b88fce - main - Bump __FreeBSD_version for = llvm 15.0.7 merge Dimitry Andric=20 >> =E2=80=A2 git: 89a072d11cd2 - main - Makefile.amd64: remove = construct that serves no purpose Warner Losh=20 >> =E2=80=A2 git: ae1dca798e0f - main - e1000: fix I219 hang on reset = Kevin Bowling=20 >> =E2=80=A2 git: 647f2d2bc0cb - main - e1000: bump driver version = Kevin Bowling=20 >> =E2=80=A2 git: 48bfd3597654 - main - Add nproc(1) Mateusz Guzik=20 >> =E2=80=A2 git: 1d03c3578d05 - main - arm: add an interrupt rman to = nexus Mitchell Horne=20 >=20 > My build of the above version works for "shutdown -r now". >=20 >> =E2=80=A2 git: f9bdaab95ec4 - main - ofwbus: remove handling of = resources from ofwbus Mitchell Horne=20 >=20 > My build of the above version works for "shutdown -r now". > It is the last version to do so. >=20 >> =E2=80=A2 git: e6cf1a0826c9 - main - physmem: add ram0 = pseudo-driver Mitchell Horne =20 >=20 > My build of the above version fails for "shutdown -r now": > hang-up just after Uptime: . . . message. >=20 >> =E2=80=A2 git: fa3f6655421f - main - netmap: drop redundant if_mtu = assignment Vincenzo Maffione=20 >> =E2=80=A2 git: ded5f2954e1a - main - nfsd: Fix handling of the = error case for nfsvno_open Rick Macklem >>=20 >> . . . >=20 >=20 The following from boot -v looks somewhat odd: ram0: reserving memory region: 2000-7ef0000 ram0: reserving memory region: 7f10000-31c00000 ram0: reserving memory region: 331d7000-39c2a000 ram0: reserving memory region: 39c2b000-39c2e000 ram0: reserving memory region: 39c2f000-39c30000 ram0: reserving memory region: 39c32000-39c33000 ram0: reserving memory region: 39c37000-3b050000 ram0: reserving memory region: 3b060000-3b300000 ram0: reserving memory region: 40000000-fc000000 ram0: reserving excluded region: 0-1fff ram0: reserving excluded region: 7ef0000-7f0ffff ram0: reserving excluded region: 31c00000-331d6fff ram0: reserving excluded region: 39c2a000-39c2afff ram0: reserving excluded region: 39c2e000-39c2efff ram0: reserving excluded region: 39c30000-39c31fff ram0: reserving excluded region: 39c33000-39c36fff ram0: reserving excluded region: 3b050000-3b05ffff ram0: reserving excluded region: 3ee5c000-3ee5cfff ram0: reserving excluded region: 3ee5c000-3ee5cfff ram0: failed to reserve region ram0: reserving excluded region: fe100000-fe100fff Possible oddities (4 GiByte RPi4B example): Nothing covers any part of [3b300000,3ee5c000) . Exclusion [3ee5c000-3ee5cfff] is repeated. (Related to the above?) The "failed to reserve region" notice. (Related to repetition?) Nothing covers any part of [fc000000,fe100000) . Nothing covers any part of [fe101000,ffffffff] . (The 2 different styles of specifying high bounds reads oddly.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Feb 25 09:58:15 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 4PP2Jl5W1pz3sxqk for ; Sat, 25 Feb 2023 09:58:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (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 4PP2Jk18mcz4F1k for ; Sat, 25 Feb 2023 09:58:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=YmjA3yXJ; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.84 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=1677319107; bh=H/ZJRrhtgHkn/Z6xTFDyl6bJDa6w5O0nS/5HuaEla2o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YmjA3yXJodAFs/ZHiItCQwp4yP5wc/UJP+uTfIqssz903Nea0YyjMKXtrsxhpqzyndtk27Agq+J+S//l26jVtSkvxFxGkqZCGne3QJShuXbXInj7KWBTv/0Kunr7HRUYVxAkU/G4Fo9EOn32Emi8lK2JEQWAlf4HDOKHiIeb35WyHRs4MT5kc4pAZuAJLT/gIdKadCuS3IU7Y4NvqzU56o2D9NtDeRBuQ0z/xgkFhb5ZWy/yaNtlCq4Tlc5mN1B1PhHYY6LYjbvvd2Ln+7jxb1rMZ4hN7BF9/+McPh8TGjTYS+BUdQdJDtkRx5fD0Ap9R19mWH4/+efMABFe7ZOrOA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677319107; bh=o0bU5Dj+DbWk4pSB7drXFBsWfAPGXYHxNtxav32dvfj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HvdaIzHbsXuQKGTlnL+6/O3sKjfhKvBHhgxR5j7UgE9NsqN236G9so3w6NrSnzpAH8R51s7WzMxe8jmaEzrO2KUJHdAA5rY+TNVFU0G0QC4jZNLHldNlkiTgpC/U8ew04gh8s5KqlMZTwWG32FRGNhb58JYmpDFQGmJPIjgQ2wFn3UNCSLjPqjjVfgI0MAA56ZGRZFepPhZOeyDGrZd44tB7AuCuFLhbZS6Y3uwN0dMRPXCPzQXwrTjl/oCvJfqTPnNKrg3VvO8pMEzLQcmASoiLOyPzd5H2vxgmQipkzqBCu4IrY+OWj7VdIl6i1/4XqqhMbd9os2hY6TFquMOuYg== X-YMail-OSG: kYDTG4MVM1k0JBx7sMAvXVb1Iv9rkI9Ns1P1CJ772WmqjQBkgYfzqQoJaJI3ah9 h1BXKel65tYRKh1ufL0Vvuy60jeJhFQs72l1xzqA9bolQBEWqxTeC7ub7uSqAJoa7EFTs3P4P.sA 92HIc7ePiFE_2C5VeuRIksV_tv0GZjvKDafRYS4vRsP2Ng3Mp3jg8nsaqo_6GMg_54tVYdn4ftnY B7Witdr0pglKMOb5zdJV79QZpXItTUiRTDBTIAeNG.nP9O5svx15tM7zyDdtBfQfcfgAcxa3Dqs9 ErQeqBUivcwYA.uAaDZsDBvP7124PtbezI1zIkHrWzkhGquhqFF9tOyKJW2HRXAhwlizs9nmBy4w lLIidXyQK76d9OOT3aRKBCI2PSwy2u930ZRusNJDpNYe0e6KMpoR8AGpg3E79Oy6WQ.Na_pOTzSw 6RdX8waTdow3wBF3YOVZ4sKLp20pYWaPmjqqkloj5UaIoKEULmOkDgOz4UcTCmL.IjOgIVTM2Uei 8u_8UpyZDQVjRebL32qI2iyYa5Z8imddTMDtrTqJB_U24sXwl1te7k8E12I0Rrs5U0Y9.gPWHPup FxCpd0rzwvsL4Xs_uLhuD6UMPYjTk3AOqCSH62m8JI4Cll9LJkpXdbG3Oi8E5375hvqargzTFmc. CeppR0aw1VESdaCewjR97ReklBoOUgE6cmbNTusN2BML4SYqemU6QmFOibDgKLNozhgMlfduZg9a 6nr1oUiNbMUiSn.WgXd_rxcpvVSg0N5h9Wh.heju5p9XqCg7WRrM8zNeDW1NC0ZQfkecBrAKJjHs V3ncJx7ue_uf7EfGGm78b_9LAnqbVavpArHnnoKXFwizacqaypCYH1VDE0y0tOQspsMrhamg52ZQ Qj9_WClfKoGs7lvu0Cyv2IuhO_rfCTl7uwrdSV0fHuc4kQD906S8vqgjnEtz56.nQwvlXHCIhMtT HveYlcNiWgGZAivExQ_WqYxPGez5XKgJmnKXZXB5eJ1PmI0jCxj0nTK4plqqX7E6gVyIob7M2iA7 RRv2ft9dwvyaqCQLjQhfGwRsRuV0.NukROxwzlTGzHhcP1Z3HiqmvTLJLhFmxCyO1glfvnJizDeR 5XmkapEulFLUvcJOZ.p6sLbPrPBlF4YctLXte.klOls2vuW2ehbg52wDwy.lajRTPA.Jg.H1Phts LdRzrjtljLsibHQhD9x5JZtmPR7YppQtzMjSrzEIG9LQ975s7TX0geYzXHdRrqAOQ9Lkv96Gu7y_ H8_pfVyyHfU8gmO8fL.GDnQ6VwXJ4Uh9YL7fD0ZjqiEPXS_Eq59kRvO56kZqofdGY3NDM_1s11wI Ebc5CtwqW_vYhGumCu0htR0kdqPfNYpJh97TUxZY.LdzDny_7BK6M7FCFdQaWCukQ9.e6ikYH28d aikvLHS86o9yBH.Y33BMf5CV0jZ_ug4s_1EaBPbWouSu6CGi3keWFjFo_8p.UD3KapYowyZ_L02i 2CBJivLJo_io6sK82uNDBkSjjeFjr.NIEL7YzoQLYEnmxi3muFWXmu3CWi114TGhND9pe71N_5u_ OMVIgNCtX0t31xCVX8fT0G4r9tne76hogE919sSnIVdN1sk7gJDpfkAWWQ3n2Muhx10xTAHa10Nx FGUAs7fVtJ6Hk2HzfvX.XTnOXZmLdRUjP_AheQWmaSYKgXJhpdlNGvJwtENgWOVgpXSHW8k3O7a4 .T32hh.2rjI0rzEBFNZK4npRBvVGD0_6xpzH0fttTMiLVGAAQh0n3XQyueORJcsbXqV.DdyGo6sQ 80a2RIAsCL4._ArdLSQbT.GUUrsj87dCXh6YHE2Ue7hMgsDGST9Uyo952S8_yVAdvxp.ANLZ_LPq piFL2ULiLnUTSgUkIhMRLFf9quwSX90rChEk9w.m_G0_58iajx5Gmn1ZpZoy2myc4CVNhW4rKdYd I8EbREw8D170tRsMunICwLr.ycSsbS9CjQPzVZNwuBfFjtHEi3dNZMcsHHaibpVU4c8dHgruMLfw Sw9hv1I0rL2jGqk.HX5.e9BKxSFtsV7W_F0Urh91PpX97ew9y.YUfHHcV_i88xvLU3aZ0RpvydoJ gy1dKl6J2.fP4n2tFcG8bS0zb4_4_7AEIaNDazCGysCtATxvBTzzZj7R4uFnoJGxX1TvsSWl2G2X 9kaVCCPnOTT6G1KvLCh3vXCu4OtDVXQD85vQ4aNhYaxEvVXf2Ub7kuhxFe36dtfy6tIOz3sKatm3 PUxQIm6S4klC9PoNoqQNYiEqR86kQSYu0_YMS1uKIfP6ZgQ4Fkay7T9CTz0D_dTVYm_vlEq.ozVV 8f_5QwQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 25 Feb 2023 09:58:27 +0000 Received: by hermes--production-gq1-655ddccc9-pfdbn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 197a9c9843bab38a8c045bb380df9c6f; Sat, 25 Feb 2023 09:58:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 \(3731.400.51.1.1\)) Subject: Re: reboot broken on RPi4 on main [breaks at git: e6cf1a0826c9 - main - physmem: add ram0 pseudo-driver] From: Mark Millard In-Reply-To: Date: Sat, 25 Feb 2023 01:58:15 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <9EA91B94-87E4-47B8-A4E2-60D556E64276@yahoo.com> <4FCD4987-6DAF-4889-B684-B6E464F41144@yahoo.com> To: Mike Karels , Mitchell Horne X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-3.33 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.83)[-0.831]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.84:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.84:from] X-Rspamd-Queue-Id: 4PP2Jk18mcz4F1k X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N [I probably should have also shown related output from earlier in the boot log.] On Feb 25, 2023, at 01:23, Mark Millard wrote: > On Feb 24, 2023, at 22:16, Mark Millard wrote: >=20 >> [The first main version to not reboot RPi4B's is: >> git: e6cf1a0826c9 - main - physmem: add ram0 pseudo-driver Mitchell = Horne >> ] >>=20 >> On Feb 24, 2023, at 17:45, Mark Millard wrote: >>=20 >>> On Feb 24, 2023, at 15:18, Mark Millard wrote: >>>=20 >>>> On Feb 23, 2023, at 14:01, Mike Karels wrote: >>>>=20 >>>>> Reboot (shutdown -r) is hanging on RPi4 on main as of today=E2=80=99= s snapshot. >>>>> It hangs after printing the Uptime. The initial bootstrap and = boot from >>>>> power-up work. I haven=E2=80=99t tested a snapshot since Jan 1, = so I=E2=80=99m not sure >>>>> when it stopped working. Any ideas what might have broken it? I = can bisect >>>>> the recent snapshots if nothing else. >>>>>=20 >>>>> 13.2-BETA2 works, however. >>>>=20 >>>> For reference . . . >>>>=20 >>>> While it is a personal build instead of a snapshot, >>>> I see the "shutdown -r now" hang problem for my build >>>> based on: >>>>=20 >>>> # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ >>>> d04c86717c8c (HEAD -> main, freebsd/main, freebsd/HEAD) bsd.sys.mk: = Add NO_WSTRICT_PROTOTYPES like in kernel >>>> branch: main >>>> merge-base: d04c86717c8ca3aa1bd9d8927a37a1f5443925b5 >>>> merge-base: CommitDate: 2023-02-19 07:02:12 +0000 >>>> n261026 (--first-parent --count for merge-base) >>>>=20 >>>> The context has a "B0T" 8 GiByte RPi4B. >>>=20 >>> For the artifact builds available for arm64, testing >>> the kernels: >>>=20 >>> The last that has "shutdown -r now" working on the RPi4B I'm using: >>>=20 >>> =E2=80=A2 git: 8b418c83d175 - main - cp: Adjust the sparse file = tests. Dag-Erling Sm=C3=B8rgrav >>> ( = https://artifact.ci.freebsd.org/snapshot/main/8b418c83d175fde3b1f65210509d= dcf2ac248d9f/arm64/aarch64/kernel.txz ) >>>=20 >>> No arm64 artifacts after that until . . . >>>=20 >>> The first that has "shutdown -r now" failing on the same RPi4B: >>>=20 >>> =E2=80=A2 git: ded5f2954e1a - main - nfsd: Fix handling of the = error case for nfsvno_open Rick Macklem >>> ( = https://artifact.ci.freebsd.org/snapshot/main/ded5f2954e1a1bb7748646888938= af767ee6257a/arm64/aarch64/kernel.txz ) >>>=20 >>> So the range is limited to (including those end points): >>> (All are 2023-Feb-08 artifact builds.) >>>=20 >>> =E2=80=A2 git: 8b418c83d175 - main - cp: Adjust the sparse file = tests. Dag-Erling Sm=C3=B8rgrav=20 >>> =E2=80=A2 git: 87d405eab911 - main - iommu_gas: initialize = start_gap as first node Doug Moore=20 >>> =E2=80=A2 git: 8c784bb8cf36 - main - lua: Update to 5.4.4 Warner = Losh=20 >>> =E2=80=A2 git: 5fff09660e06 - main - geli: split the initalization = of HMAC Gordon Tetlow=20 >>> =E2=80=A2 git: 81ad626541db - main - Merge llvm-project main = llvmorg-15-init-15358-g53dc0f10787 Dimitry Andric=20 >>> =E2=80=A2 git: 753f127f3ace - main - Merge llvm-project main = llvmorg-15-init-16436-g18a6ab5b8d1f Dimitry Andric=20 >>> =E2=80=A2 git: fcaf7f8644a9 - main - Merge llvm-project main = llvmorg-15-init-17485-ga3e38b4a206b Dimitry Andric=20 >>> =E2=80=A2 git: 972a253a57b6 - main - Merge llvm-project main = llvmorg-15-init-17826-g1f8ae9d7e7e4 Dimitry Andric=20 >>> =E2=80=A2 git: 61cfbce3347e - main - Merge llvm-project = release/15.x llvmorg-15.0.0-rc2-40-gfbd2950d8d0d Dimitry Andric=20 >>> =E2=80=A2 git: a4a491e2238b - main - Merge llvm-project = release/15.x llvmorg-15.0.0-9-g1c73596d3454 Dimitry Andric=20 >>> =E2=80=A2 git: 6246ae0b85d8 - main - Merge llvm-project = release/15.x llvmorg-15.0.2-10-gf3c5289e7846 Dimitry Andric=20 >>> =E2=80=A2 git: f3fd488f1e19 - main - Merge llvm-project = release/15.x llvmorg-15.0.6-0-g088f33605d8a Dimitry Andric=20 >>> =E2=80=A2 git: 50d7464c3fe6 - main - Merge llvm-project = release/15.x llvmorg-15.0.7-0-g8dfdcc7b7bf6 Dimitry Andric=20 >>> =E2=80=A2 git: 3264f6b88fce - main - Bump __FreeBSD_version for = llvm 15.0.7 merge Dimitry Andric=20 >>> =E2=80=A2 git: 89a072d11cd2 - main - Makefile.amd64: remove = construct that serves no purpose Warner Losh=20 >>> =E2=80=A2 git: ae1dca798e0f - main - e1000: fix I219 hang on reset = Kevin Bowling=20 >>> =E2=80=A2 git: 647f2d2bc0cb - main - e1000: bump driver version = Kevin Bowling=20 >>> =E2=80=A2 git: 48bfd3597654 - main - Add nproc(1) Mateusz Guzik=20 >>> =E2=80=A2 git: 1d03c3578d05 - main - arm: add an interrupt rman to = nexus Mitchell Horne=20 >>=20 >> My build of the above version works for "shutdown -r now". >>=20 >>> =E2=80=A2 git: f9bdaab95ec4 - main - ofwbus: remove handling of = resources from ofwbus Mitchell Horne=20 >>=20 >> My build of the above version works for "shutdown -r now". >> It is the last version to do so. >>=20 >>> =E2=80=A2 git: e6cf1a0826c9 - main - physmem: add ram0 = pseudo-driver Mitchell Horne =20 >>=20 >> My build of the above version fails for "shutdown -r now": >> hang-up just after Uptime: . . . message. >>=20 >>> =E2=80=A2 git: fa3f6655421f - main - netmap: drop redundant if_mtu = assignment Vincenzo Maffione=20 >>> =E2=80=A2 git: ded5f2954e1a - main - nfsd: Fix handling of the = error case for nfsvno_open Rick Macklem >>>=20 >>> . . . >>=20 >>=20 >=20 > The following from boot -v looks somewhat odd: >=20 > ram0: reserving memory region: 2000-7ef0000 > ram0: reserving memory region: 7f10000-31c00000 > ram0: reserving memory region: 331d7000-39c2a000 > ram0: reserving memory region: 39c2b000-39c2e000 > ram0: reserving memory region: 39c2f000-39c30000 > ram0: reserving memory region: 39c32000-39c33000 > ram0: reserving memory region: 39c37000-3b050000 > ram0: reserving memory region: 3b060000-3b300000 > ram0: reserving memory region: 40000000-fc000000 > ram0: reserving excluded region: 0-1fff > ram0: reserving excluded region: 7ef0000-7f0ffff > ram0: reserving excluded region: 31c00000-331d6fff > ram0: reserving excluded region: 39c2a000-39c2afff > ram0: reserving excluded region: 39c2e000-39c2efff > ram0: reserving excluded region: 39c30000-39c31fff > ram0: reserving excluded region: 39c33000-39c36fff > ram0: reserving excluded region: 3b050000-3b05ffff > ram0: reserving excluded region: 3ee5c000-3ee5cfff > ram0: reserving excluded region: 3ee5c000-3ee5cfff > ram0: failed to reserve region > ram0: reserving excluded region: fe100000-fe100fff >=20 > Possible oddities (4 GiByte RPi4B example): >=20 > Nothing covers any part of [3b300000,3ee5c000) . > Exclusion [3ee5c000-3ee5cfff] is repeated. (Related to the above?) > The "failed to reserve region" notice. (Related to repetition?) > Nothing covers any part of [fc000000,fe100000) . > Nothing covers any part of [fe101000,ffffffff] . >=20 > (The 2 different styles of specifying high bounds > reads oddly.) Related boot log material: Type Physical Virtual #Pages Attr Reserved 000000000000 000000000000 00000002 WB=20 ConventionalMemory 000000002000 000000002000 00007eee WB=20 ACPIReclaimMemory 000007ef0000 000007ef0000 00000020 WB=20 ConventionalMemory 000007f10000 000007f10000 00029c43 WB=20 LoaderData 000031b53000 000031b53000 00000001 WB=20 LoaderCode 000031b54000 000031b54000 00004000 WB=20 LoaderData 000035b54000 000035b54000 00004000 WB=20 LoaderCode 000039b54000 000039b54000 000000ce WB=20 BootServicesData 000039c22000 000039c22000 00000008 WB=20 RuntimeServicesData 000039c2a000 000039c2a000 00000001 WB RUNTIME BootServicesData 000039c2b000 000039c2b000 00000003 WB=20 RuntimeServicesData 000039c2e000 000039c2e000 00000001 WB RUNTIME BootServicesData 000039c2f000 000039c2f000 00000001 WB=20 RuntimeServicesData 000039c30000 000039c30000 00000002 WB RUNTIME BootServicesData 000039c32000 000039c32000 00000001 WB=20 RuntimeServicesData 000039c33000 000039c33000 00000004 WB RUNTIME BootServicesData 000039c37000 000039c37000 00000009 WB=20 BootServicesCode 000039c40000 000039c40000 00001410 WB=20 RuntimeServicesCode 00003b050000 00003b050000 00000010 WB RUNTIME BootServicesCode 00003b060000 00003b060000 000000a0 WB=20 BootServicesData 00003b100000 00003b100000 00000200 WB=20 Reserved 00003ee5c000 00003ee5c000 00000001 WB=20 BootServicesData 000040000000 000040000000 000bc000 WB=20 MemoryMappedIO 0000fe100000 0000fe100000 00000001 RUNTIME Physical memory chunk(s): 0x00002000 - 0x3b2fffff, 946 MB ( 242430 pages) 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages) Excluded memory regions: 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc=20 0x07ef0000 - 0x07f0ffff, 0 MB ( 32 pages) NoAlloc=20 0x31c00000 - 0x331d6fff, 21 MB ( 5591 pages) NoAlloc=20 0x39c2a000 - 0x39c2afff, 0 MB ( 1 pages) NoAlloc=20 0x39c2e000 - 0x39c2efff, 0 MB ( 1 pages) NoAlloc=20 0x39c30000 - 0x39c31fff, 0 MB ( 2 pages) NoAlloc=20 0x39c33000 - 0x39c36fff, 0 MB ( 4 pages) NoAlloc=20 0x3b050000 - 0x3b05ffff, 0 MB ( 16 pages) NoAlloc=20 0x3ee5c000 - 0x3ee5cfff, 0 MB ( 1 pages) NoAlloc NoDump 0x3ee5c000 - 0x3ee5cfff, 0 MB ( 1 pages) NoAlloc=20 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=20 and: Physical memory chunk(s): 0x00000000002000 - 0x00000007eeffff, 133095424 bytes (32494 pages) 0x00000007f10000 - 0x00000031bfffff, 701431808 bytes (171248 pages) 0x000000331d7000 - 0x00000039c29fff, 111489024 bytes (27219 pages) 0x00000039c2b000 - 0x00000039c2dfff, 12288 bytes (3 pages) 0x00000039c2f000 - 0x00000039c2ffff, 4096 bytes (1 pages) 0x00000039c32000 - 0x00000039c32fff, 4096 bytes (1 pages) 0x00000039c37000 - 0x0000003b04ffff, 21073920 bytes (5145 pages) 0x0000003b060000 - 0x0000003b2fffff, 2752512 bytes (672 pages) 0x00000040000000 - 0x000000f5e2ffff, 3051552768 bytes (745008 pages) So: Some of the oddities go back to some of this earlier material. For example, somehow: Reserved 00003ee5c000 00003ee5c000 00000001 WB=20 turned into: 0x3ee5c000 - 0x3ee5cfff, 0 MB ( 1 pages) NoAlloc NoDump 0x3ee5c000 - 0x3ee5cfff, 0 MB ( 1 pages) NoAlloc=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Feb 25 16:09:43 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 4PPBY66bjPz3tZft for ; Sat, 25 Feb 2023 16:09:46 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PPBY64LSVz3LMC; Sat, 25 Feb 2023 16:09:46 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.16.1/8.16.1) with ESMTP id 31PG9ijW064565; Sat, 25 Feb 2023 10:09:44 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id vAPgKcgy+mMz/AAAs/W3XQ (envelope-from ); Sat, 25 Feb 2023 10:09:44 -0600 From: Mike Karels To: Mark Millard Cc: Mitchell Horne , freebsd-arm Subject: Re: reboot broken on RPi4 on main [breaks at git: e6cf1a0826c9 - main - physmem: add ram0 pseudo-driver] Date: Sat, 25 Feb 2023 10:09:43 -0600 X-Mailer: MailMate (1.14r5937) Message-ID: <5E055A77-24DB-44D3-89F8-5113555283EA@karels.net> In-Reply-To: References: <9EA91B94-87E4-47B8-A4E2-60D556E64276@yahoo.com> <4FCD4987-6DAF-4889-B684-B6E464F41144@yahoo.com> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4PPBY64LSVz3LMC X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Top posting to make this easier to find: I verified that the current kernel can reboot if it was booted with hint.ram.0.disabled=3D=E2=80=9C1=E2=80=9D in /boot/device.hints. Mike On 25 Feb 2023, at 3:58, Mark Millard wrote: > [I probably should have also shown related output from > earlier in the boot log.] > > On Feb 25, 2023, at 01:23, Mark Millard wrote: > >> On Feb 24, 2023, at 22:16, Mark Millard wrote: >> >>> [The first main version to not reboot RPi4B's is: >>> git: e6cf1a0826c9 - main - physmem: add ram0 pseudo-driver Mitchell H= orne >>> ] >>> >>> On Feb 24, 2023, at 17:45, Mark Millard wrote: >>> >>>> On Feb 24, 2023, at 15:18, Mark Millard wrote: >>>> >>>>> On Feb 23, 2023, at 14:01, Mike Karels wrote: >>>>> >>>>>> Reboot (shutdown -r) is hanging on RPi4 on main as of today=E2=80=99= s snapshot. >>>>>> It hangs after printing the Uptime. The initial bootstrap and boo= t from >>>>>> power-up work. I haven=E2=80=99t tested a snapshot since Jan 1, s= o I=E2=80=99m not sure >>>>>> when it stopped working. Any ideas what might have broken it? I = can bisect >>>>>> the recent snapshots if nothing else. >>>>>> >>>>>> 13.2-BETA2 works, however. >>>>> >>>>> For reference . . . >>>>> >>>>> While it is a personal build instead of a snapshot, >>>>> I see the "shutdown -r now" hang problem for my build >>>>> based on: >>>>> >>>>> # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/ >>>>> d04c86717c8c (HEAD -> main, freebsd/main, freebsd/HEAD) bsd.sys.mk:= Add NO_WSTRICT_PROTOTYPES like in kernel >>>>> branch: main >>>>> merge-base: d04c86717c8ca3aa1bd9d8927a37a1f5443925b5 >>>>> merge-base: CommitDate: 2023-02-19 07:02:12 +0000 >>>>> n261026 (--first-parent --count for merge-base) >>>>> >>>>> The context has a "B0T" 8 GiByte RPi4B. >>>> >>>> For the artifact builds available for arm64, testing >>>> the kernels: >>>> >>>> The last that has "shutdown -r now" working on the RPi4B I'm using: >>>> >>>> =E2=80=A2 git: 8b418c83d175 - main - cp: Adjust the sparse file tes= ts. Dag-Erling Sm=C3=B8rgrav >>>> ( https://artifact.ci.freebsd.org/snapshot/main/8b418c83d175fde3b1f6= 5210509ddcf2ac248d9f/arm64/aarch64/kernel.txz ) >>>> >>>> No arm64 artifacts after that until . . . >>>> >>>> The first that has "shutdown -r now" failing on the same RPi4B: >>>> >>>> =E2=80=A2 git: ded5f2954e1a - main - nfsd: Fix handling of the erro= r case for nfsvno_open Rick Macklem >>>> ( https://artifact.ci.freebsd.org/snapshot/main/ded5f2954e1a1bb77486= 46888938af767ee6257a/arm64/aarch64/kernel.txz ) >>>> >>>> So the range is limited to (including those end points): >>>> (All are 2023-Feb-08 artifact builds.) >>>> >>>> =E2=80=A2 git: 8b418c83d175 - main - cp: Adjust the sparse file tes= ts. Dag-Erling Sm=C3=B8rgrav >>>> =E2=80=A2 git: 87d405eab911 - main - iommu_gas: initialize start_ga= p as first node Doug Moore >>>> =E2=80=A2 git: 8c784bb8cf36 - main - lua: Update to 5.4.4 Warner Lo= sh >>>> =E2=80=A2 git: 5fff09660e06 - main - geli: split the initalization = of HMAC Gordon Tetlow >>>> =E2=80=A2 git: 81ad626541db - main - Merge llvm-project main llvmor= g-15-init-15358-g53dc0f10787 Dimitry Andric >>>> =E2=80=A2 git: 753f127f3ace - main - Merge llvm-project main llvmor= g-15-init-16436-g18a6ab5b8d1f Dimitry Andric >>>> =E2=80=A2 git: fcaf7f8644a9 - main - Merge llvm-project main llvmor= g-15-init-17485-ga3e38b4a206b Dimitry Andric >>>> =E2=80=A2 git: 972a253a57b6 - main - Merge llvm-project main llvmor= g-15-init-17826-g1f8ae9d7e7e4 Dimitry Andric >>>> =E2=80=A2 git: 61cfbce3347e - main - Merge llvm-project release/15.= x llvmorg-15.0.0-rc2-40-gfbd2950d8d0d Dimitry Andric >>>> =E2=80=A2 git: a4a491e2238b - main - Merge llvm-project release/15.= x llvmorg-15.0.0-9-g1c73596d3454 Dimitry Andric >>>> =E2=80=A2 git: 6246ae0b85d8 - main - Merge llvm-project release/15.= x llvmorg-15.0.2-10-gf3c5289e7846 Dimitry Andric >>>> =E2=80=A2 git: f3fd488f1e19 - main - Merge llvm-project release/15.= x llvmorg-15.0.6-0-g088f33605d8a Dimitry Andric >>>> =E2=80=A2 git: 50d7464c3fe6 - main - Merge llvm-project release/15.= x llvmorg-15.0.7-0-g8dfdcc7b7bf6 Dimitry Andric >>>> =E2=80=A2 git: 3264f6b88fce - main - Bump __FreeBSD_version for llv= m 15.0.7 merge Dimitry Andric >>>> =E2=80=A2 git: 89a072d11cd2 - main - Makefile.amd64: remove constru= ct that serves no purpose Warner Losh >>>> =E2=80=A2 git: ae1dca798e0f - main - e1000: fix I219 hang on reset = Kevin Bowling >>>> =E2=80=A2 git: 647f2d2bc0cb - main - e1000: bump driver version Kev= in Bowling >>>> =E2=80=A2 git: 48bfd3597654 - main - Add nproc(1) Mateusz Guzik >>>> =E2=80=A2 git: 1d03c3578d05 - main - arm: add an interrupt rman to = nexus Mitchell Horne >>> >>> My build of the above version works for "shutdown -r now". >>> >>>> =E2=80=A2 git: f9bdaab95ec4 - main - ofwbus: remove handling of res= ources from ofwbus Mitchell Horne >>> >>> My build of the above version works for "shutdown -r now". >>> It is the last version to do so. >>> >>>> =E2=80=A2 git: e6cf1a0826c9 - main - physmem: add ram0 pseudo-drive= r Mitchell Horne >>> >>> My build of the above version fails for "shutdown -r now": >>> hang-up just after Uptime: . . . message. >>> >>>> =E2=80=A2 git: fa3f6655421f - main - netmap: drop redundant if_mtu = assignment Vincenzo Maffione >>>> =E2=80=A2 git: ded5f2954e1a - main - nfsd: Fix handling of the erro= r case for nfsvno_open Rick Macklem >>>> >>>> . . . >>> >>> >> >> The following from boot -v looks somewhat odd: >> >> ram0: reserving memory region: 2000-7ef0000 >> ram0: reserving memory region: 7f10000-31c00000 >> ram0: reserving memory region: 331d7000-39c2a000 >> ram0: reserving memory region: 39c2b000-39c2e000 >> ram0: reserving memory region: 39c2f000-39c30000 >> ram0: reserving memory region: 39c32000-39c33000 >> ram0: reserving memory region: 39c37000-3b050000 >> ram0: reserving memory region: 3b060000-3b300000 >> ram0: reserving memory region: 40000000-fc000000 >> ram0: reserving excluded region: 0-1fff >> ram0: reserving excluded region: 7ef0000-7f0ffff >> ram0: reserving excluded region: 31c00000-331d6fff >> ram0: reserving excluded region: 39c2a000-39c2afff >> ram0: reserving excluded region: 39c2e000-39c2efff >> ram0: reserving excluded region: 39c30000-39c31fff >> ram0: reserving excluded region: 39c33000-39c36fff >> ram0: reserving excluded region: 3b050000-3b05ffff >> ram0: reserving excluded region: 3ee5c000-3ee5cfff >> ram0: reserving excluded region: 3ee5c000-3ee5cfff >> ram0: failed to reserve region >> ram0: reserving excluded region: fe100000-fe100fff >> >> Possible oddities (4 GiByte RPi4B example): >> >> Nothing covers any part of [3b300000,3ee5c000) . >> Exclusion [3ee5c000-3ee5cfff] is repeated. (Related to the above?) >> The "failed to reserve region" notice. (Related to repetition?) >> Nothing covers any part of [fc000000,fe100000) . >> Nothing covers any part of [fe101000,ffffffff] . >> >> (The 2 different styles of specifying high bounds >> reads oddly.) > > Related boot log material: > > Type Physical Virtual #Pages Attr > Reserved 000000000000 000000000000 00000002 WB > ConventionalMemory 000000002000 000000002000 00007eee WB > ACPIReclaimMemory 000007ef0000 000007ef0000 00000020 WB > ConventionalMemory 000007f10000 000007f10000 00029c43 WB > LoaderData 000031b53000 000031b53000 00000001 WB > LoaderCode 000031b54000 000031b54000 00004000 WB > LoaderData 000035b54000 000035b54000 00004000 WB > LoaderCode 000039b54000 000039b54000 000000ce WB > BootServicesData 000039c22000 000039c22000 00000008 WB > RuntimeServicesData 000039c2a000 000039c2a000 00000001 WB RUNTIME > BootServicesData 000039c2b000 000039c2b000 00000003 WB > RuntimeServicesData 000039c2e000 000039c2e000 00000001 WB RUNTIME > BootServicesData 000039c2f000 000039c2f000 00000001 WB > RuntimeServicesData 000039c30000 000039c30000 00000002 WB RUNTIME > BootServicesData 000039c32000 000039c32000 00000001 WB > RuntimeServicesData 000039c33000 000039c33000 00000004 WB RUNTIME > BootServicesData 000039c37000 000039c37000 00000009 WB > BootServicesCode 000039c40000 000039c40000 00001410 WB > RuntimeServicesCode 00003b050000 00003b050000 00000010 WB RUNTIME > BootServicesCode 00003b060000 00003b060000 000000a0 WB > BootServicesData 00003b100000 00003b100000 00000200 WB > Reserved 00003ee5c000 00003ee5c000 00000001 WB > BootServicesData 000040000000 000040000000 000bc000 WB > MemoryMappedIO 0000fe100000 0000fe100000 00000001 RUNTIME > Physical memory chunk(s): > 0x00002000 - 0x3b2fffff, 946 MB ( 242430 pages) > 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages) > Excluded memory regions: > 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc > 0x07ef0000 - 0x07f0ffff, 0 MB ( 32 pages) NoAlloc > 0x31c00000 - 0x331d6fff, 21 MB ( 5591 pages) NoAlloc > 0x39c2a000 - 0x39c2afff, 0 MB ( 1 pages) NoAlloc > 0x39c2e000 - 0x39c2efff, 0 MB ( 1 pages) NoAlloc > 0x39c30000 - 0x39c31fff, 0 MB ( 2 pages) NoAlloc > 0x39c33000 - 0x39c36fff, 0 MB ( 4 pages) NoAlloc > 0x3b050000 - 0x3b05ffff, 0 MB ( 16 pages) NoAlloc > 0x3ee5c000 - 0x3ee5cfff, 0 MB ( 1 pages) NoAlloc NoDump > 0x3ee5c000 - 0x3ee5cfff, 0 MB ( 1 pages) NoAlloc > 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc > > and: > > Physical memory chunk(s): > 0x00000000002000 - 0x00000007eeffff, 133095424 bytes (32494 pages) > 0x00000007f10000 - 0x00000031bfffff, 701431808 bytes (171248 pages) > 0x000000331d7000 - 0x00000039c29fff, 111489024 bytes (27219 pages) > 0x00000039c2b000 - 0x00000039c2dfff, 12288 bytes (3 pages) > 0x00000039c2f000 - 0x00000039c2ffff, 4096 bytes (1 pages) > 0x00000039c32000 - 0x00000039c32fff, 4096 bytes (1 pages) > 0x00000039c37000 - 0x0000003b04ffff, 21073920 bytes (5145 pages) > 0x0000003b060000 - 0x0000003b2fffff, 2752512 bytes (672 pages) > 0x00000040000000 - 0x000000f5e2ffff, 3051552768 bytes (745008 pages) > > So: Some of the oddities go back to some of this earlier > material. For example, somehow: > > Reserved 00003ee5c000 00003ee5c000 00000001 WB > > turned into: > > 0x3ee5c000 - 0x3ee5cfff, 0 MB ( 1 pages) NoAlloc NoDump > 0x3ee5c000 - 0x3ee5cfff, 0 MB ( 1 pages) NoAlloc > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com From nobody Sat Feb 25 16:16:25 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 4PPBhs0w68z3tb2L; Sat, 25 Feb 2023 16:16:29 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PPBhq6vHYz3MTC; Sat, 25 Feb 2023 16:16:27 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 31PGGQPc011042 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 25 Feb 2023 08:16:26 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 31PGGQ4c011041; Sat, 25 Feb 2023 08:16:26 -0800 (PST) (envelope-from fbsd) Date: Sat, 25 Feb 2023 08:16:25 -0800 From: bob prohaska To: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot Message-ID: <20230225161625.GB8127@www.zefox.net> References: <20230224210502.GA8127@www.zefox.net> <1216867532.11893.1677280869319@localhost> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1216867532.11893.1677280869319@localhost> X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-current@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[zefox.net]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PPBhq6vHYz3MTC X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote: > > UFS stores the current timestamp in the superblock of the FS on clean > shutdown/unmount. On boot it reads the time from the timestamp in the > superblock of the root FS. Of coarse this timestamp is behind for the > duration that the machine was off or rebooting so you need to adjust that > using ntp. For ZFS root you can use the fakertc port to do something > similar. > > Mark Millard points out: /etc/localtime Current zoneinfo file, see tzsetup(8) and zic(8). /etc/wall_cmos_clock Empty file. Its presence indicates that the machine's CMOS clock is set to local time, while its absence indicates a UTC CMOS clock. Since there is no /etc/wall_cmos_clock on the newly-installed filesystem it appears the superblock timestamp is then interpreted as UTC when a Pi boots, using whatever happens to be set in /etc/localtime. My confusion is reduced somewhat. On first boot, what is the state of /etc/localtime? I've neglected to run tzsetup immediately on many previous installations and not noticed any complaints about mis-set clocks in buildworld. Is this new behavior? Thanks to both Mark and Ronald! bob prohaska From nobody Sat Feb 25 16:33:23 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 4PPC4P4mRmz3tbgY; Sat, 25 Feb 2023 16:33:25 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PPC4P4MWlz3hCb; Sat, 25 Feb 2023 16:33:25 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.16.1/8.16.1) with ESMTP id 31PGXOkY064695; Sat, 25 Feb 2023 10:33:24 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id Xg5THVQ4+mO1/AAAs/W3XQ (envelope-from ); Sat, 25 Feb 2023 10:33:24 -0600 From: Mike Karels To: bob prohaska Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot Date: Sat, 25 Feb 2023 10:33:23 -0600 X-Mailer: MailMate (1.14r5937) Message-ID: <0BA0C9F7-5F85-4EBF-86BB-428730746592@karels.net> In-Reply-To: <20230225161625.GB8127@www.zefox.net> References: <20230224210502.GA8127@www.zefox.net> <1216867532.11893.1677280869319@localhost> <20230225161625.GB8127@www.zefox.net> 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 Content-Type: text/plain X-Rspamd-Queue-Id: 4PPC4P4MWlz3hCb X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 25 Feb 2023, at 10:16, bob prohaska wrote: > On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote: >> >> UFS stores the current timestamp in the superblock of the FS on clean >> shutdown/unmount. On boot it reads the time from the timestamp in the >> superblock of the root FS. Of coarse this timestamp is behind for the >> duration that the machine was off or rebooting so you need to adjust that >> using ntp. For ZFS root you can use the fakertc port to do something >> similar. >> >> > Mark Millard points out: > /etc/localtime Current zoneinfo file, see tzsetup(8) and zic(8). > > /etc/wall_cmos_clock Empty file. Its presence indicates that the > machine's CMOS clock is set to local time, while > its absence indicates a UTC CMOS clock. > > Since there is no /etc/wall_cmos_clock on the newly-installed filesystem > it appears the superblock timestamp is then interpreted as UTC when a Pi > boots, using whatever happens to be set in /etc/localtime. My confusion > is reduced somewhat. On first boot, what is the state of /etc/localtime? > > I've neglected to run tzsetup immediately on many previous installations > and not noticed any complaints about mis-set clocks in buildworld. Is this > new behavior? /etc/localtime is used in formatting dates (e.g. for ls), but is not involved in storage of timestamps. Timestamps on files, system time, etc, are all in UTC. So the system should act normally if there is no /etc/localtime, and after one is added. Mike > Thanks to both Mark and Ronald! > > bob prohaska From nobody Sat Feb 25 17:02:38 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 4PPCk90fb0z3tdYX; Sat, 25 Feb 2023 17:02:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PPCk85nzJz3lsx; Sat, 25 Feb 2023 17:02:40 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.15.2) with ESMTPS id 31PH2dXd011245 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 25 Feb 2023 09:02:39 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.15.2/Submit) id 31PH2ckB011244; Sat, 25 Feb 2023 09:02:38 -0800 (PST) (envelope-from fbsd) Date: Sat, 25 Feb 2023 09:02:38 -0800 From: bob prohaska To: Mike Karels Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot Message-ID: <20230225170238.GA11193@www.zefox.net> References: <20230224210502.GA8127@www.zefox.net> <1216867532.11893.1677280869319@localhost> <20230225161625.GB8127@www.zefox.net> <0BA0C9F7-5F85-4EBF-86BB-428730746592@karels.net> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0BA0C9F7-5F85-4EBF-86BB-428730746592@karels.net> X-Rspamd-Queue-Id: 4PPCk85nzJz3lsx X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 25, 2023 at 10:33:23AM -0600, Mike Karels wrote: > On 25 Feb 2023, at 10:16, bob prohaska wrote: > > > On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote: > >> > >> UFS stores the current timestamp in the superblock of the FS on clean > >> shutdown/unmount. On boot it reads the time from the timestamp in the > >> superblock of the root FS. Of coarse this timestamp is behind for the > >> duration that the machine was off or rebooting so you need to adjust that > >> using ntp. For ZFS root you can use the fakertc port to do something > >> similar. > >> > >> > > Mark Millard points out: > > /etc/localtime Current zoneinfo file, see tzsetup(8) and zic(8). > > > > /etc/wall_cmos_clock Empty file. Its presence indicates that the > > machine's CMOS clock is set to local time, while > > its absence indicates a UTC CMOS clock. > > > > Since there is no /etc/wall_cmos_clock on the newly-installed filesystem > > it appears the superblock timestamp is then interpreted as UTC when a Pi > > boots, using whatever happens to be set in /etc/localtime. My confusion > > is reduced somewhat. On first boot, what is the state of /etc/localtime? > > > > I've neglected to run tzsetup immediately on many previous installations > > and not noticed any complaints about mis-set clocks in buildworld. Is this > > new behavior? > > /etc/localtime is used in formatting dates (e.g. for ls), but is not > involved in storage of timestamps. Timestamps on files, system time, etc, > are all in UTC. So the system should act normally if there is no > /etc/localtime, and after one is added. Does formatting include calculating offsets from UTC for display? On at least a couple of installs I've observed date reporting UTC time. After running tzsetup, set to PST, date then reported the same numerical time with a PST time zone. This happened very early in an installation lifecycle and seemed to just "go away" after a few reboots, though I never paid close attention since it caused no complaints. Thanks for replying! bob prohaska From nobody Sat Feb 25 17:26:07 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 4PPDFF5rqNz3tfyX; Sat, 25 Feb 2023 17:26:09 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PPDFF5QKLz3r3N; Sat, 25 Feb 2023 17:26:09 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.16.1/8.16.1) with ESMTP id 31PHQ84E064918; Sat, 25 Feb 2023 11:26:08 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id u8IeILBE+mOU/QAAs/W3XQ (envelope-from ); Sat, 25 Feb 2023 11:26:08 -0600 From: Mike Karels To: bob prohaska Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot Date: Sat, 25 Feb 2023 11:26:07 -0600 X-Mailer: MailMate (1.14r5937) Message-ID: <79CD9E36-93FF-44C2-99C4-B3CC5AEBB466@karels.net> In-Reply-To: <20230225170238.GA11193@www.zefox.net> References: <20230224210502.GA8127@www.zefox.net> <1216867532.11893.1677280869319@localhost> <20230225161625.GB8127@www.zefox.net> <0BA0C9F7-5F85-4EBF-86BB-428730746592@karels.net> <20230225170238.GA11193@www.zefox.net> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4PPDFF5QKLz3r3N X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 25 Feb 2023, at 11:02, bob prohaska wrote: > On Sat, Feb 25, 2023 at 10:33:23AM -0600, Mike Karels wrote: >> On 25 Feb 2023, at 10:16, bob prohaska wrote: >> >>> On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote: >>>> >>>> UFS stores the current timestamp in the superblock of the FS on clean >>>> shutdown/unmount. On boot it reads the time from the timestamp in the >>>> superblock of the root FS. Of coarse this timestamp is behind for the >>>> duration that the machine was off or rebooting so you need to adjust that >>>> using ntp. For ZFS root you can use the fakertc port to do something >>>> similar. >>>> >>>> >>> Mark Millard points out: >>> /etc/localtime Current zoneinfo file, see tzsetup(8) and zic(8). >>> >>> /etc/wall_cmos_clock Empty file. Its presence indicates that the >>> machine's CMOS clock is set to local time, while >>> its absence indicates a UTC CMOS clock. >>> >>> Since there is no /etc/wall_cmos_clock on the newly-installed filesystem >>> it appears the superblock timestamp is then interpreted as UTC when a Pi >>> boots, using whatever happens to be set in /etc/localtime. My confusion >>> is reduced somewhat. On first boot, what is the state of /etc/localtime? >>> >>> I've neglected to run tzsetup immediately on many previous installations >>> and not noticed any complaints about mis-set clocks in buildworld. Is this >>> new behavior? >> >> /etc/localtime is used in formatting dates (e.g. for ls), but is not >> involved in storage of timestamps. Timestamps on files, system time, etc, >> are all in UTC. So the system should act normally if there is no >> /etc/localtime, and after one is added. > > Does formatting include calculating offsets from UTC for display? Yes, I was referring to the process of converting from a binary timestamp in seconds since the epoch to a string with day/month/year/hour/minute etc in the local timezone. > On at least a couple of installs I've observed date reporting UTC time. > After running tzsetup, set to PST, date then reported the same numerical > time with a PST time zone. This happened very early in an installation > lifecycle and seemed to just "go away" after a few reboots, though I > never paid close attention since it caused no complaints. I have never seen such a thing. On the contrary, I have noticed files with timestamps that seemed to be in the future, then realized that they were in UTC; I set the timezone, and then they appeared to have recent times. I’d expect similar behavior from date unless the -u flag was used or the timezone was different in the environment. Mike