From nobody Fri Jan 12 21:53:15 2024 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 4TBZzf5v0pz56S8d for ; Fri, 12 Jan 2024 21:53:34 +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 4TBZzf3QCqz4cdS for ; Fri, 12 Jan 2024 21:53:34 +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=1705096411; bh=BRrGmWDSgk3+66fQMJlET9RSeFG8z6+hvUTU+ANvlBI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KnF96TyrgMXbkwghHZtocVoXzS1atwQbhZICdHcHs4/zjSAFlkfuY667QuIIQjVWjGlCLi+5OogfOQNt5zz9hYuDHafuzqSCL0vqbArPdZeoXfdcSVmPUrgiy21K45JrWo0+8ecIrM/wyFbEGxIjNfVdwYsULxDRoiCKYZ33ytISkT7jxRVeWE+dbbVSKGhjdS0WW0xP67GMVoDpKsKa0KQi4xjG4zQTQq1TX2LtklZmBdtyqBex5uZHU6XO3rRpVMEzrtNt0oR2LyKY2XxcEasQ/Mz/XougjFi9TJmqdd7zOkmFx8rCpz/sFW4r78VEnyOKeYYYnwI9IDUkTJcs6A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1705096411; bh=QG7iZq3eG/eiUt0mE7OZLYDtLtmrqk9SJTPgyWKt/aQ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UAXsIJQoMflkqhtKmEPVwAj2isNgZNkvPf9fOIjYEU88Ka0JYEpSyo4rhFSt6AJ9tvH6cEE4PzacTeA/2u+pv/LEf3/kiXR/OLckyixOiAB1w8mbhNCedy33wa43XjyjIi8z9IPeXTeLdj0fK9WB/Wx6DmSz/qfbxvOOdo5RZT8hDW7HO/GnwhsYsAiKskP2FPE9k1gKf1jrxeBKYSsnlsvFewHlOSndHhRFn+LJZ1kwQ5vABqesFjkStVwHCSxF5NqSQ3lk3tXss5QXwdnYuhUzKzdz2BTLmzZZ+b0dxHDfMMxT/W2qJ2G6GXdhKpEj1tPhZrPZLazTkW4rOy5pwg== X-YMail-OSG: vTj8hDcVM1nQxat8nwNeY.odmaZKAnRbMDd7eOmrn6MJWiE_iXLIL6E3V81aK74 X7SRGDZSrXemjrdpFMgR9unKOQtHZuHAPEKgay36ONI.zhEQDNvsAq5gHXmesEK0y8lzvRFlbxrg owv435NNiU2bDsu2NdIdi5lHU2AiAlLL_XE2zIFUJuoMB4jTCXTiOgm73Bk8t021zb3Lhv8aYdm5 WE_.7EFE.KFUnUvu3hwk8Yz9tlYSUx1yO18Gnskasb1rJ7Y6ssnlAM_7G1cCqam16lKRPhknus9Y 2UfVNTu0Lehjf_kzjzsT3.zLtLMxlYbtYvkkDVLmtHjOolky4OhA3KY0gMCwUOgrO885J_0OQhJz 5R1dGTxR98p_Dq6.EAby05oH7FlqlhOAbcu_4ct8XPhp1crWtJ5q1KZfwNEXbSl0MLifxvKBmh.1 O_yfPYFA7Q1WpS7U3iKk2e238FQLF7VmvI4TQ9U.w2jVXuC53372_rO3zt6nMLbNwKH_h9tGlYsB Ot4wpmdpmOCPmT6TxdxpfPrIrgLNQDx0l2wZGKTpZITSCEHhu1Uqdto3SMtrLbGTUujqx3fax_Rl cHmdcQyYS55ivMYdKxMPIjmMHTuPu0k4XlhSBCu19j7zhtAanxY2GYLQtAu6JF1MQbqct7oYTF1z KMgbfm0tRaUZoxdZNyq7xRPmkfsKVwMpLKFbbaHTrVyMZFCzXfTG.ptN5YIw6famDKo9aBPN3Uyg DEvYRj6Kfj97nsmnY7euwFZxEC6Bcz_FJqqU7cS8L9O2LVPxgbSvE9eKBFzs0XHS1AxThoRo8CV1 767Mffp1sDQSZTvNpFqmHJqSWiXLp7Rt.zz5zC4cUL6RcFY46u75AgNtK9Wxru.VnDo_ndTSU_LB wWrbQzZ1u6bJ68FDcRtL6Cl8zfUi_ySbbwZPCq_y7HaVnMjKHst687lxH3dwV0hspy3hbfzKtlwo FQOMQrX7XJPYVdLCjWlw_XVX9DxTiwOWkAUT4YwZE4_F9HE.Iwk_eooJIZCYf_EEFwamaq0kw2Bo ucovqmqKX8PgaVYTICjK6BwDcSGrR7bJlf1UbnvBVtwNEPDkoFd7FOC.LN.TUJ5UsDNlvXuqUMXf PPO5OrbKhaEsAzY3fL8yOtFAdbf9MFpSMbWUiIXv492sOK_hTohMX.5TFb3F1AR.JyoXhcQzd3Pe 3QH7E0zCsjc2E.GotOd6eWIG2L6Kkx0AbhXLAyQfnodvTiGHmuJM11tVIsB2Q_nlyh43Z9JPxIDj Q3X4DEzlffyUprthwAaC1EKFB27UuPSIPyvuG0hQZIJlRdmdbqZQP6zuxw9cj1mR4Hw_s7jaxxxu JBwJe6kKBcvG1WE_1jdP0YoV7z_CbB6jEN_lnR5kVcx8CitnuA4hHbKWzbbFnwMcZgBAoQXYXGpW CsCP7kR3cNtxV6lxoJ4BX9IAYKNKJlXGL7Ok7U6YtrjTUSmL73FYgcPLMiylKYtgIzRm6QG1Ihsw PijtMLN3767B5i3CCoFhoFGfhK1Q7ZT_LQcfopkjxdAcd1GYmcP6lJVe209IREF_dgVY1PcHKP24 Uuap8aIoEgcScsfvKk4TM5h8PcF4P1dabTzfRuoh4b3gjHjdgesCq5Nm3n8yl._rHPuR6HGb89JV .ASV0hYqJ54WxiubFUsw2L7H0IY3JwTYxxohEu1zRTAkgpTdOvCgbmgHEYmVGP4a6NFUeYBbhrPY 8Ctbd7W.squbO3fa6I5GtBikVmONFUyXBG.KHtFC0Bp7FpV7B9n63G7m0QzFUhppn74UpUXswKqp BgKgKmzG..4u.Os7hMznLyir7cCayMt1Jbp7sy3kR_OU4WY_0Vp7hmPu34sfWI_1mDiRg1Kw6b8x 61Jpoipzh__mhA5kzOmE_k7k5KHV9UEHX4F7SAJVD_BTWDSkJm4oDjG_u6_gRqcHBDfy1OqQEj4i 1oJEqVF24tQN6kL68LkNWOsWOfF6t3trj4kbQMsXNaHN3c40l2XbOxTTqUHqE5sJdBG.Kl3_m4dH r7aBZdJrvLttowZMslpjBv7gyQpQ7WA2B5nRsn.9ufufP6QYvIvkgRTjBqksBouaw.r2yD98vBZK hyfmWJ4qgeIvGjRetkoVG283cGJMM4dT51ZmO0UZq6Ccead2AnVEo3oFsCVdTcYbZ4vl8hrPRsCE ULlwCvbdi8WcHkrDfqfVNcR1YfGCh_8u2ajf5xgK49tLz5IRE1O.SAyesZeZtXtaI_ida1UKliMP bxxBTITTQkxqyPmcq29EQK8aCJyEkD2qcd4VeiBH5TENFpdc1LuBuGWVENsRteLRf0wl9NRXlkyF W3w-- X-Sonic-MF: X-Sonic-ID: f35c313c-4174-4ff6-9b5a-658b8f3e69e8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 12 Jan 2024 21:53:31 +0000 Received: by hermes--production-gq1-78d49cd6df-4xktb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2054c6487691fb4b5323ace5ced448ff; Fri, 12 Jan 2024 21:53:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 \(3774.300.61.1.2\)) Subject: Re: 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) From: Mark Millard In-Reply-To: Date: Fri, 12 Jan 2024 13:53:15 -0800 Cc: Current FreeBSD , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <3CB904C2-D983-4EF7-84D3-6BDED0700B08.ref@yahoo.com> <3CB904C2-D983-4EF7-84D3-6BDED0700B08@yahoo.com> To: Doug Rabson X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Rspamd-Queue-Id: 4TBZzf3QCqz4cdS X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated 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] On Jan 12, 2024, at 09:57, Doug Rabson wrote: > On Sat, 30 Sept 2023 at 08:47, Mark Millard wrote: > 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: >=20 > panic("ram_attach: resource %d failed to attach", rid); >=20 > 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: >=20 > =E2=80=A2 git: 906bcc44641d - releng/14.0 - arm64: Fix errata = workarounds that depend on smccc Andrew Turner >=20 > The lack of the fix leads to an earlier panic as stands. >=20 >=20 > 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: >=20 > * Initially dump_avail and phys_avail are identical. Boot time = memory > * allocations remove extents from phys_avail that may still be = included > * in dumps. >=20 > 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: >=20 > 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) >=20 > does not list the wider: >=20 > 0x00000040000000 - 0x000000bfffffff >=20 > because of phys_avail . But the earlier dump based on hwregions and > exregions shows: >=20 > 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 >=20 > which indicates: >=20 > 0x40000000 - 0xbfffffff >=20 > is available as far as it is concerned. >=20 > (Note some code works/displays in terms of: 0x40000000 - 0xc0000000 > instead.) >=20 > 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: >=20 > 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); >=20 > as shown by the just-prior start/end pair sequence messages: >=20 > 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 >=20 > 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. >=20 > I'm not quite clear why phys_avail changes Do not be confused by common labeling to distinct data: Note the "phys_avail" vs. "hwregions" despite the label "Physical memory chunk(s):" : static void cpu_startup(void *dummy) { vm_paddr_t size; int i; printf("real memory =3D %ju (%ju MB)\n", = ptoa((uintmax_t)realmem), ptoa((uintmax_t)realmem) / 1024 / 1024); if (bootverbose) { printf("Physical memory chunk(s):\n"); for (i =3D 0; phys_avail[i + 1] !=3D 0; i +=3D 2) { size =3D phys_avail[i + 1] - phys_avail[i]; printf("%#016jx - %#016jx, %ju bytes (%ju = pages)\n", (uintmax_t)phys_avail[i], (uintmax_t)phys_avail[i + 1] - 1, (uintmax_t)size, (uintmax_t)size / = PAGE_SIZE); } } . . . vs. physmem_dump_tables(int (*prfunc)(const char *, ...) __printflike(1, 2)) { size_t i; int flags; uintmax_t addr, size; const unsigned int mbyte =3D 1024 * 1024; prfunc("Physical memory chunk(s):\n"); for (i =3D 0; i < hwcnt; ++i) { addr =3D hwregions[i].addr; size =3D hwregions[i].size; prfunc(" 0x%08jx - 0x%08jx, %5ju MB (%7ju pages)\n", = addr, addr + size - 1, size / mbyte, size / PAGE_SIZE); } prfunc("Excluded memory regions:\n"); for (i =3D 0; i < excnt; ++i) { addr =3D exregions[i].addr; size =3D exregions[i].size; flags =3D exregions[i].flags; prfunc(" 0x%08jx - 0x%08jx, %5ju MB (%7ju pages) %s = %s\n", addr, addr + size - 1, size / mbyte, size / = PAGE_SIZE, (flags & EXFLAG_NOALLOC) ? "NoAlloc" : "", (flags & EXFLAG_NODUMP) ? "NoDump" : ""); } . . . In other words, phys_avail does not change: It is just that phys_avail and hwregions are for different purposes and can get distinct values but ultimately both are involved overall and a net-result has to be generated from them. > and why that is triggered by the 906bcc44641d commit. I'm wondering if = it makes sense to arrange for ram_attach to happen before acpi, e.g. = using BUS_PASS_ORDER_FIRST? =3D=3D=3D Mark Millard marklmi at yahoo.com