Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Jan 2021 03:17:49 -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:  <D8542CEB-EF9B-4FC3-AF7B-B7439225AD1A@yahoo.com>
In-Reply-To: <7893EBCC-8431-4287-9F16-1AF28794F5CA@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>

next in thread | previous in thread | raw e-mail | index | archive | help
Before the detailed sequence/evidence below: I eventually found how to
control works vs. fails . . .

Fails: have my monitor connected (1920 x 1080 in case it is important)
Works: no monitor connected
(Same kernel.)

The later reporting is in the order of investigations and results, and
so the above does not appear until the end.

End top-post.

On 2021-Jan-12, at 02:31, Mark Millard <marklmi at yahoo.com> wrote:

> 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

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.

So this time I show more prior messages that indicate
variations in what might be loaded:

. . .
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

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:
. . .

FYI I'd only edited /boot/loader.conf of the
files listed above. /boot/loader.conf.d/ is
empty.

For reference:

# 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

So looking at the alternatives for what to vary,
I decided to eliminate the:

EFI framebuffer information:
addr, size     0x3e2fe000, 0x7e9000
dimensions     1920 x 1080
stride         1920
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000

part by booting with the monitor disconnected, leaving the
rest as it was for the above.

It booted just fine:

# 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

I doubt that the use of 1a816c756003 is significant. But
I know having the monitor connected vs. not is significant
for that version.

=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?D8542CEB-EF9B-4FC3-AF7B-B7439225AD1A>