Date: Sat, 9 Apr 2022 09:22:02 -0500 From: Kyle Evans <kevans@freebsd.org> To: Andrew Turner <andrew@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, dev-commits-src-main@freebsd.org Subject: Re: git: bcd763b642ab - main - Move the arm64 DMAP creation to C Message-ID: <CACNAnaG5pZs=yXSU-PieVar_srQhUG_QcJfdJLLO-FzR%2Bcj-DA@mail.gmail.com> In-Reply-To: <CC9039A0-B057-4C0B-B83F-390EA05CC55A@FreeBSD.org> References: <202204061324.236DO0pe071404@gitrepo.freebsd.org> <CACNAnaHJ4A=ynv5xt7sEh-wAWog6XtU26d2yyoMPGfdxxNUGYQ@mail.gmail.com> <CACNAnaEaipKjYYuDE_QdAjRk_Z0sWE5oB%2B8vhmiUdeAG5aQ_gw@mail.gmail.com> <CACNAnaEWErPCi1wgp%2BjrRgs%2BDJ%2B051%2B32XgL0V_kYFxCg-ujpQ@mail.gmail.com> <CC9039A0-B057-4C0B-B83F-390EA05CC55A@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 9, 2022 at 2:41 AM Andrew Turner <andrew@freebsd.org> wrote: > > > > On 9 Apr 2022, at 06:44, Kyle Evans <kevans@freebsd.org> wrote: > > On Sat, Apr 9, 2022 at 12:43 AM Kyle Evans <kevans@freebsd.org> wrote: > >> > >> On Sat, Apr 9, 2022 at 12:31 AM Kyle Evans <kevans@freebsd.org> wrote: > >>> > >>> Our Ampere boxes were fine with this, but this seems to tickle > >>> something on this M1 mini that I have. Specifically, we end up dying > >>> while probing UEFI stuff, here: > >>> > >>> https://cgit.freebsd.org/src/tree/sys/dev/efidev/efirt.c#n183 > >>> > >>> efi_systbl_phys =3D=3D 0x9e0979f30, efi_systbl =3D=3D 0xffffa001e0979= f30 > >>> Fatal data abort: > >>> ... > >>> sp: ffff000000fb79b0 > >>> lr: ffff000000157ae0 (efirt_modevents + 94) > >>> elr: ffff000000157ae8 (efirt_modevents + 9c) > >>> spsr: 604000c5 > >>> far: ffffa001e0979f30 > >>> esr: 96000007 > >>> panic: vm_fault failed: ffff000000157ae8 error 1 > >>> cpuid =3D 0 > >>> time =3D 1 > >>> KDB: stack backtrace: > >>> db_trace_self() at db_trace_self > >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > >>> vpanic() at vpanic+0x174 > >>> panic() at panic+0x44 > >>> data_abort() at data_abort+0x2f0 > >>> handle_el1h_sync() at handle_el1h_sync+0x10 > >>> --- exception, esr 0x96000007 > >>> efirt_modevents() at efirt_modevents+0x9c > >>> module_register_init() at module_register_init+0xc4 > >>> mi_startup() at mi_startup+0x284 > >>> virtdone() at virtdone+0x7c > >> > >> Er, maybe helpful: > >> > >> Physical memory chunk(s): > >> 0x8010a8000 - 0x803ecbfff, 46 MB ( 11812 pages) > >> 0x803f8c000 - 0x8053e7fff, 20 MB ( 5212 pages) > >> 0x805402000 - 0x808f99fff, 59 MB ( 15256 pages) > >> 0x808fb6000 - 0x80d5fffff, 70 MB ( 17994 pages) > >> 0x80dc73000 - 0x9e096ffff, 7468 MB (1912061 pages) > >> 0x9e0980000 - 0x9e0a33fff, 0 MB ( 180 pages) > > Excluded memory regions: > > 0x803ecc000 - 0x803f8bfff, 0 MB ( 192 pages) NoAlloc > > 0x8053e8000 - 0x805401fff, 0 MB ( 26 pages) NoAlloc > > 0x808f9a000 - 0x808fb5fff, 0 MB ( 28 pages) NoAlloc > > 0x80d600000 - 0x80dc72fff, 6 MB ( 1651 pages) NoAlloc > > 0x9d3800000 - 0x9d4d20fff, 21 MB ( 5409 pages) NoAlloc > > 0x9db93c000 - 0x9db93efff, 0 MB ( 3 pages) NoAlloc > > 0x9db940000 - 0x9db943fff, 0 MB ( 4 pages) NoAlloc > > 0x9e0970000 - 0x9e097ffff, 0 MB ( 16 pages) NoAlloc > > 0x9e3a5c000 - 0x9e3d21fff, 2 MB ( 710 pages) NoAlloc > > It looks like the memory was previously in the DMAP by accident due to th= e memory regions rounding to a 2M level 2 block alignment. > > Where does the M1 get its memory map from, EFI or FDT? If it=E2=80=99s th= e former can you get the EFI dump the kernel prints in a verbose boot. If i= t=E2=80=99s the latter can you get the FDT memory info, either a raw dtb/dt= s or via the fdt common in loader. > UEFI, here you go: Type Physical Virtual #Pages Attr ConventionalMemory 0008010a8000 0008010a8000 00002f50 WB Reserved 000803ff8000 000803ff8000 000000c0 WB ConventionalMemory 0008040b8000 0008040b8000 00001464 WB Reserved 00080551c000 00080551c000 0000001a WB ConventionalMemory 000805536000 000805536000 00003a64 WB ACPIReclaimMemory 000808f9a000 000808f9a000 0000001c WB ConventionalMemory 000808fb6000 000808fb6000 0000464a WB Reserved 00080d600000 00080d600000 00000673 WB ConventionalMemory 00080dc73000 00080dc73000 001c5b89 WB LoaderData 0009d37fc000 0009d37fc000 00000001 WB BootServicesData 0009d37fd000 0009d37fd000 00000001 WB LoaderData 0009d37fe000 0009d37fe000 00008000 WB LoaderCode 0009db7fe000 0009db7fe000 00000136 WB BootServicesData 0009db934000 0009db934000 00000008 WB RuntimeServicesData 0009db93c000 0009db93c000 00000003 WB RUNTIME BootServicesData 0009db93f000 0009db93f000 00000001 WB RuntimeServicesData 0009db940000 0009db940000 00000004 WB RUNTIME BootServicesData 0009db944000 0009db944000 0000000b WB LoaderData 0009db94f000 0009db94f000 00005021 WB RuntimeServicesCode 0009e0970000 0009e0970000 00000010 WB RUNTIME LoaderData 0009e0980000 0009e0980000 000000b4 WB
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaG5pZs=yXSU-PieVar_srQhUG_QcJfdJLLO-FzR%2Bcj-DA>