From owner-freebsd-arm@freebsd.org Tue Oct 6 21:26:32 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DE91B43C0CA for ; Tue, 6 Oct 2020 21:26:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-21.consmr.mail.gq1.yahoo.com (sonic310-21.consmr.mail.gq1.yahoo.com [98.137.69.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5Vs34gw0z3gtw for ; Tue, 6 Oct 2020 21:26:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 6YNWuCwVM1n7IIfeCFhJ.jdDPxcCra6QCa1mnqC6Snr9IBPnlqP3ZiS.0jWHgFY .AtcUbdysZ8RJGSroPTScu3WOJDsv3fZ2CsZjT8ijwb07gARW3RDcHV9b25xyLKmD8QEK8AJDs94 9v0e8nj5eZAHVw1EY2Lc3r5suwGKAEvQSfYjC1AHmClcx0IvSkpI9mmLXCyY6DibpRD9frBZ80i2 j_epo.J9XVzTG0EDAj0VTKQ8dShuw802.5WSiTOmap.hBAcWuG1HidJRTfGDLrq0c2WZzsOvSUcJ wIxrWBLQC6Z_FA2kQZd6uU_CdlcbkTGbBfR1a2sWR_t3H4v0Y73PasrKW_qENBcqQbvlEN9FRDIp 6mL0XrfqG45v5c.Md1ZvPXIwmXs6ImC_I_oJB0lPJJ9f.2SnO4VRelVMMulKlbD.SLbTqYOinxSp a6AoZKTiDTFh551S69pa9Fz4IDnLNxUQ9SBSwt57JZbVvFcb.Qg9sPSqx8udNhhydDZUqhCpcMMS zc9pPpfn8fBCvOOcXVKvmCm0lQ4IG32SxRPwlFF8kUCzxxvZAJObul_K1pjRDNvZ5M84BUNXxDT9 Xrge3.ydd7eoBo2Ohw5yTBxCZyAnNa90xfndyy6VBIr8OkjBe6TUJTwpxZRBhTtdddKKTYOdIbHI TMVS_0Vc30Iuh1eM2DlXdx2KBVm9yQuKTQ5RwdSAZ4anfyjsOxpppOnbzRfNN_SnN_WHHFDBrPJ3 hxBvcJSEokHhYZApoukGlSf2KTrx3miHUu0P0FnLeemMZ1wFGGT3BKmSI0thuafyH2OohJkQyRGw CZ7xlo2NjfN.yezk5lRSARDygClzshignjMhYYPGfuEn1v1aU58Wj73wELNydhAXM3d_9mbTHJsi gTNaLSHT9.JOtJPxDS2md1a9K19bdgBUx38eL.THoxBZJkdhwmfDGrXG936seOnpEJZVQTRB3UCb n9ZYf7vltQPSBRMEQjjduPUbF1MomIJleckTI56RGy.9MB3sfe5v6J4w3yQV44OEQ3pqpmjYwr1V Sx_bB3sc5cOLfu1TGvh1dXO7uOBNw0BmdRSLzzJ6bnd66CWf3Ld1b9bM1DaXbZgGxdTj9rfKbjXM UG8XMCWGlLkWEo1f2z7.FU51_NsJGNwy2O2KpjookeV.UAxT6A0j_wbC1fPhZtzxiklamzHuhd6h TiyuR_06hJ0TmQdBT_rcHo2KJjPrN4nb2PVM40wPw2QkGReTR95ggH.DKz0fdd_SL9b.qGjcqEii I8OtHRdmpu_j0g__jqk_5mMRFqOL3ep7jDk1qeqF4X3RWZ7.NBYf.RW59mBGjwiz8UNrZongiDIT p.gwk_0Wd9MK.anTDMfc1rdY4asNFMODcptPaRfuTk1PgLI3JP3iOAnSCTVl1AQVDF1lwSICtCgU R65mjBQuQGCpfKsKFv8yuGr3fBV_VPLNexAJnnRO04nkMOTXgUSCoB2h9iLWH91m7VCk05dfWhHV Ud9LfXrWt0UW91MsCn44fkH3qCl3O6eKqKWhmIv6QzJficmBMbJcBpfhxjpezHwjXsW.qCbqTc_E jlhjr0JafxYm.xSn.Dqio0gL4ywM5jyvblac- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 Oct 2020 21:26:28 +0000 Received: by smtp422.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 534db2c7acdaa9f351ae946f578637b9; Tue, 06 Oct 2020 21:26:25 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: rpi4 FreeBSD vs. ubuntu u-boot fdt print / memereserve difference (lack of reserve in FreeBSD context), 0x3b400000 vs. DMA_HIGH_LIMIT being 0x3c000000 Date: Tue, 6 Oct 2020 14:26:24 -0700 References: <1A13F7B5-F8C3-4022-939C-2992E53D1DF1@yahoo.com> <01C14FE4-C2A6-4459-A5EE-AE33045FAF42@yahoo.com> <4D5162C2-592D-439C-9660-33A94DA5C807@yahoo.com> To: Robert Crowston , freebsd-arm In-Reply-To: <4D5162C2-592D-439C-9660-33A94DA5C807@yahoo.com> Message-Id: <14D4D816-3CF3-4911-91FB-2AA50A4D1C22@yahoo.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Queue-Id: 4C5Vs34gw0z3gtw X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.25 / 15.00]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.75)[-0.745]; FREEMAIL_TO(0.00)[protonmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.017]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.147:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 21:26:32 -0000 On 2020-Oct-4, at 01:41, Mark Millard wrote: >=20 > On 2020-Oct-3, at 20:15, Mark Millard wrote: >=20 >> . . . >=20 > Looking at the FreeBSD boot-time memory map > on the 8 GiByte RPi4B via a u-boot based boot > shows that the address ranges > 0x3b400000..0x3e512fff and > 0x3ebec000..0x3fffffff are not referenced > below (I inserted some notes): >=20 > Type Physical Virtual #Pages Attr > Reserved 000000000000 0 00000002 WB=20 > ConventionalMemory 000000002000 2000 00007eef WB=20 > ACPIReclaimMemory 000007ef1000 7ef1000 0000001e WB=20 > ConventionalMemory 000007f0f000 7f0f000 00029f71 WB=20 > BootServicesData 000031e80000 31e80000 00000001 WB=20 > LoaderData 000031e81000 31e81000 00008001 WB=20 > LoaderCode 000039e82000 39e82000 000000ad WB=20 > Reserved 000039f2f000 39f2f000 00000007 WB=20 > BootServicesData 000039f36000 39f36000 00000001 WB=20 > RuntimeServicesData 000039f37000 39f37000 00000001 WB RUNTIME > BootServicesData 000039f38000 39f38000 00000002 WB=20 > Reserved 000039f3a000 39f3a000 00000001 WB=20 > BootServicesData 000039f3b000 39f3b000 00000002 WB=20 > RuntimeServicesData 000039f3d000 39f3d000 00000002 WB RUNTIME > Reserved 000039f3f000 39f3f000 00000001 WB=20 > BootServicesData 000039f40000 39f40000 00000001 WB=20 > Reserved 000039f41000 39f41000 00000001 WB=20 > BootServicesData 000039f42000 39f42000 00000002 WB=20 > Reserved 000039f44000 39f44000 00000001 WB=20 > LoaderData 000039f45000 39f45000 0000140b WB=20 > RuntimeServicesCode 00003b350000 3b350000 00000010 WB RUNTIME > LoaderData 00003b360000 3b360000 000000a0 WB=20 > NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all = (even later) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even later) > BootServicesData 000040000000 40000000 000bc000 WB=20 > MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME > BootServicesData 000100000000 100000000 00100000 WB=20 > Physical memory chunk(s): > 0x00002000 - 0x07ef0fff, 126 MB ( 32495 pages) > 0x07f0f000 - 0x39f2efff, 800 MB ( 204832 pages) > 0x39f36000 - 0x39f39fff, 0 MB ( 4 pages) > 0x39f3b000 - 0x39f3efff, 0 MB ( 4 pages) > 0x39f40000 - 0x39f40fff, 0 MB ( 1 pages) > 0x39f42000 - 0x39f43fff, 0 MB ( 2 pages) > 0x39f45000 - 0x3b34ffff, 20 MB ( 5131 pages) > 0x3b360000 - 0x3b3fffff, 0 MB ( 160 pages) > NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all = (even later) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even later) > 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages) > 0x100000000 - 0x1ffffffff, 4096 MB (1048576 pages) > Excluded memory regions: > 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc=20 > 0x07ef1000 - 0x07f0efff, 0 MB ( 30 pages) NoAlloc=20 > 0x32000000 - 0x33451fff, 20 MB ( 5202 pages) NoAlloc=20 > 0x39f2f000 - 0x39f35fff, 0 MB ( 7 pages) NoAlloc=20 > 0x39f37000 - 0x39f37fff, 0 MB ( 1 pages) NoAlloc=20 > 0x39f3a000 - 0x39f3afff, 0 MB ( 1 pages) NoAlloc=20 > 0x39f3d000 - 0x39f3ffff, 0 MB ( 3 pages) NoAlloc=20 > 0x39f41000 - 0x39f41fff, 0 MB ( 1 pages) NoAlloc=20 > 0x39f44000 - 0x39f44fff, 0 MB ( 1 pages) NoAlloc=20 > 0x3b350000 - 0x3b35ffff, 0 MB ( 16 pages) NoAlloc=20 > NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all = (even above) > 0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20 Looks like the above "NoAlloc" line is from: /* Exclude the EFI framebuffer from our view of physical memory. = */ efifb =3D (struct efi_fb *)preload_search_info(kmdp, MODINFO_METADATA | MODINFOMD_EFI_FB); if (efifb !=3D NULL) physmem_exclude_region(efifb->fb_addr, efifb->fb_size, EXFLAG_NOALLOC); However, for the RPi4B, it looks like the EFI FrameBuffer is in a subrange of the more general "gpu_mem" area that can be sized by doing gpu_mem=3D or gpu_mem_1024=3D via config.txt . The size varies by changing the smaller memory address and runs to the end of the=20 1 GiByte area on RPi4B's. At least this gives a reason for the one NoAlloc range that did show up that is in the gpu_mem=3D/gpu_mem_1024=3D area (but without a containing "Physical memory chunk"). In the end, I do not expect that this contributes to the issue at hand: phys_avail and the like seem to omit the whole gpu_mem=3D area and so it looks like the gpu_mem=3D memory is avoided for allocation. > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even above) > 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=20 >=20 > Physical memory chunk(s): > 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages) > 0x00000007f0f000 - 0x00000031ffffff, 705630208 bytes (172273 pages) > 0x00000033452000 - 0x00000039f2efff, 112054272 bytes (27357 pages) > 0x00000039f36000 - 0x00000039f36fff, 4096 bytes (1 pages) > 0x00000039f38000 - 0x00000039f39fff, 8192 bytes (2 pages) > 0x00000039f3b000 - 0x00000039f3cfff, 8192 bytes (2 pages) > 0x00000039f40000 - 0x00000039f40fff, 4096 bytes (1 pages) > 0x00000039f42000 - 0x00000039f43fff, 8192 bytes (2 pages) > 0x00000039f45000 - 0x0000003b34ffff, 21016576 bytes (5131 pages) > 0x0000003b360000 - 0x0000003b3fffff, 655360 bytes (160 pages) > NOTE: Here is where 0x3b400000..0x3e512fff is not mentioned at all = (even above) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even above) > 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages) > 0x00000100000000 - 0x000001f3840fff, 4085518336 bytes (997441 pages) >=20 > So: >=20 > #define DMA_HIGH_LIMIT 0x3c000000 >=20 > leads to the range for potential DMA use seeming to > overlap 0x3b400000..0x3bffffff (which is not mentioned > above). >=20 > Should the missing ranges have a classification above? > Is the lack of mention supposed to prevent the range > of memory's use for DMA activity? >=20 > I'll note that there are a bunch of explicitly "Excluded > memory regions" that overlap with the range for potential > DMA use as well. >=20 > Note: Use of gpu_mem_1024=3D256 in config.txt instead > produces (notes added again): >=20 > Type Physical Virtual #Pages Attr > Reserved 000000000000 0 00000002 WB=20 > ConventionalMemory 000000002000 2000 00007eef WB=20 > ACPIReclaimMemory 000007ef1000 7ef1000 0000001e WB=20 > ConventionalMemory 000007f0f000 7f0f000 0001eb71 WB=20 > BootServicesData 000026a80000 26a80000 00000001 WB=20 > LoaderData 000026a81000 26a81000 00008001 WB=20 > LoaderCode 00002ea82000 2ea82000 000000ad WB=20 > Reserved 00002eb2f000 2eb2f000 00000007 WB=20 > BootServicesData 00002eb36000 2eb36000 00000001 WB=20 > RuntimeServicesData 00002eb37000 2eb37000 00000001 WB RUNTIME > BootServicesData 00002eb38000 2eb38000 00000002 WB=20 > Reserved 00002eb3a000 2eb3a000 00000001 WB=20 > BootServicesData 00002eb3b000 2eb3b000 00000002 WB=20 > RuntimeServicesData 00002eb3d000 2eb3d000 00000002 WB RUNTIME > Reserved 00002eb3f000 2eb3f000 00000001 WB=20 > BootServicesData 00002eb40000 2eb40000 00000001 WB=20 > Reserved 00002eb41000 2eb41000 00000001 WB=20 > BootServicesData 00002eb42000 2eb42000 00000002 WB=20 > Reserved 00002eb44000 2eb44000 00000001 WB=20 > LoaderData 00002eb45000 2eb45000 0000140b WB=20 > RuntimeServicesCode 00002ff50000 2ff50000 00000010 WB RUNTIME > LoaderData 00002ff60000 2ff60000 000000a0 WB=20 > NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all = (even below) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even below) > BootServicesData 000040000000 40000000 000bc000 WB=20 > MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME > BootServicesData 000100000000 100000000 00100000 WB=20 > Physical memory chunk(s): > 0x00002000 - 0x07ef0fff, 126 MB ( 32495 pages) > 0x07f0f000 - 0x2eb2efff, 620 MB ( 158752 pages) > 0x2eb36000 - 0x2eb39fff, 0 MB ( 4 pages) > 0x2eb3b000 - 0x2eb3efff, 0 MB ( 4 pages) > 0x2eb40000 - 0x2eb40fff, 0 MB ( 1 pages) > 0x2eb42000 - 0x2eb43fff, 0 MB ( 2 pages) > 0x2eb45000 - 0x2ff4ffff, 20 MB ( 5131 pages) > 0x2ff60000 - 0x2fffffff, 0 MB ( 160 pages) > NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all = (even below) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even below) > 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages) > 0x100000000 - 0x1ffffffff, 4096 MB (1048576 pages) > Excluded memory regions: > 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc=20 > 0x07ef1000 - 0x07f0efff, 0 MB ( 30 pages) NoAlloc=20 > 0x26c00000 - 0x28051fff, 20 MB ( 5202 pages) NoAlloc=20 > 0x2eb2f000 - 0x2eb35fff, 0 MB ( 7 pages) NoAlloc=20 > 0x2eb37000 - 0x2eb37fff, 0 MB ( 1 pages) NoAlloc=20 > 0x2eb3a000 - 0x2eb3afff, 0 MB ( 1 pages) NoAlloc=20 > 0x2eb3d000 - 0x2eb3ffff, 0 MB ( 3 pages) NoAlloc=20 > 0x2eb41000 - 0x2eb41fff, 0 MB ( 1 pages) NoAlloc=20 > 0x2eb44000 - 0x2eb44fff, 0 MB ( 1 pages) NoAlloc=20 > 0x2ff50000 - 0x2ff5ffff, 0 MB ( 16 pages) NoAlloc=20 (Line that was here moved down to track address-range ordering.) > NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all = (even above) 0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20 (Again the EFI framebuffer.) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even above) > 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=20 >=20 > Physical memory chunk(s): > 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages) > 0x00000007f0f000 - 0x00000026bfffff, 516886528 bytes (126193 pages) > 0x00000028052000 - 0x0000002eb2efff, 112054272 bytes (27357 pages) > 0x0000002eb36000 - 0x0000002eb36fff, 4096 bytes (1 pages) > 0x0000002eb38000 - 0x0000002eb39fff, 8192 bytes (2 pages) > 0x0000002eb3b000 - 0x0000002eb3cfff, 8192 bytes (2 pages) > 0x0000002eb40000 - 0x0000002eb40fff, 4096 bytes (1 pages) > 0x0000002eb42000 - 0x0000002eb43fff, 8192 bytes (2 pages) > 0x0000002eb45000 - 0x0000002ff4ffff, 21016576 bytes (5131 pages) > 0x0000002ff60000 - 0x0000002fffffff, 655360 bytes (160 pages) > NOTE: Here is where 0x30000000..0x3e512fff is not mentioned at all = (even above) > NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all = (even above) > 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages) > 0x00000100000000 - 0x000001f3cb5fff, 4090191872 bytes (998582 pages) >=20 >=20 > (Note: gpu_mem_1024=3D16 leads to the rpi firmware > messing up and being unable to read the microsd card > for later rpi firmware files that it needs. It > actually ended up doing a USB3 SSD based boot, in > my context a uefi/ACPI boot.) >=20 >=20 > gpu_mem_1024=3D32 produced (no notes this time): >=20 > Type Physical Virtual #Pages Attr > Reserved 000000000000 0 00000002 WB=20 > ConventionalMemory 000000002000 2000 00007eef WB=20 > ACPIReclaimMemory 000007ef1000 7ef1000 0000001e WB=20 > ConventionalMemory 000007f0f000 7f0f000 0002cb71 WB=20 > BootServicesData 000034a80000 34a80000 00000001 WB=20 > LoaderData 000034a81000 34a81000 00008001 WB=20 > LoaderCode 00003ca82000 3ca82000 000000ad WB=20 > Reserved 00003cb2f000 3cb2f000 00000007 WB=20 > BootServicesData 00003cb36000 3cb36000 00000001 WB=20 > RuntimeServicesData 00003cb37000 3cb37000 00000001 WB RUNTIME > BootServicesData 00003cb38000 3cb38000 00000002 WB=20 > Reserved 00003cb3a000 3cb3a000 00000001 WB=20 > BootServicesData 00003cb3b000 3cb3b000 00000002 WB=20 > RuntimeServicesData 00003cb3d000 3cb3d000 00000002 WB RUNTIME > Reserved 00003cb3f000 3cb3f000 00000001 WB=20 > BootServicesData 00003cb40000 3cb40000 00000001 WB=20 > Reserved 00003cb41000 3cb41000 00000001 WB=20 > BootServicesData 00003cb42000 3cb42000 00000002 WB=20 > Reserved 00003cb44000 3cb44000 00000001 WB=20 > LoaderData 00003cb45000 3cb45000 0000140b WB=20 > RuntimeServicesCode 00003df50000 3df50000 00000010 WB RUNTIME > LoaderData 00003df60000 3df60000 000000a0 WB=20 > BootServicesData 000040000000 40000000 000bc000 WB=20 > MemoryMappedIO 0000fe100000 fe100000 00000001 RUNTIME > BootServicesData 000100000000 100000000 00100000 WB=20 > Physical memory chunk(s): > 0x00002000 - 0x07ef0fff, 126 MB ( 32495 pages) > 0x07f0f000 - 0x3cb2efff, 844 MB ( 216096 pages) > 0x3cb36000 - 0x3cb39fff, 0 MB ( 4 pages) > 0x3cb3b000 - 0x3cb3efff, 0 MB ( 4 pages) > 0x3cb40000 - 0x3cb40fff, 0 MB ( 1 pages) > 0x3cb42000 - 0x3cb43fff, 0 MB ( 2 pages) > 0x3cb45000 - 0x3df4ffff, 20 MB ( 5131 pages) > 0x3df60000 - 0x3dffffff, 0 MB ( 160 pages) > 0x40000000 - 0xfbffffff, 3008 MB ( 770048 pages) > 0x100000000 - 0x1ffffffff, 4096 MB (1048576 pages) > Excluded memory regions: > 0x00000000 - 0x00001fff, 0 MB ( 2 pages) NoAlloc=20 > 0x07ef1000 - 0x07f0efff, 0 MB ( 30 pages) NoAlloc=20 > 0x34c00000 - 0x36051fff, 20 MB ( 5202 pages) NoAlloc=20 > 0x3cb2f000 - 0x3cb35fff, 0 MB ( 7 pages) NoAlloc=20 > 0x3cb37000 - 0x3cb37fff, 0 MB ( 1 pages) NoAlloc=20 > 0x3cb3a000 - 0x3cb3afff, 0 MB ( 1 pages) NoAlloc=20 > 0x3cb3d000 - 0x3cb3ffff, 0 MB ( 3 pages) NoAlloc=20 > 0x3cb41000 - 0x3cb41fff, 0 MB ( 1 pages) NoAlloc=20 > 0x3cb44000 - 0x3cb44fff, 0 MB ( 1 pages) NoAlloc=20 > 0x3df50000 - 0x3df5ffff, 0 MB ( 16 pages) NoAlloc=20 > 0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20 (Above: again the EFI framebuffer inside the bigger gpu_mem area.) > 0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=20 >=20 > Physical memory chunk(s): > 0x00000000002000 - 0x00000007ef0fff, 133099520 bytes (32495 pages) > 0x00000007f0f000 - 0x00000034bfffff, 751767552 bytes (183537 pages) > 0x00000036052000 - 0x0000003cb2efff, 112054272 bytes (27357 pages) > 0x0000003cb36000 - 0x0000003cb36fff, 4096 bytes (1 pages) > 0x0000003cb38000 - 0x0000003cb39fff, 8192 bytes (2 pages) > 0x0000003cb3b000 - 0x0000003cb3cfff, 8192 bytes (2 pages) > 0x0000003cb40000 - 0x0000003cb40fff, 4096 bytes (1 pages) > 0x0000003cb42000 - 0x0000003cb43fff, 8192 bytes (2 pages) > 0x0000003cb45000 - 0x0000003df4ffff, 21016576 bytes (5131 pages) > 0x0000003df60000 - 0x0000003dffffff, 655360 bytes (160 pages) > 0x00000040000000 - 0x000000fbffffff, 3154116608 bytes (770048 pages) > 0x00000100000000 - 0x000001f372afff, 4084379648 bytes (997163 pages) >=20 >=20 > I wonder if such could be contributing to why > DMA_HIGH_LIMIT had to be set smaller than the > 3 GiByte limit: to under a 1 GiByte limit. It looks like my ACPI boots are getting the EFI framebuffer being more like (default gpu_mem example, as I remember): 0x3e2fe000 - 0x3eae6fff, 7 MB ( 2025 pages) NoAlloc=20 again not having a containing "Physical memory chunk" (and, again in the gpu_mem=3D/gpu_mem_1024=3D area). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)