Date: Sun, 4 Oct 2020 01:41:54 -0700 From: Mark Millard <marklmi@yahoo.com> To: Robert Crowston <crowston@protonmail.com>, freebsd-arm <freebsd-arm@freebsd.org> 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 Message-ID: <4D5162C2-592D-439C-9660-33A94DA5C807@yahoo.com> In-Reply-To: <01C14FE4-C2A6-4459-A5EE-AE33045FAF42@yahoo.com> References: <1A13F7B5-F8C3-4022-939C-2992E53D1DF1@yahoo.com> <BDA2D50C-E8C8-4BF2-8C97-C1B2516F06F3@yahoo.com> <01C14FE4-C2A6-4459-A5EE-AE33045FAF42@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Oct-3, at 20:15, Mark Millard <marklmi at yahoo.com> wrote:
> On 2020-Oct-3, at 16:10, Mark Millard <marklmi at yahoo.com> wrote:
>=20
>> On 2020-Oct-3, at 15:20, Mark Millard <marklmi at yahoo.com> wrote:
>>=20
>>> Another FreeBSD vs. ubuntu context difference, this time in the
>>> fdt print / output . . .
>>>=20
>>> The ubuntu u-boot has (fdt print / output):
>>>=20
>>> memreserve =3D <0x3b400000 0x04c00000>;
>>> . . . (Note: 0x3b400000+0x04c00000 =3D=3D 0x40000000) . . .
>>>=20
>>> #address-cells =3D <0x00000002>;
>>> #size-cells =3D <0x00000001>;
>>> . . .
>>> axi {
>>> vc_mem {
>>> reg =3D <0x3ec00000 0x40000000 0xc0000000>;
>>> };
>>> Note: "vc_mem is solely used as a mechanism for passing a =
couple
>>> of parameters through from the firmware to vcdbg"
>>> End note
>>> };
>>>=20
>>> . . . ( boot args has: vc_mem.mem_base=3D0x3ec00000 =
vc_mem.mem_size=3D0x40000000 ) . . .
>>>=20
>>> reserved-memory {
>>> #address-cells =3D <0x00000002>;
>>> #size-cells =3D <0x00000001>;
>>> ranges;
>>> phandle =3D <0x0000003d>;
>>> linux,cma {
>>> compatible =3D "shared-dma-pool";
>>> size =3D <0x04000000>;
>>> reusable;
>>> linux,cma-default;
>>> alloc-ranges =3D <0x00000000 0x00000000 =
0x30000000>;
>>> phandle =3D <0x0000003e>;
>>> };
>>> };
>>> . . . (I split the reg into lines below) . . .
>>> memory@0 {
>>> device_type =3D "memory";
>>> reg =3D <0x00000000 0x00000000 0x3b400000
>>> 0x00000000 0x40000000 0xbc000000
>>> 0x00000001 0x00000000 0x80000000
>>> 0x00000001 0x80000000 0x80000000>;
>>> };
>>> . . . (Note: 0x40000000+0xbc000000 =3D=3D 0xFC000000) . . .
>>>=20
>>> (I've ignored gpiomem above and below.)
>>>=20
>>> It appears to be that the memreserve may be important
>>> to have. The above may also suggest that FreeBSD's:
>>>=20
>>> #define DMA_HIGH_LIMIT 0x3c000000
>>>=20
>>> may be a little too large (< or <=3D 0x3b400000 ?).
>>>=20
>>> FreeBSD u-boot reports just:
>>>=20
>>> /memreserve/ 0x0 0x1000;
>>> . . .
>>> memory@0 {
>>>=20
>>> device_type =3D "memory";
>>> reg =3D <0x0 0x0 0x0>;
>>> };
>>>=20
>>> And so does not indicate anything special for either of
>>> (showing begin/end points):
>>>=20
>>> 0x3b400000..0x3FFFFFFF (in use by the vc?)
>>> 0xFC000000..0xFFFFFFFF (I/O peripheral area and such?)
>>>=20
>>> The context is an 8 GiByte RPi4 in both examples. Various
>>> details would vary on 1 GiByte and 2 GiByte RPi4Bs and
>>> some in memory@0 on the 4 GiBYTe RPi4B.
>>=20
>> Turns out that rpi_DATA_2711_1p0.pdf 's "Figure 1. BCM2711
>> Address Maps" shows this "SDRAM (for the VC)" area in the
>> two 35-bit Address Maps, showing 0x0_4000_0000 as the
>> next address after the area in both diagrams --and notes
>> for area for each diagram:
>>=20
>> QUOTE
>> Size of VC SDRAM
>> determined by
>> config.txt
>> END QUOTE
>>=20
>> But ubuntu uses includes and such so overall there
>> are the following .txt files ( cmdline.txt being for
>> a different purpose ):
>>=20
>> # ls -ld /boot/firmware/*.txt
>> -rwxr-xr-x 1 root root 141 Jul 31 16:48 /boot/firmware/cmdline.txt
>> -rwxr-xr-x 1 root root 1117 Jul 31 16:48 /boot/firmware/config.txt
>> -rwxr-xr-x 1 root root 327 Jul 31 16:48 /boot/firmware/syscfg.txt
>> -rwxr-xr-x 1 root root 251 Sep 26 22:14 /boot/firmware/usercfg.txt
>>=20
>> config.txt includes syscfg.txt and usercfg.txt .
>>=20
>> config.txt uses the [pi4], [pi2], [pi3], and [all] section
>> notation as well.
>>=20
>> Looks like one of u-boot's jobs is to figure out the figures
>> that go in (base then size):
>>=20
>> memreserve =3D <0x???????? 0x????????>;
>>=20
>> (such that the total is 0x40000000 for the RPi4B) in order
>> to protect the VC SDRAM area.
>>=20
>>=20
>> The diagrams also indicate that 0xFC000000..0xFFFFFFFF is
>> for when "low Perioheral" mode is in use, listing ("up
>> to H" not including H):
>>=20
>> ARM Local peripherals from 0x0_FF80_0000 up to 0x1_0000_0000
>> and:
>> Main peripherals from 0x0_FC00_0000 up to 0x0_FF80_0000
>>=20
>> Otherwise they are listed at:
>>=20
>> ARM Local peripherals from 0x4_C000_0000 up to 0x5_0000_0000
>> and:
>> Main peripherals from 0x4_7C00_0000 up to 0x4_8000_0000
>>=20
>> I gather the ubuntu "fdt print /" result implies that ubuntu
>> is using "Low Peripheral" mode (or at least allowing for it).
>>=20
>> There are some other "Reserved" areas and the special areas
>> that are "two L2 cache aliases (one allocating, one
>> non-allocating) which cache (only) the first 1GB of SDRAM".
>> if these are all counted then 0x4_0000_0000 up to
>> 0x6_0000_0000 is all some form of special-use area in
>> both diagrams and 0x6_0000_0000 through 0x7_FFFF_FFFF is the
>> PCIe area in both diagams.
>=20
>=20
> Looks like in ubuntu land the following from the dtb/fdt
> work together(?) to cover avoiding memory that is
> inappropriate for use for low-RAM DMA activity:
>=20
> U-Boot> fdt print /
> / {
> memreserve =3D <0x3b400000 0x04c00000>;
> . . . (Note: 0x3b400000+0x04c00000 =3D=3D 0x40000000) . . .
> reserved-memory {
> #address-cells =3D <0x00000002>;
> #size-cells =3D <0x00000001>;
> ranges;
> phandle =3D <0x0000003d>;
> linux,cma {
> compatible =3D "shared-dma-pool";
> size =3D <0x04000000>;
> reusable;
> linux,cma-default;
> alloc-ranges =3D <0x00000000 0x00000000 =
0x30000000>;
> phandle =3D <0x0000003e>;
> };
> };
> . . .
>=20
> where:
>=20
> alloc-ranges =3D <0x00000000 0x00000000 0x30000000> indicates a low
> memory range to use for "shared-dma-pool" DMA activity.
>=20
> memreserve =3D <0x3b400000 0x04c00000> indicates the actual
> area in use for gnu_mem=3D/gnu_mem_1024=3D material and so indicates
> an area that must be avoided. It appears that this adjusts based
> on what config.txt has for (either of) gnu_mem=3D/gnu_mem_1024=3D .
>=20
> It appears that the alloc-ranges=3D... above allows for the maximum
> recommended gpu_mem/gnu_mem_1024 figure for the RPi4B and so,
> if that limit is honored, avoids overlapping the memreserve. This
> may suggest that your code should change to:
>=20
> #define DMA_HIGH_LIMIT 0x30000000
>=20
>=20
> XHCI and the type-DMA4 engine use need to explicitly avoid the
> memreserve area. The old normal/LITE DMA could be redirected to
> use a different 1 GiByte range (shifted above the memreserve
> when there is enough RAM to do so).
>=20
>=20
> The more modern dtb/fdt's that I use in some contexts have the
> reserved-memory linux,cma alloc-ranges. (I'm not claiming such
> information is translated to uefi/ACPI.) But the old dtb/fdt's
> used with FreeBSD u-boot do not indicate those alloc-ranges.
>=20
> The u-boot for FreeBSD that I'm using (from ports) does not
> generate the memreserve material so neither the old or new
> fdt's end up with such material.
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):
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
NOTE: Here is where 0x3ebec000..0x3fffffff is not mentioned at all (even =
above)
0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=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)
So:
#define DMA_HIGH_LIMIT 0x3c000000
leads to the range for potential DMA use seeming to
overlap 0x3b400000..0x3bffffff (which is not mentioned
above).
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?
I'll note that there are a bunch of explicitly "Excluded
memory regions" that overlap with the range for potential
DMA use as well.
Note: Use of gpu_mem_1024=3D256 in config.txt instead
produces (notes added again):
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
0x3e513000 - 0x3ebebfff, 6 MB ( 1753 pages) NoAlloc=20
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)
0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=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)
(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.)
gpu_mem_1024=3D32 produced (no notes this time):
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
0xfe100000 - 0xfe100fff, 0 MB ( 1 pages) NoAlloc=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)
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.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D5162C2-592D-439C-9660-33A94DA5C807>