Re: PR 252541: Early kernel panic on RPi4B (Too many early devmatch mappings) [tied to monitor connected vs. not]

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:
> 
> # more ~/sys_build_scripts.amd64-host/make-aarch64-debug-clang-default_config-amd64-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=/dev/null SRCCONF=/dev/null SRC_ENV_CONF=/dev/null TARGET=arm64 TARGET_ARCH=aarch64 \
> WITH_META_MODE=yes \
> MAKEOBJDIRPREFIX="/usr/obj/aarch64dbg_default_config_clang/arm64.aarch64" \
> make $*
> 
> on my existing source context ( 19cca0b9613d
> with CommitDate 2021-01-09 16:21:33 -0800 
> based ):
> 
> # ~/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.
> 
> 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.
> 
> This is still a cross-build context. I used the 3 commands:
> 
> ~/sys_build_scripts.amd64-host/make-aarch64-debug-clang-default_config-amd64-host.sh -j32 kernel-toolchain
> 
> ~/sys_build_scripts.amd64-host/make-aarch64-debug-clang-default_config-amd64-host.sh -j32 buildkernel
> 
> ~/sys_build_scripts.amd64-host/make-aarch64-debug-clang-default_config-amd64-host.sh -j32 installkernel DESTDIR=/usr/obj/DESTDIRs/clang-aarch64-installkernel-dbg-default_config
> 
> (I'll avoid documenting copying to the RPi4B /boot/kernel/ and such.)
> 
> It still failed to boot, with:
> 
> . . .
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...               
> 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 = 0
> time = 1
> KDB: stack backtrace:
> . . .
> 
> So my configuration files were not needed to have the failure
> that I've been getting for the debug kernels.
> 

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=0x2a8 text=0x7faa3c text=0x22589c data=0x1aa458 data=0x0+0x611000 syms=[0x8+0x1209c0+0x8+0x145428]
Loading configured modules...
/boot/kernel/umodem.ko text=0x2140 text=0x1390 data=0x6e0+0x10 syms=[0x8+0xf48+0x8+0xb6e]
loading required module 'ucom'
/boot/kernel/ucom.ko text=0x22e6 text=0x2e48 data=0x8d0+0x858 syms=[0x8+0x12a8+0x8+0xbe5]
/boot/entropy size=0x1000
/etc/hostid size=0x25

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...               
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 = 0
time = 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="YES"           # File system labels (see glabel(8))
#
boot_multicons="YES"
boot_serial="YES"
#
# ucom is not automatically being loaded when umodem is loaded at boot.
ucom_load="YES"
umodem_load="YES"
#
beastie_disable="YES"
loader_color="NO"
#
vfs.root.mountfrom="ufs:/dev/gpt/RPi4Broot"
kern.cam.boot_delay=10000
vfs.mountroot.timeout=10
vfs.root_mount_always_wait=1
vfs.ffs.dotrimcons=1
#
kern.geom.label.disk_ident.enable=0
kern.geom.label.gptid.enable=0
kern.geom.label.ufsid.enable=0
#
dumpdev="/dev/gpt/RPi4Bswap"
#
vm.pageout_oom_seq=120
vm.pfault_oom_attempts=-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.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[email protected]"