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()
Mark Millard
marklmi at yahoo.com
Mon Feb 3 09:47:29 UTC 2020
[powerpc64 FreeBSD did not have the problem.]
On 2020-Feb-2, at 23:52, Mark Millard <marklmi at yahoo.com> wrote:
>
> On 2020-Feb-2, at 22:58, Mark Millard <marklmi at yahoo.com> wrote:
>
>> [32-bit powerpc non-debug kernel too, also for
>> updating head -r356426 based to -r357419 based.]
>>
>> On 2020-Feb-2, at 22:09, Mark Millard <marklmi atyahoo.com> wrote:
>>
>>> 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)
>>>
>>> ---<<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 at FBSDFHUGE:/usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/sys/GENERIC-NODBG arm
>>> FreeBSD clang version 9.0.1 (git at 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=00000005, FAR=00000150, spsr=000000d3
>>> r0 =00000000, r1 =00000000, r2 =00000001, r3 =c0b55520
>>> r4 =00000150, r5 =00000002, r6 =c510dca0, r7 =c096dc60
>>> r8 =00000001, r9 =c0970fc0, r10=00000000, r11=c0e14da0
>>> r12=00a00010, ssp=c0e14d80, slr=c0631f90, pc =c06313b8
>>>
>>> panic: Fatal abort
>>> cpuid = 0
>>> time = 1
>>> KDB: stack backtrace:
>>> db_trace_self() at db_trace_self
>>> pc = 0xc06789fc lr = 0xc007f710 (db_trace_self_wrapper+0x30)
>>> sp = 0xc0e14ac8 fp = 0xc0e14be0
>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>>> pc = 0xc007f710 lr = 0xc02e6e4c (vpanic+0x174)
>>> sp = 0xc0e14be8 fp = 0xc0e14c08
>>> r4 = 0x00000100 r5 = 0xc0b55520
>>> r6 = 0xc07cb7f7 r7 = 0x00000000
>>> vpanic() at vpanic+0x174
>>> pc = 0xc02e6e4c lr = 0xc02e6cd8 (vpanic)
>>> sp = 0xc0e14c10 fp = 0xc0e14c14
>>> r4 = 0xc0e14cf0 r5 = 0x00000013
>>> r6 = 0x00000150 r7 = 0x00000005
>>> r8 = 0x00000005 r9 = 0xc0b55520
>>> r10 = 0x00000150
>>> vpanic() at vpanic
>>> pc = 0xc02e6cd8 lr = 0xc069c5a0 (abort_align)
>>> sp = 0xc0e14c1c fp = 0xc0e14c48
>>> r4 = 0x00000005 r5 = 0x00000005
>>> r6 = 0xc0b55520 r7 = 0x00000150
>>> r8 = 0xc0e14c14 r9 = 0xc02e6cd8
>>> r10 = 0xc0e14c1c
>>> abort_align() at abort_align
>>> pc = 0xc069c5a0 lr = 0xc069c14c (abort_handler+0x2f8)
>>> sp = 0xc0e14c50 fp = 0xc0e14ce8
>>> r4 = 0x00000013 r5 = 0x00000150
>>> abort_handler() at abort_handler+0x2f8
>>> pc = 0xc069c14c lr = 0xc067b348 (exception_exit)
>>> sp = 0xc0e14cf0 fp = 0xc0e14da0
>>> r4 = 0x00000150 r5 = 0x00000002
>>> r6 = 0xc510dca0 r7 = 0xc096dc60
>>> r8 = 0x00000001 r9 = 0xc0970fc0
>>> r10 = 0x00000000
>>> exception_exit() at exception_exit
>>> pc = 0xc067b348 lr = 0xc0631f90 (cache_alloc+0x5c4)
>>> sp = 0xc0e14d80 fp = 0xc0e14da0
>>> r0 = 0x00000000 r1 = 0x00000000
>>> r2 = 0x00000001 r3 = 0xc0b55520
>>> r4 = 0x00000150 r5 = 0x00000002
>>> r6 = 0xc510dca0 r7 = 0xc096dc60
>>> r8 = 0x00000001 r9 = 0xc0970fc0
>>> r10 = 0x00000000 r12 = 0x00a00010
>>> uma_zalloc_arg() at uma_zalloc_arg+0x50
>>> pc = 0xc06313b8 lr = 0xc0631f90 (cache_alloc+0x5c4)
>>> sp = 0xc0e14da8 fp = 0xc0e14df0
>>> r4 = 0xc510dc80 r5 = 0x00000002
>>> r6 = 0xc510dca0 r7 = 0xc096dc60
>>> r8 = 0x00000000 r9 = 0xc510dca0
>>> r10 = 0xffffffff
>>> cache_alloc() at cache_alloc+0x5c4
>>> pc = 0xc0631f90 lr = 0xc06313dc (uma_zalloc_arg+0x74)
>>> sp = 0xc0e14df8 fp = 0xc0e14e18
>>> r4 = 0x00000150 r5 = 0x00000000
>>> r6 = 0xc510dc80 r7 = 0x000050b0
>>> r8 = 0x00000002 r9 = 0xc0970fc0
>>> r10 = 0xc510dc80
>>> uma_zalloc_arg() at uma_zalloc_arg+0x74
>>> pc = 0xc06313dc lr = 0xc02c117c (malloc+0x70)
>>> sp = 0xc0e14e20 fp = 0xc0e14e48
>>> r4 = 0xc0b554f0 r5 = 0xc0995b6c
>>> r6 = 0xc510dc80 r7 = 0x000050b0
>>> r8 = 0xc0945088 r9 = 0x00000002
>>> r10 = 0x0000000b
>>> malloc() at malloc+0x70
>>> pc = 0xc02c117c lr = 0xc02c6dd4 (mtx_pool_setup_dynamic+0x1c)
>>> sp = 0xc0e14e50 fp = 0xc0e14e60
>>> r4 = 0xc0b554f0 r5 = 0xc0995b6c
>>> r6 = 0x00000000 r7 = 0x00800001
>>> r8 = 0xc0b554fc r9 = 0x01ac0000
>>> r10 = 0xc0b55500
>>> mtx_pool_setup_dynamic() at mtx_pool_setup_dynamic+0x1c
>>> pc = 0xc02c6dd4 lr = 0xc026f490 (mi_startup+0x2a0)
>>> sp = 0xc0e14e68 fp = 0xc0e14e90
>>> r4 = 0xc0b554f0 r5 = 0xc0995b6c
>>> r6 = 0x00000000 r7 = 0x00800001
>>> mi_startup() at mi_startup+0x2a0
>>> pc = 0xc026f490 lr = 0xc00002c4 (_start+0x144)
>>> sp = 0xc0e14e98 fp = 0x00000000
>>> r4 = 0xc00003f8 r5 = 0xc0bb0000
>>> r6 = 0x00000000 r7 = 0x00c52078
>>> r8 = 0xc0d83000 r9 = 0x00000000
>>> r10 = 0x0000000a
>>> _start() at _start+0x144
>>> pc = 0xc00002c4 lr = 0xc00002c4 (_start+0x144)
>>> sp = 0xc0e14e98 fp = 0x00000000
>>> KDB: enter: panic
>>> [ thread pid 0 tid 0 ]
>>> Stopped at kdb_enter+0x58: ldrb r15, [r15, r15, ror r15]!
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Note: Both of these PowerMac reports are for kern.vty=vt ,
>> because for kern.vty=sc the output stopped before any backtrace
>> showed.
>>
>
> 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.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list