head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

Mark Millard-2
When I attempted to use the result of:

# cp -aRx /usr/obj/DESTDIRs/clang-cortexA53-installworld/boot/boot1.efi /mnt/EFI/BOOT/

the pine64+ boot sequence got over and over
a sequence like:

U-Boot 2017.07 (Sep 06 2017 - 07:49:12 +0000) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64+
DRAM:  2 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
. . .
>> FreeBSD EFI boot block
   Loader path: /boot/loader.efi

   Initializing modules: ZFS UFS
   Load Path:
"Synchronous Abort" handler, esr 0x96000004
ELR:     bdf90b30
LR:      bdf8fb6c
x0 : 0000000000000000 x1 : 0000000000000000
x2 : 00000000bdffc000 x3 : 0000000040000000
x4 : 00000000b9f34d40 x5 : 0000000000000000
x6 : 0000000000000015 x7 : 0000000000000000
x8 : 00000000bdfa59b8 x9 : 000000000000001c
x10: 0000000000000002 x11: 0000000000000000
x12: 0000000000000000 x13: 0000000000000000
x14: 0000000000000000 x15: 0000000000000000
x16: 0000000000000000 x17: 0000000000000000
x18: 00000000b9f39df8 x19: 0000000000000000
x20: 0000000000000000 x21: 0000000000000002
x22: 00000000b8f34c98 x23: 00000000b8f34c88
x24: 00000000b8f34ca0 x25: 00000000000007d0
x26: 00000000b8f34c90 x27: 00000000b8f2f198
x28: 0000000000000000 x29: 00000000b9f34de0

Resetting CPU ...

resetting ...



I found an old boot1.efi to copy over instead (from
back in -r308??? time frames as I remember) and
doing the replacement got past this point.



Booting with the non-debug kernel appears to hang for
a bit and then gets to a db> prompt and a bt showed
(for example):
(The console output for the register dump seems
to always be incomplete and there is a wait to
end up at the db> prompt. Note the data_abort
closest to the fork_exit .)

. . .
Release APs
APs not started
CPU  0: ARM Cortex-A53 r0p4 affinity:  0
 Instruction Set Attributes 0 = <AES+PMULL,SHA1,SHA2,CRC32>
 Instruction Set Attributes 1 = <0>
         Processor Features 0 = <AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
         Processor Features 1 = <0>
      Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA>
      Memory Model Features 1 = <>
             Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8>
             Debug Features 1 = <0>
         Auxiliary Features 0 = <0>
         Auxiliary Features 1 = <0>
CPU  1: (null) (null) r0p0 affinity:  0
CPU  2: (null) (null) r0p0 affinity:  0
CPU  3: (null) (null) r0p0 affinity:  0
  x0: ffff000000a1c000
  x1: fffffd000103a[ thread pid 0 tid 100057 ]
