From nobody Sat Sep 30 07:46:39 2023 X-Original-To: freebsd-current@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 4RyK6j3zwvz4vkkL for ; Sat, 30 Sep 2023 07:46:53 +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 4RyK6h1ldnz3CQ9 for ; Sat, 30 Sep 2023 07:46:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=FHv1VSe6; 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=1696060010; bh=XjgMf2wMD0Xe/LM/aiJrawiiUBspj2Q815CWd0szC7M=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=FHv1VSe65zpdUyrnl/FSxbF/l05ErrcuLWgqbc1PnAup2JB2Lg45/fCIBmX9rVyQTyl7KM9lMAX8Iq2k1BIPVt/S2UJnfPbY29VdhlFk+mOWGsL0QvOXvyyzLYaybpG4GVAhtUPqTHxeEQI7TIetnfC3sxTuxu4i38x1PKGz8QX4ul5bTzBUkrJxPOmXxDW11Yl6GkY6bf2Er+xMJq83Er/2tUt26EhmnEyFPzmvdaMuQYyvMa6oNJLgo6ZoqUMam32LNzWzzvwYxXwEQtrAhh0wEHzdc1RyRcOh+vLrtYQPZ/2Tc80iW8xAXQeltmsRaFE1dXScNhyEsN1zE0rlGg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1696060010; bh=/4mjIb7OJjtP60wLkd+9Qpgp0l8AAntSc29ucUyTyMj=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Mscnnsm56IkFdvZjbAaD4VK1QXnbBgBJjjlbrA/T8njm22r1a54p9GILe3CbralKZRO2KN/gofQmT+AT8aAiBVV3NREithEfUyAmJ6VlIplW9U1aeqvz/sD+T7yguv7UoDeRk8M7EdUxwmRPYKas0IFuiATx5bdeiaECIyLgPZsPXReJMQT+aKDJNqvZMwP/329wTuiDRJzp2vGOIqCrgj1R/nE4uxL/tlwJBm4dmAA7kn0/SuOI3X07EJ27U0AnonFhjJ1GDtRGv0TVPbllSfVAtgqNijqTc2DQ7f7BcJsQ8QCJxOg4TSikV8vAMCSEON0HN+dE1uvOh6tKOQVuww== X-YMail-OSG: l8d_pAQVM1kVUZUvo1O5I6PQod0MTmJcaTC5YWQXov1uLzD_w8hj5Jy_A3wQleR RQ7lykw0JyXjtrk9FtE5HFYqjZyO6Dp7NPoXSDXLGI4JsufmTXaIEtPGSrD1STKUyNVu0DdGbLEO CpByYrMPmbiXU05JtW_nE0QfWL9oRApKd5YvLka0STTMSuwOn8ZRk9ayq_LZkP3pv2qK7TgQs_3l U48mWcIOWMENwwi27R5_e_mF50L0mtJKS5fsBA72Teja.ZHhvlxEE7QkNImYeLJ6.Ienc4W7tKzo llXiV6ZOvfLqiabx_z8JpC_PvGp.rtLygKGJvr8aZm8Xik1pjpsdCZUm.Lx65tiKW5fQo8Yq9oEP oa18mPlL6D2Qz2PWQvbzbcqmWvqy_BFcaXdIdfdeRu8V3JbWrQhHaF4INM1sSH9Z7nJo4oKSeG1f 8t9P_VQQJUp6mrq.e1y0spDTdIaUik9OuSJtoR_43Q3pKPASgja2hVoUpT7hLEphyzGyUsFulp.I Dyy_gwHL1Py9vx8lj.MXNjuqVnfquilY3sKhwLc6QAbCaylXBDSbbjEHtPeSaus1sMBn_RxQNxrd Q1ESSHlRoGNmbIU4Oz2BZDqMB33fZFp4ra.2y82WECF0liq1V4_B9VxJ.Yrq6FKWRNqHC7RJ0tz8 4XMOqcs6pITVWGei0iQiyTQ4viM_M1z0Mhu4GZDer7OwxtluSjpuojQJ5CmbxrQapsly5IF_Mul1 aj664eZNl6vDGQW3uqjZbzLr5DDBLunqyZNGB5xZufvJ0akm1MlVCeCqVi29U824opLpYTmAHYyM nRe3qhvy8.ReV1HxdOpz1jc9H_qd2H4X5Us65j.9fE.4D4b4tzMPdc6ndQ_4747dntZGm5FHAb1t _ydBaWUqf84a3Vcv8zdWnQwt_QKaD.fNtSn0G9dbNGgzQw3oo60SgQn4v71y1r34GFnQuUuNJIHP YB9ER1D0CqtvpZqhgUqzLtCP6G2cM5yWs7Ye8mnEUHFoXVl2Nkc_v7FWWsJxd5Sjx1KmHSNu8hSE LhU9.7oLWqjIQEJY25SFzHJy6VVVgY5OllS83X5mmCImtZOInRnk1NLXw7ZHvNPifBI.xbmvWQ9u nypPp18_I5eIa2BXWQtiAHSW1BaDKJUNOsO1K1VTDrg9f_8LCxhgXndLK7RH7Hrtt9jCB1.zVLhH x2KpePyRhK_JX_kts1JoVHRZnwY.NJVvEZFOOi9JDzTzWJrRiL_2Rjkb4JNcxNV9dDwsrGF0hbUJ YaLRSSD2zhbnoPtsIQtFj4Z4vVxCp8nGEAWoe3Boy273zyRA_tZWEZk4A1ng3gxu9QBfsd5J7oBN PXL1POHFyDy58E8Ypy9VttdIXTAgO4xBbJnOp.dSCbKuZiLG76Jx.eg3r3V2FndCm7qGAzsF2k1q YqY7iapPrBx91WJY2k5MqdL1db1Mv_cFVTI.w6snAGbY6rzPJ5fy.0pb6zqArE1jIxXkU66l0_qx yO5r.qFJcU6YwrJSaZbGhoVQxOFV_oNFiDXfEpw3T1XlWbfbd9evZj5op23XQEe4EcNW6blm6oFD VhuY5eIGFySUK7vzHu_SAZ__VH_CLQLS08Pi2jtx1HT9Q32oRXXbQtbYyT8ytPnL8wE1rhbYy.Rj jx4GJCC.lfhoSdYIhWndBIMn6aK9Gc6TJSmLoWvU.dF4yeXqzm09Rov0VQJTe2T3TJ946OayD8n3 mTmFC5p_qvYw5RKodMnu4NteTC.TWcdB_I7_M4vKK9PcVu2Vo5hWmKldSvgPpUtzk_6yCU4Y..i4 KecQXOqEwcNiE_00VVBAmO5ekiiiR011z_x0SStCgTcnaFqr7u8KIi6X.UpkGNeIuL8vrm.FiZv_ QItsTDnflt5k6U96CL3VTKOUiVWO0fVoCpIKrpySOERRtCMM.U4M4BEIiyVF2mVH7RiFihZQVam7 JPswlcg5rQLwiB_NGsKGVXlq2dkCLP0PtykgaHaEBKEDB6V7y0392sHzhf0vJIaq61DLrfC1gkgx lWvvJGunORuxkPGe2W7otcxtUjEJioPayLVOqqscE0AaLw3naFcyMaR7kXeekMHz.9j.bbWsV4n6 aEAGLXRQ61rh.oQ8WPttpSav8rokCW2e0vlyfJ0kcZKu_kFWqqAI6ozr7qhCd75liKr1r.bslF_A aqGeN8jM7ceIWn5NkkP.TIuS3uaE9rwRS4A9Rxa6_c0U8o1AWjYABqj7o9JELZSr6NBP00fQnvoc p27cUnjrlXn7sPUKhcBg8Jc_GcyTKl_Bkz_Iu3ezV_OgAI3ZSer5OBL1dtVHGEHgXcZnXuw-- X-Sonic-MF: X-Sonic-ID: ab9d4623-6fbb-4889-8a31-f1f11c884c50 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Sep 2023 07:46:50 +0000 Received: by hermes--production-gq1-56dd58fbdb-hkqgj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b63fb46944f6aa226335089e6331af7d; Sat, 30 Sep 2023 07:46:49 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: 15 & 14: ram_attach vs. its using regions_to_avail vs. "bus_alloc_resource" can lead to: panic("ram_attach: resource %d failed to attach", rid) Message-Id: <3CB904C2-D983-4EF7-84D3-6BDED0700B08@yahoo.com> Date: Sat, 30 Sep 2023 00:46:39 -0700 To: Current FreeBSD , FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3731.700.6) References: <3CB904C2-D983-4EF7-84D3-6BDED0700B08.ref@yahoo.com> X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; 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]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.204:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.204:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4RyK6h1ldnz3CQ9 ram_attach is based on regions_to_avail but that is a problem for its later bus_alloc_resource use --and that can lead to: panic("ram_attach: resource %d failed to attach", rid); Unfortunately, the known example is use of EDK2 on RPi4B class systems, not what is considered the supported way. The panic happens for main [so: 15] and will happen once the cortex-a72 handling in 14.0-* is in a build fixed by: =E2=80=A2 git: 906bcc44641d - releng/14.0 - arm64: Fix errata = workarounds that depend on smccc Andrew Turner The lack of the fix leads to an earlier panic as stands. sys/kern/subr_physmem.c 's regions_to_avail is based on ignoring phys_avail and using only hwregions and exregions. In other words, in part: * Initially dump_avail and phys_avail are identical. Boot time memory * allocations remove extents from phys_avail that may still be included * in dumps. This means that early, dedicated memory allocations are treated as available for general use by regions_to_avail . The distinction is visible in the boot -v output in that: real memory =3D 3138154496 (2992 MB) Physical memory chunk(s): 0x00000000200000 - 0x0000002b7fffff, 727711744 bytes (177664 pages) 0x0000002ce3a000 - 0x0000003385ffff, 111304704 bytes (27174 pages) 0x000000338c0000 - 0x000000338c6fff, 28672 bytes (7 pages) 0x00000033a30000 - 0x00000036efffff, 55377920 bytes (13520 pages) 0x000000372e0000 - 0x0000003b2fffff, 67239936 bytes (16416 pages) 0x00000040000000 - 0x000000bb3dcfff, 2067648512 bytes (504797 pages) avail memory =3D 3027378176 (2887 MB) does not list the wider: 0x00000040000000 - 0x000000bfffffff because of phys_avail . But the earlier dump based on hwregions and exregions shows: Physical memory chunk(s): 0x001d0000 - 0x001effff, 0 MB ( 32 pages) 0x00200000 - 0x338c6fff, 822 MB ( 210631 pages) 0x33920000 - 0x3b2fffff, 121 MB ( 31200 pages) 0x40000000 - 0xbfffffff, 2048 MB ( 524288 pages) Excluded memory regions: 0x001d0000 - 0x001effff, 0 MB ( 32 pages) NoAlloc=20 0x2b800000 - 0x2ce39fff, 22 MB ( 5690 pages) NoAlloc=20 0x33860000 - 0x338bffff, 0 MB ( 96 pages) NoAlloc=20 0x33920000 - 0x33a2ffff, 1 MB ( 272 pages) NoAlloc=20 0x36f00000 - 0x372dffff, 3 MB ( 992 pages) NoAlloc=20 which indicates: 0x40000000 - 0xbfffffff is available as far as it is concerned. (Note some code works/displays in terms of: 0x40000000 - 0xc0000000 instead.) For aarch64 , sys/arm64/arm64/nexus.c has a nexus_alloc_resource that is used as bus_alloc_resource . It ends up rejecting the RPi4B boot via using the result of the call in ram_attach: if (bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, start, = end, end - start, 0) =3D=3D NULL) panic("ram_attach: resource %d failed to = attach", rid); as shown by the just-prior start/end pair sequence messages: ram0: reserving memory region: 200000-2b800000 ram0: reserving memory region: 2ce3a000-33860000 ram0: reserving memory region: 338c0000-338c7000 ram0: reserving memory region: 33a30000-36f00000 ram0: reserving memory region: 372e0000-3b300000 ram0: reserving memory region: 40000000-c0000000 panic: ram_attach: resource 5 failed to attach I do not see anything about this that looks inherently RPi* specific for possibly ending up with an analogous panic. So I expect the example is sufficient context to identify a problem is present, despite EDK2 use not being normal for RPi4B's and the like as far as FreeBSD is concerned. =3D=3D=3D Mark Millard marklmi at yahoo.com