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>