Date: Mon, 3 Feb 2020 01:47:22 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org>, "jeff@freebsd.org" <jeff@FreeBSD.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> 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() Message-ID: <7FACD90F-D051-454C-BF8A-81A9AFC99A6C@yahoo.com> In-Reply-To: <B978B231-5429-4DCC-900D-A03BB5E56D19@yahoo.com> References: <1E73DBF9-22D6-4304-B737-F9961DFF444A@yahoo.com> <11385E0D-6B89-4D5F-A4FD-06052D2FEF22@yahoo.com> <B978B231-5429-4DCC-900D-A03BB5E56D19@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[powerpc64 FreeBSD did not have the problem.] On 2020-Feb-2, at 23:52, Mark Millard <marklmi at yahoo.com> wrote: >=20 > On 2020-Feb-2, at 22:58, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> [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 <marklmi atyahoo.com> 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 >>> ---<<BOOT>>--- >>> 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?) I tried a powerpc64 update to head -r357419 on an old PowerMac G5 (2 socket, 2 cores each). It booted fine. So all the contexts that I had the very-early-boot-failure with were 32-bit FreeBSD on a weak memory model machine, but I've no strong-memory-model 32-bit FreeBSD contexts. >> 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 >=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). I've not done similarly for 32-bit PowerPC FreeBSD, but could if needed. =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?7FACD90F-D051-454C-BF8A-81A9AFC99A6C>