Stopped at      thread_lock_flags_+0x298:       ldr     w4, [x3, #156]
db> bt
Tracing pid 0 tid 100057 td 0xfffffd000103a000
db_trace_self() at db_stack_trace+0xec
         pc = 0xffff000000613688  lr = 0xffff000000084db4
         sp = 0xffff0000698f4260  fp = 0xffff0000698f4290

db_stack_trace() at db_command+0x224
         pc = 0xffff000000084db4  lr = 0xffff000000084a3c
         sp = 0xffff0000698f42a0  fp = 0xffff0000698f4380

db_command() at db_command_loop+0x60
         pc = 0xffff000000084a3c  lr = 0xffff0000000847fc
         sp = 0xffff0000698f4390  fp = 0xffff0000698f43b0

db_command_loop() at db_trap+0xf4
         pc = 0xffff0000000847fc  lr = 0xffff000000087964
         sp = 0xffff0000698f43c0  fp = 0xffff0000698f45e0

db_trap() at kdb_trap+0x180
         pc = 0xffff000000087964  lr = 0xffff0000003693e0
         sp = 0xffff0000698f45f0  fp = 0xffff0000698f4650
       
kdb_trap() at do_el1h_sync+0x90
         pc = 0xffff0000003693e0  lr = 0xffff00000062956c
         sp = 0xffff0000698f4660  fp = 0xffff0000698f4690

do_el1h_sync() at handle_el1h_sync+0x74
         pc = 0xffff00000062956c  lr = 0xffff000000615074
         sp = 0xffff0000698f46a0  fp = 0xffff0000698f47b0

handle_el1h_sync() at kdb_enter+0x38
         pc = 0xffff000000615074  lr = 0xffff000000368ac8
         sp = 0xffff0000698f47c0  fp = 0xffff0000698f4850

kdb_enter() at vpanic+0x180
         pc = 0xffff000000368ac8  lr = 0xffff000000326dd8
         sp = 0xffff0000698f4860  fp = 0xffff0000698f48d0

vpanic() at panic+0x48
         pc = 0xffff000000326dd8  lr = 0xffff000000326c54
         sp = 0xffff0000698f48e0  fp = 0xffff0000698f4960
       
panic() at data_abort+0x21c
         pc = 0xffff000000326c54  lr = 0xffff0000006298e8
         sp = 0xffff0000698f4970  fp = 0xffff0000698f4a20

data_abort() at do_el1h_sync+0xfc
         pc = 0xffff0000006298e8  lr = 0xffff0000006295d8
         sp = 0xffff0000698f4a30  fp = 0xffff0000698f4a60

do_el1h_sync() at handle_el1h_sync+0x74
         pc = 0xffff0000006295d8  lr = 0xffff000000615074
         sp = 0xffff0000698f4a70  fp = 0xffff0000698f4b80

handle_el1h_sync() at thread_lock_flags_+0x1a8
         pc = 0xffff000000615074  lr = 0xffff000000309060
         sp = 0xffff0000698f4b90  fp = 0xffff0000698f4c80

thread_lock_flags_() at statclock_cnt+0x11c
         pc = 0xffff000000309060  lr = 0xffff0000002c5b90
         sp = 0xffff0000698f4c90  fp = 0xffff0000698f4cb0
       
statclock_cnt() at handleevents+0x108
         pc = 0xffff0000002c5b90  lr = 0xffff00000064ad84
         sp = 0xffff0000698f4cc0  fp = 0xffff0000698f4d00

handleevents() at timercb+0xe0
         pc = 0xffff00000064ad84  lr = 0xffff00000064b51c
         sp = 0xffff0000698f4d10  fp = 0xffff0000698f4d80

timercb() at arm_tmr_intr+0x58
         pc = 0xffff00000064b51c  lr = 0xffff000000600e5c
         sp = 0xffff0000698f4d90  fp = 0xffff0000698f4d90

arm_tmr_intr() at intr_event_handle+0x64
         pc = 0xffff000000600e5c  lr = 0xffff0000002edd50
         sp = 0xffff0000698f4da0  fp = 0xffff0000698f4dd0

intr_event_handle() at intr_isrc_dispatch+0x30
         pc = 0xffff0000002edd50  lr = 0xffff00000064d8ec
         sp = 0xffff0000698f4de0  fp = 0xffff0000698f4df0
       
intr_isrc_dispatch() at arm_gic_intr+0xf0
         pc = 0xffff00000064d8ec  lr = 0xffff000000601848
         sp = 0xffff0000698f4e00  fp = 0xffff0000698f4e50

arm_gic_intr() at intr_irq_handler+0x60
         pc = 0xffff000000601848  lr = 0xffff00000064d6e0
         sp = 0xffff0000698f4e60  fp = 0xffff0000698f4e80

intr_irq_handler() at handle_el1h_irq+0x70
         pc = 0xffff00000064d6e0  lr = 0xffff000000615130
         sp = 0xffff0000698f4e90  fp = 0xffff0000698f4fa0

handle_el1h_irq() at ns8250_putc+0x2c
         pc = 0xffff000000615130  lr = 0xffff00000019a570
         sp = 0xffff0000698f4fb0  fp = 0xffff0000698f5050

ns8250_putc() at ns8250_putc+0x2c
         pc = 0xffff00000019a570  lr = 0xffff00000019a570
         sp = 0xffff0000698f5060  fp = 0xffff0000698f5080
       
ns8250_putc() at uart_cnputc+0x94
         pc = 0xffff00000019a570  lr = 0xffff0000001a0860
         sp = 0xffff0000698f5090  fp = 0xffff0000698f50c0

uart_cnputc() at cnputc+0x90
         pc = 0xffff0000001a0860  lr = 0xffff0000002cb3a8
         sp = 0xffff0000698f50d0  fp = 0xffff0000698f5120

cnputc() at cnputs+0xb4
         pc = 0xffff0000002cb3a8  lr = 0xffff0000002cb7c8
         sp = 0xffff0000698f5130  fp = 0xffff0000698f5150

cnputs() at putchar+0x158
         pc = 0xffff0000002cb7c8  lr = 0xffff00000036f04c
         sp = 0xffff0000698f5160  fp = 0xffff0000698f51e0

putchar() at kvprintf+0xda8
         pc = 0xffff00000036f04c  lr = 0xffff00000036ec70
         sp = 0xffff0000698f51f0  fp = 0xffff0000698f5300
       
kvprintf() at vprintf+0x7c
         pc = 0xffff00000036ec70  lr = 0xffff00000036f838
         sp = 0xffff0000698f5310  fp = 0xffff0000698f5420

vprintf() at printf+0x48
         pc = 0xffff00000036f838  lr = 0xffff00000036f7ac
         sp = 0xffff0000698f5430  fp = 0xffff0000698f54b0

printf() at print_registers+0x4c
         pc = 0xffff00000036f7ac  lr = 0xffff00000062966c
         sp = 0xffff0000698f54c0  fp = 0xffff0000698f54f0

print_registers() at data_abort+0x1f0
         pc = 0xffff00000062966c  lr = 0xffff0000006298bc
         sp = 0xffff0000698f5500  fp = 0xffff0000698f55b0

data_abort() at do_el1h_sync+0xfc
         pc = 0xffff0000006298bc  lr = 0xffff0000006295d8
         sp = 0xffff0000698f55c0  fp = 0xffff0000698f55f0
       
do_el1h_sync() at handle_el1h_sync+0x74
         pc = 0xffff0000006295d8  lr = 0xffff000000615074
         sp = 0xffff0000698f5600  fp = 0xffff0000698f5710

handle_el1h_sync() at sched_switch+0x54c
         pc = 0xffff000000615074  lr = 0xffff000000351dd4
         sp = 0xffff0000698f5720  fp = 0xffff0000698f5800

sched_switch() at mi_switch+0x118
         pc = 0xffff000000351dd4  lr = 0xffff000000330c14
         sp = 0xffff0000698f5810  fp = 0xffff0000698f5830

mi_switch() at taskqgroup_binder+0x74
         pc = 0xffff000000330c14  lr = 0xffff000000367864
         sp = 0xffff0000698f5840  fp = 0xffff0000698f5860

taskqgroup_binder() at gtaskqueue_run_locked+0x160
         pc = 0xffff000000367864  lr = 0xffff000000367710
         sp = 0xffff0000698f5870  fp = 0xffff0000698f58e0
       
gtaskqueue_run_locked() at gtaskqueue_thread_loop+0xcc
         pc = 0xffff000000367710  lr = 0xffff0000003672c8
         sp = 0xffff0000698f58f0  fp = 0xffff0000698f5910

gtaskqueue_thread_loop() at fork_exit+0x94
         pc = 0xffff0000003672c8  lr = 0xffff0000002eab20
         sp = 0xffff0000698f5920  fp = 0xffff0000698f5950

fork_exit() at fork_trampoline+0x10
         pc = 0xffff0000002eab20  lr = 0xffff00000062934c
         sp = 0xffff0000698f5960  fp = 0x0000000000000000


Booting with a debug kernel worked fine. (This matches up
with past reports about "recent" pine64+ handling.)

But trying to have the root file system on a USB SSD
drive failed to see the USB drive at all. (This matches
up with past reports about "recent" pine64+ handling.)


From a separate non-debug kernel boot attempt:
(remember the "thread_lock_flags_+0x298: ldr w4, [x3, #156]"
but also note x8 in addition to x3)

db> show reg
spsr        0x96000004000003c5
x0          0xffff00000069b000  $d.2+0x1ac
x1                         0x2
x2          0xffff00000069ba48  $d.5+0x1d
x3                  0xdeadc0d8 <<<<<<<<< Note the "0xdeadc0d8"
x4                         0x3
x5          0xffff000000610cf0  generic_bs_barrier
x6                           0
x7                        0x40  $d.14
x8                  0xdeadc0de <<<<<<<<< Note the "0xdeadc0de"
x9                           0
x10                 0x975c860b
x11                 0x975c860b
x12                  0x51eb850
x13                        0x4
x14                       0x66  $d.9+0x26
x15         0xffff0000007004ce  hex2ascii_data
x16                          0
x17                          0
x18         0xffff00006990ec10
x19         0xfffffd000103a000
x20         0xffff000000bcee70  blocked_lock+0x18
x21         0xffff00000080e5a8  sdt_lockstat___spin__release
x22                  0x3938700
x23         0xfffffd000103a000
x24         0xffff000000bcee58  blocked_lock
x25                        0x4
x26                   0x98967f
x27         0xffff0000009ef000  next_to_notify
x28         0xffff000000bb9000  proc0+0x4f8
x29         0xffff00006990ec80
lr          0xffff000000309064  thread_lock_flags_+0x1ac
elr         0xffff000000309154  thread_lock_flags_+0x29c
sp          0xffff00006990ec10
thread_lock_flags_+0x298:       ldr     w4, [x3, #156]
db> bt
Tracing pid 0 tid 100057 td 0xfffffd000103a000
db_trace_self() at db_stack_trace+0xec
         pc = 0xffff000000613688  lr = 0xffff000000084db4
         sp = 0xffff00006990e260  fp = 0xffff00006990e290

db_stack_trace() at db_command+0x224
         pc = 0xffff000000084db4  lr = 0xffff000000084a3c
         sp = 0xffff00006990e2a0  fp = 0xffff00006990e380

db_command() at db_command_loop+0x60
         pc = 0xffff000000084a3c  lr = 0xffff0000000847fc
         sp = 0xffff00006990e390  fp = 0xffff00006990e3b0

db_command_loop() at db_trap+0xf4
         pc = 0xffff0000000847fc  lr = 0xffff000000087964
         sp = 0xffff00006990e3c0  fp = 0xffff00006990e5e0

db_trap() at kdb_trap+0x180
         pc = 0xffff000000087964  lr = 0xffff0000003693e0
         sp = 0xffff00006990e5f0  fp = 0xffff00006990e650
       
kdb_trap() at do_el1h_sync+0x90
         pc = 0xffff0000003693e0  lr = 0xffff00000062956c
         sp = 0xffff00006990e660  fp = 0xffff00006990e690

do_el1h_sync() at handle_el1h_sync+0x74
         pc = 0xffff00000062956c  lr = 0xffff000000615074
         sp = 0xffff00006990e6a0  fp = 0xffff00006990e7b0

handle_el1h_sync() at kdb_enter+0x38
         pc = 0xffff000000615074  lr = 0xffff000000368ac8
         sp = 0xffff00006990e7c0  fp = 0xffff00006990e850

kdb_enter() at vpanic+0x180
         pc = 0xffff000000368ac8  lr = 0xffff000000326dd8
         sp = 0xffff00006990e860  fp = 0xffff00006990e8d0

vpanic() at panic+0x48
         pc = 0xffff000000326dd8  lr = 0xffff000000326c54
         sp = 0xffff00006990e8e0  fp = 0xffff00006990e960
       
panic() at data_abort+0x21c
         pc = 0xffff000000326c54  lr = 0xffff0000006298e8
         sp = 0xffff00006990e970  fp = 0xffff00006990ea20

data_abort() at do_el1h_sync+0xfc
         pc = 0xffff0000006298e8  lr = 0xffff0000006295d8
         sp = 0xffff00006990ea30  fp = 0xffff00006990ea60

do_el1h_sync() at handle_el1h_sync+0x74
         pc = 0xffff0000006295d8  lr = 0xffff000000615074
         sp = 0xffff00006990ea70  fp = 0xffff00006990eb80

handle_el1h_sync() at thread_lock_flags_+0x1a8
         pc = 0xffff000000615074  lr = 0xffff000000309060
         sp = 0xffff00006990eb90  fp = 0xffff00006990ec80

thread_lock_flags_() at statclock_cnt+0x11c
         pc = 0xffff000000309060  lr = 0xffff0000002c5b90
         sp = 0xffff00006990ec90  fp = 0xffff00006990ecb0
       
statclock_cnt() at handleevents+0x108
         pc = 0xffff0000002c5b90  lr = 0xffff00000064ad84
         sp = 0xffff00006990ecc0  fp = 0xffff00006990ed00

handleevents() at timercb+0xe0
         pc = 0xffff00000064ad84  lr = 0xffff00000064b51c
         sp = 0xffff00006990ed10  fp = 0xffff00006990ed80

timercb() at arm_tmr_intr+0x58
         pc = 0xffff00000064b51c  lr = 0xffff000000600e5c
         sp = 0xffff00006990ed90  fp = 0xffff00006990ed90

arm_tmr_intr() at intr_event_handle+0x64
         pc = 0xffff000000600e5c  lr = 0xffff0000002edd50
         sp = 0xffff00006990eda0  fp = 0xffff00006990edd0

intr_event_handle() at intr_isrc_dispatch+0x30
         pc = 0xffff0000002edd50  lr = 0xffff00000064d8ec
         sp = 0xffff00006990ede0  fp = 0xffff00006990edf0
       
intr_isrc_dispatch() at arm_gic_intr+0xf0
         pc = 0xffff00000064d8ec  lr = 0xffff000000601848
         sp = 0xffff00006990ee00  fp = 0xffff00006990ee50

arm_gic_intr() at intr_irq_handler+0x60
         pc = 0xffff000000601848  lr = 0xffff00000064d6e0
         sp = 0xffff00006990ee60  fp = 0xffff00006990ee80

intr_irq_handler() at handle_el1h_irq+0x70
         pc = 0xffff00000064d6e0  lr = 0xffff000000615130
         sp = 0xffff00006990ee90  fp = 0xffff00006990efa0

handle_el1h_irq() at ns8250_putc+0x2c
         pc = 0xffff000000615130  lr = 0xffff00000019a570
         sp = 0xffff00006990efb0  fp = 0xffff00006990f050

ns8250_putc() at ns8250_putc+0x2c
         pc = 0xffff00000019a570  lr = 0xffff00000019a570
         sp = 0xffff00006990f060  fp = 0xffff00006990f080
       
ns8250_putc() at uart_cnputc+0x94
         pc = 0xffff00000019a570  lr = 0xffff0000001a0860
         sp = 0xffff00006990f090  fp = 0xffff00006990f0c0

uart_cnputc() at cnputc+0x90
         pc = 0xffff0000001a0860  lr = 0xffff0000002cb3a8
         sp = 0xffff00006990f0d0  fp = 0xffff00006990f120

cnputc() at cnputs+0xb4
         pc = 0xffff0000002cb3a8  lr = 0xffff0000002cb7c8
         sp = 0xffff00006990f130  fp = 0xffff00006990f150

cnputs() at putchar+0x158
         pc = 0xffff0000002cb7c8  lr = 0xffff00000036f04c
         sp = 0xffff00006990f160  fp = 0xffff00006990f1e0

putchar() at kvprintf+0xda8
         pc = 0xffff00000036f04c  lr = 0xffff00000036ec70
         sp = 0xffff00006990f1f0  fp = 0xffff00006990f300
       
kvprintf() at vprintf+0x7c
         pc = 0xffff00000036ec70  lr = 0xffff00000036f838
         sp = 0xffff00006990f310  fp = 0xffff00006990f420

vprintf() at printf+0x48
         pc = 0xffff00000036f838  lr = 0xffff00000036f7ac
         sp = 0xffff00006990f430  fp = 0xffff00006990f4b0

printf() at print_registers+0x4c
         pc = 0xffff00000036f7ac  lr = 0xffff00000062966c
         sp = 0xffff00006990f4c0  fp = 0xffff00006990f4f0

print_registers() at data_abort+0x1f0
         pc = 0xffff00000062966c  lr = 0xffff0000006298bc
         sp = 0xffff00006990f500  fp = 0xffff00006990f5b0

data_abort() at do_el1h_sync+0xfc
         pc = 0xffff0000006298bc  lr = 0xffff0000006295d8
         sp = 0xffff00006990f5c0  fp = 0xffff00006990f5f0
       
do_el1h_sync() at handle_el1h_sync+0x74
         pc = 0xffff0000006295d8  lr = 0xffff000000615074
         sp = 0xffff00006990f600  fp = 0xffff00006990f710

handle_el1h_sync() at sched_switch+0x54c
         pc = 0xffff000000615074  lr = 0xffff000000351dd4
         sp = 0xffff00006990f720  fp = 0xffff00006990f800

sched_switch() at mi_switch+0x118
         pc = 0xffff000000351dd4  lr = 0xffff000000330c14
         sp = 0xffff00006990f810  fp = 0xffff00006990f830

mi_switch() at taskqgroup_binder+0x74
         pc = 0xffff000000330c14  lr = 0xffff000000367864
         sp = 0xffff00006990f840  fp = 0xffff00006990f860

taskqgroup_binder() at gtaskqueue_run_locked+0x160
         pc = 0xffff000000367864  lr = 0xffff000000367710
         sp = 0xffff00006990f870  fp = 0xffff00006990f8e0
       
gtaskqueue_run_locked() at gtaskqueue_thread_loop+0xcc
         pc = 0xffff000000367710  lr = 0xffff0000003672c8
         sp = 0xffff00006990f8f0  fp = 0xffff00006990f910

gtaskqueue_thread_loop() at fork_exit+0x94
         pc = 0xffff0000003672c8  lr = 0xffff0000002eab20
         sp = 0xffff00006990f920  fp = 0xffff00006990f950

fork_exit() at fork_trampoline+0x10
         pc = 0xffff0000002eab20  lr = 0xffff00000062934c
         sp = 0xffff00006990f960  fp = 0x0000000000000000



===
Mark Millard
markmi at dsl-only.net

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

Mark Millard-2
On 2017-Sep-10, at 1:17 PM, Warner Losh <imp at bsdimp.com> wrote:

> On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard <[hidden email]> wrote:
> When I attempted to use the result of:
>
> # cp -aRx /usr/obj/DESTDIRs/clang-cortexA53-installworld/boot/boot1.efi /mnt/EFI/BOOT/
>
> the pine64+ boot sequence got over and over
> a sequence like:
>
> U-Boot 2017.07 (Sep 06 2017 - 07:49:12 +0000) Allwinner Technology
>
> CPU:   Allwinner A64 (SUN50I)
> Model: Pine64+
> DRAM:  2 GiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
>
> In:    serial
> Out:   serial
> . . .
> >> FreeBSD EFI boot block
>    Loader path: /boot/loader.efi
>
>    Initializing modules: ZFS UFS
>    Load Path:
> "Synchronous Abort" handler, esr 0x96000004
> ELR:     bdf90b30
> LR:      bdf8fb6c
> x0 : 0000000000000000 x1 : 0000000000000000
> x2 : 00000000bdffc000 x3 : 0000000040000000
> x4 : 00000000b9f34d40 x5 : 0000000000000000
> x6 : 0000000000000015 x7 : 0000000000000000
> x8 : 00000000bdfa59b8 x9 : 000000000000001c
> x10: 0000000000000002 x11: 0000000000000000
> x12: 0000000000000000 x13: 0000000000000000
> x14: 0000000000000000 x15: 0000000000000000
> x16: 0000000000000000 x17: 0000000000000000
> x18: 00000000b9f39df8 x19: 0000000000000000
> x20: 0000000000000000 x21: 0000000000000002
> x22: 00000000b8f34c98 x23: 00000000b8f34c88
> x24: 00000000b8f34ca0 x25: 00000000000007d0
> x26: 00000000b8f34c90 x27: 00000000b8f2f198
> x28: 0000000000000000 x29: 00000000b9f34de0
>
> Resetting CPU ...
>
> resetting ...
>
> It would be super helpful if you could bisect the change that caused this.

I'm doing some other experiments first but I'll
probably take a stab at it if things seem stable
enough. Pine64+ has multiple problems currently.
(It regressed some time back.)

Unfortunately I do not have a known way to reproduce
the older boot1.efi file fully. I'll have to explore
that part to have a known-good low bound. If I'm
lucky the first try from the general time frame will
happen to work.

Do to other issues I'm jumping from pre-INO64 to modern
without having tracked in the middle.


I will note that the older boot1.efi (as bootaa64.efi)
output is different (no "Load Path:"):

>> FreeBSD EFI boot block
   Loader path: /boot/loader.efi

   Initializing modules: ZFS UFS
   Probing 3 block devices.....* done
    ZFS found no pools
    UFS found 1 partition
Consoles: EFI console  
Command line arguments: loader.efi
Image base: 0xb6dbb008
EFI version: 2.05
EFI Firmware: Das U-boot (rev 0.00)

The failing one has garbage (invisible)
text after "Load Path:".

===
Mark Millard
markmi at dsl-only.net

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: head -r323246 Pine64+ 2GB context: boot1.efi (as bootaa64.efi), I had to revert to an older one that I had around; more

Mark Millard-2
[Warner: looks like you were thinking in the
correct general direction. Details below.]

On 2017-Sep-10, at 3:17 PM, Warner Losh <imp at bsdimp.com> wrote:

> On Sun, Sep 10, 2017 at 3:18 PM, Mark Millard <markmi at dsl-only.net> wrote:
> On 2017-Sep-10, at 1:17 PM, Warner Losh <imp at bsdimp.com> wrote:
>
> > On Sun, Sep 10, 2017 at 2:34 AM, Mark Millard <[hidden email]> wrote:
> > When I attempted to use the result of:
> >
> > # cp -aRx /usr/obj/DESTDIRs/clang-cortexA53-installworld/boot/boot1.efi /mnt/EFI/BOOT/
> >
> > the pine64+ boot sequence got over and over
> > a sequence like:
> >
> > U-Boot 2017.07 (Sep 06 2017 - 07:49:12 +0000) Allwinner Technology
> >
> > CPU:   Allwinner A64 (SUN50I)
> > Model: Pine64+
> > DRAM:  2 GiB
> > MMC:   SUNXI SD/MMC: 0
> > *** Warning - bad CRC, using default environment
> >
> > In:    serial
> > Out:   serial
> > . . .
> > >> FreeBSD EFI boot block
> >    Loader path: /boot/loader.efi
> >
> >    Initializing modules: ZFS UFS
> >    Load Path:
> > "Synchronous Abort" handler, esr 0x96000004
> > ELR:     bdf90b30
> > LR:      bdf8fb6c
> > x0 : 0000000000000000 x1 : 0000000000000000
> > x2 : 00000000bdffc000 x3 : 0000000040000000
> > x4 : 00000000b9f34d40 x5 : 0000000000000000
> > x6 : 0000000000000015 x7 : 0000000000000000
> > x8 : 00000000bdfa59b8 x9 : 000000000000001c
> > x10: 0000000000000002 x11: 0000000000000000
> > x12: 0000000000000000 x13: 0000000000000000
> > x14: 0000000000000000 x15: 0000000000000000
> > x16: 0000000000000000 x17: 0000000000000000
> > x18: 00000000b9f39df8 x19: 0000000000000000
> > x20: 0000000000000000 x21: 0000000000000002
> > x22: 00000000b8f34c98 x23: 00000000b8f34c88
> > x24: 00000000b8f34ca0 x25: 00000000000007d0
> > x26: 00000000b8f34c90 x27: 00000000b8f2f198
> > x28: 0000000000000000 x29: 00000000b9f34de0
> >
> > Resetting CPU ...
> >
> > resetting ...
> >
> > It would be super helpful if you could bisect the change that caused this.
>
> I'm doing some other experiments first but I'll
> probably take a stab at it if things seem stable
> enough. Pine64+ has multiple problems currently.
> (It regressed some time back.)
>
> Unfortunately I do not have a known way to reproduce
> the older boot1.efi file fully. I'll have to explore
> that part to have a known-good low bound. If I'm
> lucky the first try from the general time frame will
> happen to work.
>
> Do to other issues I'm jumping from pre-INO64 to modern
> without having tracked in the middle.
>
>
> I will note that the older boot1.efi (as bootaa64.efi)
> output is different (no "Load Path:"):
>
> >> FreeBSD EFI boot block
>    Loader path: /boot/loader.efi
>
>    Initializing modules: ZFS UFS
>    Probing 3 block devices.....* done
>     ZFS found no pools
>     UFS found 1 partition
> Consoles: EFI console
> Command line arguments: loader.efi
> Image base: 0xb6dbb008
> EFI version: 2.05
> EFI Firmware: Das U-boot (rev 0.00)
>
> The failing one has garbage (invisible)
> text after "Load Path:".
>
> My first guess, and it's just a shot in the dark, is that the UEFI subset that u-boot implements doesn't implement the device path to text protocols, so we're jumping into the middle of cloud cuckoo land and/or printing stack trash.
>
> This is new functionality designed to help track WTF we booted from.

Based on your guess I explored just recent changes
that looked to be tied to your guesses.

The following back-off of 2 file revisions
was enough to build a working boot1.efi (as
bootaa64.efi) for the Pine64+ 2GB :

# svnlite update -r322941 /usr/src/sys/boot/efi/boot1/boot1.c /usr/src/sys/boot/efi/include/efiapi.h

-r323064 was not far enough back for these 2 soruces:
failed just like -r323246 did. I did not directly
try -r323063 . I can if you want.

Revision 323064 - Directory Listing
Modified Thu Aug 31 17:32:19 2017 UTC (10 days, 12 hours ago) by imp
Exit rather than panic for most errors.

In the FreeBSD UEFI boot protocol, boot1.efi exits back to UEFI if it
can't boot the image for most reasons (so that further items in the
EFI boot manger list can be tried). Rename panic to efi_panic, make it
static and give it an extra status argument. Exit back to UEFI with
that status argument so the next loader can be tried.

Use malloc/free exclusively instead of mixing malloc/free and
AllocatePool/FreePool. The code is smaller.

Sponsored by: Netflix



Revision 323063 - Directory Listing
Modified Thu Aug 31 17:32:14 2017 UTC (10 days, 12 hours ago) by imp
boot1.efi: print more info about where boot1.efi is loaded from

Print the device that boot1.efi was loaded from. Print the path as
well (since it isn't included in DeviceHandle). Move block where we do
this earlier so all the block handle code is now together.

Sponsored by: Netflix


Revision 322941 - Directory Listing
Modified Sun Aug 27 03:10:16 2017 UTC (2 weeks, 1 day ago) by imp
Eliminate redunant device path matching.

Use efi_devpath_match instead of device_paths_match. They are
functionally the same. Remove device_paths_match from boot1.c and call
efi_devpath_match instead.

Sponsored by: Netflix


===
Mark Millard
markmi at dsl-only.net


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: head -r323246 Pine64+ 2GB boot time context: acquiring blockable sleep lock with spinlock or critical section held for data_abort calling pmap_fault calling __mtx_lock_flags

Mark Millard-2
In reply to this post by Mark Millard-2
[I got another blockable sleep lock panic during
the Pine64+ 2GB boot, this time with ddb> input
working. I show both the older example and the
new one.]

On 2017-Sep-10, at 3:25 PM, Mark Millard <[hidden email]> wrote:

> [I got a boot-time panic with a debug kernel that
> reported a "acquiring blockable sleep lock with
> spinlock or critical section held (sleep mutex)".
> This was for data_abort calling pmap_fault calling
> __mtx_lock_flags . I first include prior non-debug
> kernel reports in case they are related.]
>
> . . .
>
> . . .
> Release APs
> APs not started
> CPU  0: ARM Cortex-A53 r0p4 affinity:  0
> Instruction Set Attributes 0 = <AES+PMULL,SHA1,SHA2,CRC32>
> Instruction Set Attributes 1 = <0>
>         Processor Features 0 = <AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
>         Processor Features 1 = <0>
>      Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA>
>      Memory Model Features 1 = <>
>             Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8>
>             Debug Features 1 = <0>
>         Auxiliary Features 0 = <0>
>         Auxiliary Features 1 = <0>
> CPU  1: (null) (null) r0p0 affinity:  0
> CPU  2: (null) (null) r0p0 affinity:  0
> CPU  3: (null) (null) r0p0 affinity:  0
> panic: acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710
> cpuid = 0
> time = 13
> KDB: stack backtrace:
> db_trace_self() at db_trace_self_wrapper+0x28
>         pc = 0xffff0000005efc78  lr = 0xffff000000088094
>         sp = 0xffff000069850080  fp = 0xffff000069850290
>
> db_trace_self_wrapper() at vpanic+0x164
>         pc = 0xffff000000088094  lr = 0xffff00000031764c
>         sp = 0xffff0000698502a0  fp = 0xffff000069850310
>
> vpanic() at kassert_panic+0x15c
>         pc = 0xffff00000031764c  lr = 0xffff0000003174e4
>         sp = 0xffff000069850320  fp = 0xffff0000698503e0
>
> kassert_panic() at witness_checkorder+0x160
>         pc = 0xffff0000003174e4  lr = 0xffff000000374990
>         sp = 0xffff0000698503f0  fp = 0xffff000069850470
>
> witness_checkorder() at __mtx_lock_flags+0xa8
>         pc = 0xffff000000374990  lr = 0xffff0000002f8b7c
>         sp = 0xffff000069850480  fp = 0xffff0000698504b0
>
> __mtx_lock_flags() at pmap_fault+0x40
>         pc = 0xffff0000002f8b7c  lr = 0xffff000000606994
>         sp = 0xffff0000698504c0  fp = 0xffff0000698504e0
>
> pmap_fault() at data_abort+0xb8
>         pc = 0xffff000000606994  lr = 0xffff000000608a9c
>         sp = 0xffff0000698504f0  fp = 0xffff0000698505a0
>
> data_abort() at do_el1h_sync+0xfc
>         pc = 0xffff000000608a9c  lr = 0xffff0000006088f0
>         sp = 0xffff0000698505b0  fp = 0xffff0000698505e0
>
> do_el1h_sync() at handle_el1h_sync+0x74
>         pc = 0xffff0000006088f0  lr = 0xffff0000005f1874
>         sp = 0xffff0000698505f0  fp = 0xffff000069850700
>
> handle_el1h_sync() at sched_switch+0x2a8
>         pc = 0xffff0000005f1874  lr = 0xffff00000033f0c8
>         sp = 0xffff000069850710  fp = 0xffff0000698507f0
>
> sched_switch() at mi_switch+0x1b8
>         pc = 0xffff00000033f0c8  lr = 0xffff00000032161c
>         sp = 0xffff000069850800  fp = 0xffff000069850820
>
> mi_switch() at taskqgroup_binder+0x7c
>         pc = 0xffff00000032161c  lr = 0xffff00000035510c
>         sp = 0xffff000069850830  fp = 0xffff000069850860
>
> taskqgroup_binder() at gtaskqueue_run_locked+0x104
>         pc = 0xffff00000035510c  lr = 0xffff000000354f74
>         sp = 0xffff000069850870  fp = 0xffff0000698508e0
>
> gtaskqueue_run_locked() at gtaskqueue_thread_loop+0x9c
>         pc = 0xffff000000354f74  lr = 0xffff000000354d10
>         sp = 0xffff0000698508f0  fp = 0xffff000069850910
>
> gtaskqueue_thread_loop() at fork_exit+0x7c
>         pc = 0xffff000000354d10  lr = 0xffff0000002dbd3c
>         sp = 0xffff000069850920  fp = 0xffff000069850950
>
> fork_exit() at fork_trampoline+0x10
>         pc = 0xffff0000002dbd3c  lr = 0xffff000000608664
>         sp = 0xffff000069850960  fp = 0x0000000000000000
>
> KDB: enter: panic
> [ thread pid 0 tid 100058 ]
> Stopped at      sched_switch+0x2b8:     ldrb    w9, [x8, #894]
> db>
>
> Unfortunately it was not taking console input so that is
> all I got.

From the new example:

CPU  1: (null) (null) r0p0 affinity:  0
CPU  2: (null) (null) r0p0 affinity:  0
CPU  3: (null) (null) r0p0 affinity:  0
panic: acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710
cpuid = 0
time = 13
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
         pc = 0xffff0000005efc78  lr = 0xffff000000088094
         sp = 0xffff000069850080  fp = 0xffff000069850290

db_trace_self_wrapper() at vpanic+0x164
         pc = 0xffff000000088094  lr = 0xffff00000031764c
         sp = 0xffff0000698502a0  fp = 0xffff000069850310

vpanic() at kassert_panic+0x15c
         pc = 0xffff00000031764c  lr = 0xffff0000003174e4
         sp = 0xffff000069850320  fp = 0xffff0000698503e0

kassert_panic() at witness_checkorder+0x160
         pc = 0xffff0000003174e4  lr = 0xffff000000374990
         sp = 0xffff0000698503f0  fp = 0xffff000069850470

witness_checkorder() at __mtx_lock_flags+0xa8
         pc = 0xffff000000374990  lr = 0xffff0000002f8b7c
         sp = 0xffff000069850480  fp = 0xffff0000698504b0

__mtx_lock_flags() at pmap_fault+0x40
         pc = 0xffff0000002f8b7c  lr = 0xffff000000606994
         sp = 0xffff0000698504c0  fp = 0xffff0000698504e0

pmap_fault() at data_abort+0xb8
         pc = 0xffff000000606994  lr = 0xffff000000608a9c
         sp = 0xffff0000698504f0  fp = 0xffff0000698505a0

data_abort() at do_el1h_sync+0xfc
         pc = 0xffff000000608a9c  lr = 0xffff0000006088f0
         sp = 0xffff0000698505b0  fp = 0xffff0000698505e0

do_el1h_sync() at handle_el1h_sync+0x74
         pc = 0xffff0000006088f0  lr = 0xffff0000005f1874
         sp = 0xffff0000698505f0  fp = 0xffff000069850700

handle_el1h_sync() at sched_switch+0x2a8
         pc = 0xffff0000005f1874  lr = 0xffff00000033f0c8
         sp = 0xffff000069850710  fp = 0xffff0000698507f0

sched_switch() at mi_switch+0x1b8
         pc = 0xffff00000033f0c8  lr = 0xffff00000032161c
         sp = 0xffff000069850800  fp = 0xffff000069850820

mi_switch() at taskqgroup_binder+0x7c
         pc = 0xffff00000032161c  lr = 0xffff00000035510c
         sp = 0xffff000069850830  fp = 0xffff000069850860

taskqgroup_binder() at gtaskqueue_run_locked+0x104
         pc = 0xffff00000035510c  lr = 0xffff000000354f74
         sp = 0xffff000069850870  fp = 0xffff0000698508e0

gtaskqueue_run_locked() at gtaskqueue_thread_loop+0x9c
         pc = 0xffff000000354f74  lr = 0xffff000000354d10
         sp = 0xffff0000698508f0  fp = 0xffff000069850910

gtaskqueue_thread_loop() at fork_exit+0x7c
         pc = 0xffff000000354d10  lr = 0xffff0000002dbd3c
         sp = 0xffff000069850920  fp = 0xffff000069850950

fork_exit() at fork_trampoline+0x10
         pc = 0xffff0000002dbd3c  lr = 0xffff000000608664
         sp = 0xffff000069850960  fp = 0x0000000000000000

KDB: enter: panic
[ thread pid 0 tid 100058 ]
Stopped at      sched_switch+0x2b8:     ldrb    w9, [x8, #894]

It turns our that x8 is reported as holding the value zero:

db> show regs
No such command; use "help" to list available commands
db> show reg
spsr        0x9600000440000085
x0          0xffff000000ac1000  __pcpu+0x200
x1                         0x4
x2          0xffff00000068a5cb  $d.4+0x15c
x3                       0x218  $d.9+0x1d8
x4                           0
x5                        0x11
x6          0xffff000000a45f20
x7                        0x40  $d.14
x8                           0
x9                         0x5
x10         0xffff0000009a7d88  tdq_cpu+0xe08
x11                       0x18
x12                   0x1ddc88
x13                 0x7ff707d0
x14                          0
x15                 0x7ff6e010
x16                     0x2af8  $d.1+0x122e
x17                     0x27c0  $d.1+0xef6
x18         0xffff000069850790
x19         0xfffffd0001415a80
x20         0xffff0000009a7c80  tdq_cpu+0xd00
x21         0xffff0000009a6f80  tdq_cpu
x22         0xffff0000009a7d1d  tdq_cpu+0xd9d
x23                        0x1
x24                          0
x25         0xffff0000009a6f80  tdq_cpu
x26         0xffff000000c85000  dpcpu+0x158
x27         0xffff000000c85000  dpcpu+0x158
x28                          0
x29         0xffff0000698507f0
lr          0xffff00000033f0cc  sched_switch+0x2ac
elr         0xffff00000033f0dc  sched_switch+0x2bc
sp          0xffff000069850790
sched_switch+0x2b8:     ldrb    w9, [x8, #894]

db> show lockchain
thread 100058 (pid 0, softirq_1) is on a run queue
db> show locks
db> show lock
db> show locktree
db> show sleepqueue
db> show sleepq
ddb> show sleepchain
thread 100058 (pid 0, softirq_1) is on a run queue
db> show alllocks
Process 0 (kernel) thread 0xffff000000acd500 (100000)
exclusive sleep mutex Giant (Giant) r = 0 (0xffff000000c5d860) locked @ /usr/src/sys/kern/kern_module.c:116
db> show allchains
chain 1:
 thread 100049 (pid 18, vmdaemon) sleeping on 0xffff000000aa811c "psleep"
chain 2:
 thread 100054 (pid 17, laundry: dom0) sleeping on 0xffff000000aa80c4 "launds"
chain 3:
 thread 100055 (pid 17, uma) sleeping on 0xffff000000aa7b68 "umarcl"
chain 4:
 thread 100047 (pid 16, mmcsd0: mmc/sd card) sleeping on 0xfffffd0000638800 "mmcsd disk jobqueue"
chain 5:
 thread 100046 (pid 15, soaiod4) sleeping on 0xffff000000a9dbe4 "-"
chain 6:
 thread 100045 (pid 9, soaiod3) sleeping on 0xffff000000a9dbe4 "-"
chain 7:
 thread 100044 (pid 8, soaiod2) sleeping on 0xffff000000a9dbe4 "-"
chain 8:
 thread 100043 (pid 7, soaiod1) sleeping on 0xffff000000a9dbe4 "-"
chain 9:
 thread 100036 (pid 5, sctp_iterator) sleeping on 0xffff000000c7bf20 "waiting_for_work"
chain 10:
 thread 100028 (pid 14, usbus0) sleeping on 0xffff000040925358 "-"
chain 11:
 thread 100029 (pid 14, usbus0) sleeping on 0xffff0000409253b0 "-"
chain 12:
 thread 100030 (pid 14, usbus0) sleeping on 0xffff000040925408 "-"
chain 13:
 thread 100031 (pid 14, usbus0) sleeping on 0xffff000040925460 "-"
chain 14:
 thread 100032 (pid 14, usbus0) sleeping on 0xffff0000409254b8 "-"
chain 15:
 thread 100025 (pid 4, doneq0) sleeping on 0xffff000000878280 "-"
chain 16:
 thread 100042 (pid 4, scanner) sleeping on 0xffff0000008780c8 "-"
chain 17:
 thread 100024 (pid 3, crypto returns) sleeping on 0xffff000000aa6008 "crypto_ret_wait"
chain 18:
 thread 100023 (pid 2, crypto) sleeping on 0xffff000000aa5ec0 "crypto_wait"
chain 19:
 thread 100019 (pid 13, g_event) sleeping on 0xffff000000c6a450 "-"
chain 20:
 thread 100020 (pid 13, g_up) sleeping on 0xffff000000c6a460 "-"
chain 21:
 thread 100021 (pid 13, g_down) sleeping on 0xffff000000c6a458 "-"
chain 22:
 thread 100014 (pid 12, swi4: clock (0)) blocked on lock 0xffff000000c5d860 (sleep mutex) "Giant"
 thread 100000 (pid 0, swapper) is on a run queue
chain 23:
 thread 100002 (pid 1, kernel) blocked on lock 0xffff000000c5d860 (sleep mutex) "Giant"
 thread 100000 (pid 0, swapper) is on a run queue
chain 24:
 thread 100001 (pid 10, audit) sleeping on 0xffff000000c808e0 "audit_worker_cv"
chain 25:
 thread 100009 (pid 0, thread taskq) sleeping on 0xfffffd00005f2b00 "-"
chain 26:
 thread 100010 (pid 0, aiod_kick taskq) sleeping on 0xfffffd00005f2a00 "-"
chain 27:
 thread 100012 (pid 0, kqueue_ctx taskq) sleeping on 0xfffffd00005f2700 "-"
chain 28:
 thread 100022 (pid 0, firmware taskq) sleeping on 0xfffffd00005f2000 "-"
chain 29:
 thread 100037 (pid 0, acpi_task_0) sleeping on 0xfffffd00005f1400 "-"
chain 30:
 thread 100038 (pid 0, acpi_task_1) sleeping on 0xfffffd00005f1400 "-"
chain 31:
 thread 100039 (pid 0, acpi_task_2) sleeping on 0xfffffd00005f1400 "-"
chain 32:
 thread 100041 (pid 0, CAM taskq) sleeping on 0xfffffd00005f1e00 "-"
chain 33:
 thread 100056 (pid 0, if_config_tqg_0) sleeping on 0xfffffd00005f1300 "-"
chain 34:
 thread 100057 (pid 0, softirq_0) sleeping on 0xfffffd00005f1200 "-"
chain 35:
 thread 100059 (pid 0, softirq_2) sleeping on 0xfffffd00005f1000 "-"
chain 36:
 thread 100060 (pid 0, softirq_3) sleeping on 0xfffffd00005f0e00 "-"


The code for:

panic: acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4710

is the PMAP_LOCK in:

int
pmap_fault(pmap_t pmap, uint64_t esr, uint64_t far)
{
#ifdef SMP
        uint64_t par;
#endif
 
        switch (ESR_ELx_EXCEPTION(esr)) {
        case EXCP_DATA_ABORT_L:
        case EXCP_DATA_ABORT:
                break;
        default:
                return (KERN_FAILURE);
        }
 
#ifdef SMP
        PMAP_LOCK(pmap);
        switch (esr & ISS_DATA_DFSC_MASK) {
        case ISS_DATA_DFSC_TF_L0:
        case ISS_DATA_DFSC_TF_L1:
        case ISS_DATA_DFSC_TF_L2:
        case ISS_DATA_DFSC_TF_L3:
                /* Ask the MMU to check the address */
                if (pmap == kernel_pmap)
                        par = arm64_address_translate_s1e1r(far);
                else
                        par = arm64_address_translate_s1e0r(far);
 
                /*
                 * If the translation was successful the address was invalid
                 * due to a break-before-make sequence. We can unlock and
                 * return success to the trap handler.
                 */
                if (PAR_SUCCESS(par)) {
                        PMAP_UNLOCK(pmap);
                        return (KERN_SUCCESS);
                }
                break;
        default:
                break;
        }
        PMAP_UNLOCK(pmap);
#endif
 
        return (KERN_FAILURE);
}


===
Mark Millard
markmi at dsl-only.net



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"