From owner-freebsd-arm@freebsd.org Tue Jan 12 12:14:59 2021 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 48EDC4D5DE1 for ; Tue, 12 Jan 2021 12:14:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFTzQ2frPz4tZg for ; Tue, 12 Jan 2021 12:14:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1610453696; bh=lo3Rehh4wIVA0mlVHIOxiI2HY+VUg+/Czy8kCOHJ3nB=; h=Subject:From:Date:To:From:Subject:Reply-To; b=qu0Vpr/6T8owu3dSqIRGrftygTSH1+e4YkWutKI2k1pk5FdiWm/LBNr4GeqEOQWlilbns76/75np+q0K350a9icPNWj59mUwMtWCbtiRuwCcP3dCWsEhAcNvOPZgMFSq+0YOC/n3fk4Wl4UzR2qPZBbFCmqL5ISF/arj/54PFpk/C/UyLAyfHLVN/maa/4WJfaq/+alrFTxPCcYLca86aM0TeyaYU0oHTdV8YnXCc3YCeFMY9NiJoePECC1B1uj3xmvol3moo105lz455rUACX7EvfCEusWpv6C2HRvoA/QH4VJ/CXev6xUHxHqYmwgeCOdf+qiP4eCuinIPQlsYIQ== X-YMail-OSG: nKsc_C4VM1nNeBErBWRjFByhpZQydZeYsUDt45GgfvYYdnotSZ8yC3O7rgKKusp RexjfZfOSFa2KW_queQ8ccv6B9KPNEm3e3SzQwoht8OLIS.v2QApB3GwIb3V7xsH.jaXFsSZsd3r ueIOWNPWyV3QlJtz3WkjxkKjNKCmCxrrQBglEDnNJ0C6iF_uw_kXoLabipp5Ap9LXg4CGy9r3YMF SrX34KxCW.kyzk3fcwWBxY.AcVrGJS9gpycqR4aY3XF9rOh_2ijujsMBdfrS1B7L6xMkN83IcyBh MLoOX8ipYAek9U8nJvY0ICrocvzcy19mtzPc9KlxwqImidtIkyyMBAUiyVG3ll2QaxbbJEC8VRhD 6GNach524UAfNDG3fBpc86L9hxCEACuY_b6kpoU1UE_PTtkDA1biLErPHWTvsrCxTMD5NTXv_o6w ZbpYrke2ttLHBkKjXxerTDY8o2qa03QwSv_LVDa.ax4j8Ebddw_rDOXw9cmAtNTNEptsjyNJAgcd 9c6R1ctTTNPYxl.YQl6FQkwku6zGnDVQVG4XIJ8cOA5OxTnmg7wnXHJ4ocR.q3Xq4FXU1.wenFXP CrTN_fEkddScKDz49_EPbdSbHTHkxeQotzn98MgPdptxqAaWFDZN.gaBtcW0TD7WRPnB2nEzJn6m T.AKnTWIvA_JJ9sfSigjozOjEYUld.ybysjb.R4PsUdnyGtdBumkAmpbKuzsQ05x6eUAaN1_huCI Za.7qWxWjjcnl8BRPZOUh0x0O8xq0BNPFssOHAGFesTyMfOKReAlGo37CVnuCFqvAHbuygKudTEB jR5wsV8yVj2kXY315QXk4KNfBfuXKFvNvgndNvXvGWgc.PCeq9r5VMRhO26hMtVslyrK2YJ96Tub uzBRdE1ptJJxpF_pmV9k6hNcoaECRYR7fhYoQ8eid8x79SeMFM11ACUG0mpabtylUryeCoH50jl3 cLFUG0GhtBCPbS5wteCWaGve9R57S.8mF7qiqptf00GPKhPEVoSLkW8Tr4EFITkjTL_9xrR1BIMm oQGMAom3ZQs6S9J2lnby83LSdJSa0mhp.1jQDKWyaS.AZm1Fj8rk8hVrCJ_AY07SppFQWPYinZCK pvfmawR.td1b_fus_EgMdf22PdPgm5v7XHJVqs.Wrj7M.HWt1T2CU80_kBSxQukUFQyz5L3AQ8wo oGyakw7jgVijcvAA2XZEUvezb1JtlDsgGHne0H_xVv.F_QROyyLZOqrzTsXUo_zz2AdlJ7vkd_OO 6GEsBiw9qlD158uYkI5OU4_evsrAt_FvNiHi8hdP3esPj4AaOvY9unEUCBOuOdfrHGPkdH.1WLai ZcPkl7fOkH5vyfyozc7ID4BVtgZaZq13qj7KFp5.6ILOjWM3bhd3hG5bJod8i5ghdhrwnqm34atE vmy.RS9LmPzM6_cDtN3Mpy1RMbCP42DUfB8VsZ2oY35Fhoc4ymWvHm1TblPuHwwTEKWBQJCzreWL I2vd8GZtQm6D4fAmI8MhHjhcuLGiUJkyVC4prJbZJjYdSueeYMkW5ArDMzZuROKgFWKCL0tf9wMQ Bo1dEUy02pZC_Yr7bROq42pUVfvkkXhGk.j4tDA5k_cuUJ..DqYEA.R1xLKf6Lg8lOBKRXqi3tp4 74t3NbUOrnr35zyyb2NeigyVot4ANYb_72F9HWeIDOqAv98MeGX5sQiBS2dNqV_53dYG1U_H7YgN MPB1gek69wol0cl9hFbkd3b8pGsBR7FsZXJftRjPM_4QeGZL64v7ZD1zCS01bVl99yeOSdTiv5v2 JDZbDFUc48feCTW9ijd6svw.z1ldcnPuI7ZurAD0gkLvzO3L02wquPuGG_zUnYTwmw2GjRaiVze0 AJh1F5UAHrdcyElT78P0mjVsbvRNAt2NyW7g4kVaoJvYKI7m8f.Iw29TM0s5JR1Y17pcJdt7MGWR nSGXkWtJGiwRL3Tf89N0QlYRcFpHbDJwe8OjljIvAtCCVUC66n8Mm6ZPLoAuNA0QfW187FbsmsrF FhNikXr0s_BbvwfAf0GqWKupZcAP8nNRs7cpc5.4Yhic9FZKtsZiG4xEJTCf6KOc_FuMY3NmADUk qCtlHj4q.vqkKmt.sfxRLv7kgPQtbX1jQFRLxzEWifHqKGpb.yMVISY_BfTb8L_4r75wv0iIGLUi ABVI2YAtzrpeTm0AKqQX8i_WAggynnGqcpuZfGZOwPnLrM7w.4hKwofCF2lr3.bMH18lCCXPAN76 KC0xSP1Az4aBrpkYms34siPPTzekZUy9mABhNDDdg8wn0ldruuBqU9KkZ1RDFI3RlcA4NCwa1lHc KsR7n.iTwdRmJhDwp8aU_IIYpdLZbc5tQ.U.ob12KER3rVug4UvROF4u8HvF66APXduu2BSQw3BS aT6Rz73wIPTB5vqonsJPwFXd6wQwArh80LNUBfavlMkX8uU1HzZXY5onDDvxdOm6MoNJu2kf_oMz 3yjE0y_mvU_x.UbZ.S55yY.ljisiWr9.1oHhHzPwuYpPB7SghNARCKyATBybp8ffSlxYQMiM7GN8 _UNAEW4N0gOVARkbPXTPoQt4CMyy9f.afvjsiUAZ82LeH0m4xim.ZiCniS9BcrHENj9.6mQwBoN_ snDUpe2I3qk8mqf3YLY4CQCrUujDiVirwBF3NWayZnxqcw2sVaPgtYkStFOKTdfIqF42wGr1_VtD uASOzYVGweEZK5Q1l9xvJ2cXVCT9CFPA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 12 Jan 2021 12:14:56 +0000 Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 681d81c034419b2cb3a3d4f53f3de01b; Tue, 12 Jan 2021 12:14:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: PR 252541: Early kernel panic on RPi4B (Too many early devmatch mappings) [tied to monitor connected vs. not] From: Mark Millard In-Reply-To: Date: Tue, 12 Jan 2021 04:14:51 -0800 Cc: =?utf-8?Q?Klaus_K=C3=BCchemann?= , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1B3F8042-6A8D-4F99-A9B7-A05B83B4D372@yahoo.com> References: <7C6DC946-B7B6-42C8-A8B9-0471ED7B77AA@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> <7893EBCC-8431-4287-9F16-1AF28794F5CA@yahoo.com> To: Gordon Bergling X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Rspamd-Queue-Id: 4DFTzQ2frPz4tZg X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.82:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.82:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.82:from]; FREEMAIL_CC(0.00)[googlemail.com,freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 12:14:59 -0000 On 2021-Jan-12, at 03:17, Mark Millard 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 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 >> ---<>--- >> 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 > ---<>--- > 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)