From owner-freebsd-arm@freebsd.org Mon Feb 3 07:52:36 2020 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 543972459F5 for ; Mon, 3 Feb 2020 07:52:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 48B0RR0fbmz4Ctb for ; Mon, 3 Feb 2020 07:52:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: E8FwiR4VM1l2joBZQTQTtiMS894pwZiPPZ3Dgm25lvxnSsZTfNEank_zF_BLKxJ 9Nnm8dOaxGe_tWfa1XfGsxh0pQLW8El_P9MK4BXB7LzsGh7zsplc0rYlrDIqvBtPfBed7pd7KyjP 3ES25dafy02A.WHUvezq3G3qY5oJhPYaatbGseuOJIaD6C2N8Rwdj9a5x7MtW5ktzleJ1tiau6tg PyuNfJlNNLN.nWkrYKPp5zmMgvtIbv5gXSGDTpB7dD5QWWUEu13JUGIHCucLI1sGNZiAyUgeMcZ1 njSQdCwiCKODnt3XBxpOP6hCbekdJTBJiEdM0zgq64G2R7CZUQusTLv3bv3zEPeTjYVIHUuUqZUn gRhR8Y6a0qVTcFpAmleuWmsk8xn2xWzuKlIFhc_J09gjwJylHcDBZmhRvsuj.uG6UUHLdB.ps2k_ IEjUMaOfY6J0I.Ev_m8Rsp._hG5VrVaKfWg.F91G66SZ_qUmebERsW_.xv55HlTxoyGiRO10zOLs c0iAp1W5SFxMdQmTStMQu3DLUIiYJAoW5.i9OSXL4MXa0NXExdrjMIBzdWBvrdksFoAxeJhV0ZKT sMs1FF3NpAz_eNQd0Ui2WOUOo0aXdbqzjP9I_HviFHB7emcEYVlqvCQMX1LKggG8kAzNfKH9D1Ep 2cPoDJ0j5tmTINzMXm_9jNWdDpc1V3VIxm_jkUpz.Xg4hSl3UgY3BKdQDpsM9CF37P42FscL_V9d V7lSMQFi7c7e9CjC7Z160sgTaAo6NbM81LD3kWRjam.UnvP1xTgs_I28dq69zuDp4ONXqQCz_jPT Vj.HNWcABYEe1H4Y1Eawo4Lm3FyvgKe9zLop_eCqPIQv15DiqlD97mRx07hZwo3IbUs1bYRc2b0A fotTSZWBE0mO7_9SZDXevA3FbCnjm_BREs.h4jroOXAwv8JjV9vfrI_Okl8Gzz4z0LQFpOsPox5M LaKjZQCKk5L_0_WZVIPzu6DrtVaQepFq6y9au3gCkyUZHjd_6LkiP4eIZ6sFhthJKyn9tAGhQbtI aMB0.PlWyWk6SZv2jxFk4_CYlU4wRN82zMuCzbOP.MjTiIrPnsuE7RqFiF.bjFKnihLJCKiqiX4Y Cu_LQ_AKFIHBrJInN2wPaOtfrBvcyetz4SRLS_pXWYt3DfG4M06n0QAtjilQjWcb5S8lPbb6syIA Y31Lnaol9xmOZ8eBlvI7zTZEavJh2l_83pdrhf57Zh41zwoGMGeMMNCfbNyz4NxReLuR2ySsTt0S _S9ilQCH43Q3_QURvo63p4TLnYAmF66eEcj1J0_fQhFWbUw6eV5C3pII3xE_ULM9Nmte2SWblR9C uShc9oZAYrYfjdI4zOnrHW5N_KuJb78q1CKkSVcfblswifmMJGMRtwUsqYiLk_mjOrmc2piakJx2 o5xjgM_SboLiT6wg_FpfH6gPZxH6GNCMWWW2gbA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Mon, 3 Feb 2020 07:52:33 +0000 Received: by smtp409.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8aa9b19879a6e6d898d612f8155b9983; Mon, 03 Feb 2020 07:52:28 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: Updating to head -r357419 vs. Orange Pi+ 2ed and vs. 32-bit powerpc FreeBSD on PowerMacs: early boot failure via uma_zalloc_arg() for cache_alloc() Date: Sun, 2 Feb 2020 23:52:27 -0800 References: <1E73DBF9-22D6-4304-B737-F9961DFF444A@yahoo.com> <11385E0D-6B89-4D5F-A4FD-06052D2FEF22@yahoo.com> To: freebsd-arm , "jeff@freebsd.org" , FreeBSD PowerPC ML In-Reply-To: <11385E0D-6B89-4D5F-A4FD-06052D2FEF22@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Rspamd-Queue-Id: 48B0RR0fbmz4Ctb X-Spamd-Bar: - X-Spamd-Result: default: False [-1.19 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; 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/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.46)[-0.465,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.22)[-0.220,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (7.23), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[204.68.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[204.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 07:52:36 -0000 On 2020-Feb-2, at 22:58, Mark Millard wrote: > [32-bit powerpc non-debug kernel too, also for > updating head -r356426 based to -r357419 based.] >=20 > On 2020-Feb-2, at 22:09, Mark Millard wrote: >=20 >> After updating from head -r356426 based to >> head -r357419 based, the armv7 example >> crashes rather early in the boot sequence: >> (a non-debug kernel context) >>=20 >> ---<>--- >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2020 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights = reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 13.0-CURRENT #23 r357419M: Sun Feb 2 18:27:00 PST 2020 >> = markmi@FBSDFHUGE:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/sys/GENE= RIC-NODBG arm >> FreeBSD clang version 9.0.1 (git@github.com:llvm/llvm-project.git = c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) >> VT: init without driver. >> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> trapframe: 0xc0e14cf0 >> FSR=3D00000005, FAR=3D00000150, spsr=3D000000d3 >> r0 =3D00000000, r1 =3D00000000, r2 =3D00000001, r3 =3Dc0b55520 >> r4 =3D00000150, r5 =3D00000002, r6 =3Dc510dca0, r7 =3Dc096dc60 >> r8 =3D00000001, r9 =3Dc0970fc0, r10=3D00000000, r11=3Dc0e14da0 >> r12=3D00a00010, ssp=3Dc0e14d80, slr=3Dc0631f90, pc =3Dc06313b8 >>=20 >> panic: Fatal abort >> cpuid =3D 0 >> time =3D 1 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> pc =3D 0xc06789fc lr =3D 0xc007f710 = (db_trace_self_wrapper+0x30) >> sp =3D 0xc0e14ac8 fp =3D 0xc0e14be0 >> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >> pc =3D 0xc007f710 lr =3D 0xc02e6e4c (vpanic+0x174) >> sp =3D 0xc0e14be8 fp =3D 0xc0e14c08 >> r4 =3D 0x00000100 r5 =3D 0xc0b55520 >> r6 =3D 0xc07cb7f7 r7 =3D 0x00000000 >> vpanic() at vpanic+0x174 >> pc =3D 0xc02e6e4c lr =3D 0xc02e6cd8 (vpanic) >> sp =3D 0xc0e14c10 fp =3D 0xc0e14c14 >> r4 =3D 0xc0e14cf0 r5 =3D 0x00000013 >> r6 =3D 0x00000150 r7 =3D 0x00000005 >> r8 =3D 0x00000005 r9 =3D 0xc0b55520 >> r10 =3D 0x00000150 >> vpanic() at vpanic >> pc =3D 0xc02e6cd8 lr =3D 0xc069c5a0 (abort_align) >> sp =3D 0xc0e14c1c fp =3D 0xc0e14c48 >> r4 =3D 0x00000005 r5 =3D 0x00000005 >> r6 =3D 0xc0b55520 r7 =3D 0x00000150 >> r8 =3D 0xc0e14c14 r9 =3D 0xc02e6cd8 >> r10 =3D 0xc0e14c1c >> abort_align() at abort_align >> pc =3D 0xc069c5a0 lr =3D 0xc069c14c (abort_handler+0x2f8) >> sp =3D 0xc0e14c50 fp =3D 0xc0e14ce8 >> r4 =3D 0x00000013 r5 =3D 0x00000150 >> abort_handler() at abort_handler+0x2f8 >> pc =3D 0xc069c14c lr =3D 0xc067b348 (exception_exit) >> sp =3D 0xc0e14cf0 fp =3D 0xc0e14da0 >> r4 =3D 0x00000150 r5 =3D 0x00000002 >> r6 =3D 0xc510dca0 r7 =3D 0xc096dc60 >> r8 =3D 0x00000001 r9 =3D 0xc0970fc0 >> r10 =3D 0x00000000 >> exception_exit() at exception_exit >> pc =3D 0xc067b348 lr =3D 0xc0631f90 (cache_alloc+0x5c4) >> sp =3D 0xc0e14d80 fp =3D 0xc0e14da0 >> r0 =3D 0x00000000 r1 =3D 0x00000000 >> r2 =3D 0x00000001 r3 =3D 0xc0b55520 >> r4 =3D 0x00000150 r5 =3D 0x00000002 >> r6 =3D 0xc510dca0 r7 =3D 0xc096dc60 >> r8 =3D 0x00000001 r9 =3D 0xc0970fc0 >> r10 =3D 0x00000000 r12 =3D 0x00a00010 >> uma_zalloc_arg() at uma_zalloc_arg+0x50 >> pc =3D 0xc06313b8 lr =3D 0xc0631f90 (cache_alloc+0x5c4) >> sp =3D 0xc0e14da8 fp =3D 0xc0e14df0 >> r4 =3D 0xc510dc80 r5 =3D 0x00000002 >> r6 =3D 0xc510dca0 r7 =3D 0xc096dc60 >> r8 =3D 0x00000000 r9 =3D 0xc510dca0 >> r10 =3D 0xffffffff >> cache_alloc() at cache_alloc+0x5c4 >> pc =3D 0xc0631f90 lr =3D 0xc06313dc (uma_zalloc_arg+0x74) >> sp =3D 0xc0e14df8 fp =3D 0xc0e14e18 >> r4 =3D 0x00000150 r5 =3D 0x00000000 >> r6 =3D 0xc510dc80 r7 =3D 0x000050b0 >> r8 =3D 0x00000002 r9 =3D 0xc0970fc0 >> r10 =3D 0xc510dc80 >> uma_zalloc_arg() at uma_zalloc_arg+0x74 >> pc =3D 0xc06313dc lr =3D 0xc02c117c (malloc+0x70) >> sp =3D 0xc0e14e20 fp =3D 0xc0e14e48 >> r4 =3D 0xc0b554f0 r5 =3D 0xc0995b6c >> r6 =3D 0xc510dc80 r7 =3D 0x000050b0 >> r8 =3D 0xc0945088 r9 =3D 0x00000002 >> r10 =3D 0x0000000b >> malloc() at malloc+0x70 >> pc =3D 0xc02c117c lr =3D 0xc02c6dd4 = (mtx_pool_setup_dynamic+0x1c) >> sp =3D 0xc0e14e50 fp =3D 0xc0e14e60 >> r4 =3D 0xc0b554f0 r5 =3D 0xc0995b6c >> r6 =3D 0x00000000 r7 =3D 0x00800001 >> r8 =3D 0xc0b554fc r9 =3D 0x01ac0000 >> r10 =3D 0xc0b55500 >> mtx_pool_setup_dynamic() at mtx_pool_setup_dynamic+0x1c >> pc =3D 0xc02c6dd4 lr =3D 0xc026f490 (mi_startup+0x2a0) >> sp =3D 0xc0e14e68 fp =3D 0xc0e14e90 >> r4 =3D 0xc0b554f0 r5 =3D 0xc0995b6c >> r6 =3D 0x00000000 r7 =3D 0x00800001 >> mi_startup() at mi_startup+0x2a0 >> pc =3D 0xc026f490 lr =3D 0xc00002c4 (_start+0x144) >> sp =3D 0xc0e14e98 fp =3D 0x00000000 >> r4 =3D 0xc00003f8 r5 =3D 0xc0bb0000 >> r6 =3D 0x00000000 r7 =3D 0x00c52078 >> r8 =3D 0xc0d83000 r9 =3D 0x00000000 >> r10 =3D 0x0000000a >> _start() at _start+0x144 >> pc =3D 0xc00002c4 lr =3D 0xc00002c4 (_start+0x144) >> sp =3D 0xc0e14e98 fp =3D 0x00000000 >> KDB: enter: panic >> [ thread pid 0 tid 0 ] >> Stopped at kdb_enter+0x58: ldrb r15, [r15, r15, ror r15]! >=20 > 32-bit powerpc FreeBSD head -r357419 booting G5 powerpc64 PowerMac > (2 sockets, 1 core each): same sort of traceback sequence for a data > storage trap. >=20 > 32-bit powerpc FreeBSD head -r357419 booting G4 powerpc PowerMac > (2 sockets, 1 core each): backtrace is truncated, reporting > that the saved LR is invalid (an odd number) for a program > trap. But it was just as early as far as where the message > appeared. >=20 > I have not tried powerpc64 FreeBSD head -r357419 on an old > PowerMac. (Yet?) >=20 > Note: PowerMacs do not take input to the bd> prompt this > early. >=20 > Note: Both of these PowerMac reports are for kern.vty=3Dvt , > because for kern.vty=3Dsc the output stopped before any backtrace > showed. >=20 I substituted the artifact.ci.freebsd.org head -r357419 kernel (and its debug information). The result was the same backtrace sequence again. The problem is not specific to non-debug kernels. It appears that nothing special to my context is required for the problem to repeat on armv7 (Cortex-A7 anyway). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)