head -r362600 aarch64 kernel from artifacts.ci.freebsd.org: boot crashes on 8 GiBYte RPi4 for UEFI RPI_EFI.fd v1.16 (USB-MSB style)

[Mark Millard]

In order to try to investigate a separate problem, I tried
substituting the -r362600 debug kernel into my RPi4 context.
The result of attempting the UEFI v1.16 based boot on the
8 GiByte RPi4 (USB-MSB style) was:

. . .
acpi_syscontainer0: <System Container> on acpi0
cpu0: <ACPI CPU> on acpi0
acpi_syscontainer1: <System Container> on acpi0
xhci0: <Generic USB 3.0 controller> iomem 0x600000000-0x600000fff irq 0 on acpi0
panic: Misaligned access from kernel space!
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
         pc = 0xffff000000760a68  lr = 0xffff00000010a49c
         sp = 0xffff000000010240  fp = 0xffff000000010440

db_trace_self_wrapper() at vpanic+0x194
         pc = 0xffff00000010a49c  lr = 0xffff00000041a1b4
         sp = 0xffff000000010450  fp = 0xffff0000000104a0

vpanic() at panic+0x44
         pc = 0xffff00000041a1b4  lr = 0xffff000000419f5c
         sp = 0xffff0000000104b0  fp = 0xffff000000010560

panic() at align_abort+0x7c
         pc = 0xffff000000419f5c  lr = 0xffff000000780aac
         sp = 0xffff000000010570  fp = 0xffff0000000105e0

align_abort() at do_el1h_sync+0x144
         pc = 0xffff000000780aac  lr = 0xffff00000077fd7c
         sp = 0xffff0000000105f0  fp = 0xffff000000010600

do_el1h_sync() at handle_el1h_sync+0x78
         pc = 0xffff00000077fd7c  lr = 0xffff000000763078
         sp = 0xffff000000010610  fp = 0xffff000000010750

handle_el1h_sync() at xhci_init+0x1b4
         pc = 0xffff000000763078  lr = 0xffff00000028c7f0
         sp = 0xffff000000010760  fp = 0xffff0000000107e0

xhci_init() at generic_xhci_attach+0x1cc
         pc = 0xffff00000028c7f0  lr = 0xffff0000007ad4fc
         sp = 0xffff0000000107f0  fp = 0xffff000000010820

generic_xhci_attach() at device_attach+0x400
         pc = 0xffff0000007ad4fc  lr = 0xffff000000450c04
         sp = 0xffff000000010830  fp = 0xffff000000010880

device_attach() at device_probe_and_attach+0x7c
         pc = 0xffff000000450c04  lr = 0xffff00000045076c
         sp = 0xffff000000010890  fp = 0xffff0000000108e0

device_probe_and_attach() at bus_generic_new_pass+0xf8
         pc = 0xffff00000045076c  lr = 0xffff000000452950
         sp = 0xffff0000000108f0  fp = 0xffff000000010910

bus_generic_new_pass() at bus_generic_new_pass+0xa8
         pc = 0xffff000000452950  lr = 0xffff000000452900
         sp = 0xffff000000010920  fp = 0xffff000000010950

bus_generic_new_pass() at bus_generic_new_pass+0xa8
         pc = 0xffff000000452900  lr = 0xffff000000452900
         sp = 0xffff000000010960  fp = 0xffff000000010990

bus_generic_new_pass() at bus_set_pass+0x4c
         pc = 0xffff000000452900  lr = 0xffff00000044dd40
         sp = 0xffff0000000109a0  fp = 0xffff0000000109d0

bus_set_pass() at mi_startup+0x12c
         pc = 0xffff00000044dd40  lr = 0xffff0000003ad23c
         sp = 0xffff0000000109e0  fp = 0xffff000000010a20

mi_startup() at virtdone+0x5c
         pc = 0xffff0000003ad23c  lr = 0xffff00000000108c
         sp = 0xffff000000010a30  fp = 0x0000000000000000

KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      generic_bs_r_4: ldr     w0, [x1, x2]
db> 

My normal, non-debug, head -r360311 based context did not have this
issue: That booted just fine.

Looks like I'll be building my own debug kernel in hopes that it
will work. (I commonly use artifact.ci materials to avoid such
builds.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)