Date: Tue, 12 Jan 2021 04:14:51 -0800 From: Mark Millard <marklmi@yahoo.com> To: Gordon Bergling <gbe@freebsd.org> Cc: =?utf-8?Q?Klaus_K=C3=BCchemann?= <maciphone2@googlemail.com>, freebsd-arm@freebsd.org Subject: Re: PR 252541: Early kernel panic on RPi4B (Too many early devmatch mappings) [tied to monitor connected vs. not] Message-ID: <1B3F8042-6A8D-4F99-A9B7-A05B83B4D372@yahoo.com> In-Reply-To: <D8542CEB-EF9B-4FC3-AF7B-B7439225AD1A@yahoo.com> References: <X/y5YbRUMOyn4Hwl@lion.0xfce3.net> <7C6DC946-B7B6-42C8-A8B9-0471ED7B77AA@yahoo.com> <F0031010-EBB0-4DDE-B9D1-20A0F161E4EA@yahoo.com> <784263FD-D17C-4CA5-991E-FE93E3E584F3@yahoo.com> <7655A4A0-B74E-41B5-8E93-8F39CD462A81@yahoo.com> <4CFBA50F-0C76-48A4-8D88-58ED76D4E444@googlemail.com> <8AA272E7-DC58-4129-B376-0BB663B63BA7@yahoo.com> <X/1f/sj5LuKh//o6@lion.0xfce3.net> <E3ABC40A-92FF-45B7-BB6E-B05AF930DC33@yahoo.com> <7893EBCC-8431-4287-9F16-1AF28794F5CA@yahoo.com> <D8542CEB-EF9B-4FC3-AF7B-B7439225AD1A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-12, at 03:17, Mark Millard <marklmi at yahoo.com> wrote:
> Before the detailed sequence/evidence below: I eventually found how to
> control works vs. fails . . .
>=20
> Fails: have my monitor connected (1920 x 1080 in case it is important)
> Works: no monitor connected
> (Same kernel.)
>=20
> The later reporting is in the order of investigations and results, and
> so the above does not appear until the end.
>=20
> End top-post.
>=20
> On 2021-Jan-12, at 02:31, Mark Millard <marklmi at yahoo.com> wrote:
>=20
>> I've tried a from-scratch build via the script:
>>=20
>> # more =
~/sys_build_scripts.amd64-host/make-aarch64-debug-clang-default_config-amd=
64-host.sh
>> kldload -n filemon && \
>> script =
~/sys_typescripts/typescript_make_aarch64_debug_clang_default_config-amd64=
-host-$(date +%Y-%m-%d:%H:%M:%S) \
>> env __MAKE_CONF=3D/dev/null SRCCONF=3D/dev/null =
SRC_ENV_CONF=3D/dev/null TARGET=3Darm64 TARGET_ARCH=3Daarch64 \
>> WITH_META_MODE=3Dyes \
>> =
MAKEOBJDIRPREFIX=3D"/usr/obj/aarch64dbg_default_config_clang/arm64.aarch64=
" \
>> make $*
>>=20
>> on my existing source context ( 19cca0b9613d
>> with CommitDate 2021-01-09 16:21:33 -0800=20
>> based ):
>>=20
>> # ~/fbsd-based-on-what-freebsd-main.sh mm-src
>> 19cca0b9613d7c3058e41baf0204245119732235
>> CommitDate: 2021-01-09 16:21:33 -0800
>> 5d333ee67ac3 19cca0b9613d (HEAD -> mm-src) mm-src snapshot for mm's =
patched build in git context.
>>=20
>> So defaults but for TARGET, TARGET_ARCH, WITH_META_MODE, and
>> MAKEOBJDIRPREFIX . WITH_META_MODE should not matter for a
>> from-scratch build as far as I know.
>>=20
>> This is still a cross-build context. I used the 3 commands:
>>=20
>> =
~/sys_build_scripts.amd64-host/make-aarch64-debug-clang-default_config-amd=
64-host.sh -j32 kernel-toolchain
>>=20
>> =
~/sys_build_scripts.amd64-host/make-aarch64-debug-clang-default_config-amd=
64-host.sh -j32 buildkernel
>>=20
>> =
~/sys_build_scripts.amd64-host/make-aarch64-debug-clang-default_config-amd=
64-host.sh -j32 installkernel =
DESTDIR=3D/usr/obj/DESTDIRs/clang-aarch64-installkernel-dbg-default_config=
>>=20
>> (I'll avoid documenting copying to the RPi4B /boot/kernel/ and such.)
>>=20
>> It still failed to boot, with:
>>=20
>> . . .
>> Hit [Enter] to boot immediately, or any other key for command prompt.
>> Booting [/boot/kernel/kernel]... =20
>> Using DTB provided by EFI at 0x7ef0000.
>> EFI framebuffer information:
>> addr, size 0x3e2fe000, 0x7e9000
>> dimensions 1920 x 1080
>> stride 1920
>> masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
>> ---<<BOOT>>---
>> panic: Too many early devmap mappings
>> cpuid =3D 0
>> time =3D 1
>> KDB: stack backtrace:
>> . . .
>>=20
>> So my configuration files were not needed to have the failure
>> that I've been getting for the debug kernels.
>>=20
>=20
> I made a build based on 1a816c75600 that matches the official
> git (i.e., no changes in source) and used the same script as
> above (while cd'd into a different worktree). Same failure.
>=20
> So this time I show more prior messages that indicate
> variations in what might be loaded:
>=20
> . . .
> Setting currdev to disk0p1:
> Loading /boot/defaults/loader.conf
> Loading /boot/defaults/loader.conf
> Loading /boot/device.hints
> Loading /boot/loader.conf
> Loading /boot/loader.conf.local
> Loading kernel...
> /boot/kernel/kernel text=3D0x2a8 text=3D0x7faa3c text=3D0x22589c =
data=3D0x1aa458 data=3D0x0+0x611000 syms=3D[0x8+0x1209c0+0x8+0x145428]
> Loading configured modules...
> /boot/kernel/umodem.ko text=3D0x2140 text=3D0x1390 data=3D0x6e0+0x10 =
syms=3D[0x8+0xf48+0x8+0xb6e]
> loading required module 'ucom'
> /boot/kernel/ucom.ko text=3D0x22e6 text=3D0x2e48 data=3D0x8d0+0x858 =
syms=3D[0x8+0x12a8+0x8+0xbe5]
> /boot/entropy size=3D0x1000
> /etc/hostid size=3D0x25
>=20
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]... =20
> Using DTB provided by EFI at 0x7ef0000.
> EFI framebuffer information:
> addr, size 0x3e2fe000, 0x7e9000
> dimensions 1920 x 1080
> stride 1920
> masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> ---<<BOOT>>---
> panic: Too many early devmap mappings
> cpuid =3D 0
> time =3D 1
> KDB: stack backtrace:
> . . .
>=20
> FYI I'd only edited /boot/loader.conf of the
> files listed above. /boot/loader.conf.d/ is
> empty.
>=20
> For reference:
>=20
> # more /boot/loader.conf
> geom_label_load=3D"YES" # File system labels (see glabel(8))
> #
> boot_multicons=3D"YES"
> boot_serial=3D"YES"
> #
> # ucom is not automatically being loaded when umodem is loaded at =
boot.
> ucom_load=3D"YES"
> umodem_load=3D"YES"
> #
> beastie_disable=3D"YES"
> loader_color=3D"NO"
> #
> vfs.root.mountfrom=3D"ufs:/dev/gpt/RPi4Broot"
> kern.cam.boot_delay=3D10000
> vfs.mountroot.timeout=3D10
> vfs.root_mount_always_wait=3D1
> vfs.ffs.dotrimcons=3D1
> #
> kern.geom.label.disk_ident.enable=3D0
> kern.geom.label.gptid.enable=3D0
> kern.geom.label.ufsid.enable=3D0
> #
> dumpdev=3D"/dev/gpt/RPi4Bswap"
> #
> vm.pageout_oom_seq=3D120
> vm.pfault_oom_attempts=3D-1
>=20
> So looking at the alternatives for what to vary,
> I decided to eliminate the:
>=20
> EFI framebuffer information:
> addr, size 0x3e2fe000, 0x7e9000
> dimensions 1920 x 1080
> stride 1920
> masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
>=20
> part by booting with the monitor disconnected, leaving the
> rest as it was for the above.
>=20
> It booted just fine:
>=20
> # uname -apKU
> FreeBSD RPi4B 13.0-CURRENT FreeBSD 13.0-CURRENT #0 =
pure-src-c255871-g1a816c756003: Tue Jan 12 02:43:40 PST 2021 =
root@FBSDFHUGE:/usr/obj/aarch64dbg_default_config_clang/arm64.aarch64/usr/=
fbsd/pure-src/arm64.aarch64/sys/GENERIC arm64 aarch64 1300134 1300134
>=20
> I doubt that the use of 1a816c756003 is significant. But
> I know having the monitor connected vs. not is significant
> for that version.
Going back to my 19cca0b9613d based debug kernel build that
has the printf's reporting the values used in the test, but
with no monitor attached, it boots fine and reports:
pmap_mapdev early_boot: akva_devmap_vaddr: ffff007ffffff000 size: 1000
pmap_mapdev early_boot: va: ffff007fffffe000 VM_MAX_KERNEL_ADDRESS: =
ffff008000000000 L2_SIZE: 200000
That compares to the previously reported failure figures from
having the monitor attached for that debug kernel:
pmap_mapdev early_boot: akva_devmap_vaddr: ffff007fff816000 size: 1000
pmap_mapdev early_boot: va: ffff007fff815000 VM_MAX_KERNEL_ADDRESS: =
ffff008000000000 L2_SIZE: 200000
panic: Too many early devmap mappings
where the code does:
KASSERT(va >=3D VM_MAX_KERNEL_ADDRESS - L2_SIZE,
("Too many early devmap mappings"));
Looks like akva_devmap_vaddr gets smaller to make room above
for monitor related data and so va can end up being too small
by the criteria of this test.
I've no clue who would be appropriate for dealing with this.
=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?1B3F8042-6A8D-4F99-A9B7-A05B83B4D372>