Re: git: bcd763b642ab - main - Move the arm64 DMAP creation to C

Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Sat, 09 Apr 2022 08:12:49 UTC
From: Kyle Evans <kevans_at_freebsd.org> 
Date: Sat, 9 Apr 2022 00:31:09 -0500 :
> On Wed, Apr 6, 2022 at 8:24 AM Andrew Turner <andrew_at_freebsd.org> wrote:
> >
> > The branch main has been updated by andrew:
> >
> > URL: https://cgit.FreeBSD.org/src/commit/?id=bcd763b642abb4b236902e84184c579225265fb7
> >
> > commit bcd763b642abb4b236902e84184c579225265fb7
> > Author:     Andrew Turner <andrew_at_FreeBSD.org>
> > AuthorDate: 2022-03-15 17:05:48 +0000
> > Commit:     Andrew Turner <andrew_at_FreeBSD.org>
> > CommitDate: 2022-04-06 13:09:49 +0000
> >
> >     Move the arm64 DMAP creation to C
> >
> >     To simplify the creation of the direct map (DMAP) region on arm64 move
> >     it from the pre-C code into pmap. This simplifies the DMAP creation
> >     as we can use the notmal index macros, and should reduce the number
> >     of pages needed to hold the level 1 tables to just those needed.
> >
> >     Reviewed by:    alc, dch
> >     Tested by:      dch, kevans
> >     Sponsored by:   The FreeBSD Foundation
> >     Differential Revision: https://reviews.freebsd.org/D34568
> 
> Our Ampere boxes were fine with this, but this seems to tickle
> something on this M1 mini that I have. Specifically, we end up dying
> while probing UEFI stuff, here:
> 
> 
> https://cgit.freebsd.org/src/tree/sys/dev/efidev/efirt.c#n183
> 
> 
> efi_systbl_phys == 0x9e0979f30, efi_systbl == 0xffffa001e0979f30
> Fatal data abort:
> ...
>   sp: ffff000000fb79b0
>   lr: ffff000000157ae0 (efirt_modevents + 94)
>  elr: ffff000000157ae8 (efirt_modevents + 9c)
> spsr:         604000c5
>  far: ffffa001e0979f30
>  esr:         96000007
> panic: vm_fault failed: ffff000000157ae8 error 1
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x174
> panic() at panic+0x44
> data_abort() at data_abort+0x2f0
> handle_el1h_sync() at handle_el1h_sync+0x10
> --- exception, esr 0x96000007
> efirt_modevents() at efirt_modevents+0x9c
> module_register_init() at module_register_init+0xc4
> mi_startup() at mi_startup+0x284
> virtdone() at virtdone+0x7c

https://lists.freebsd.org/archives/freebsd-arm/2022-April/001222.html

is a RPi4B report by Bob Prohaska that has efirt_modevents getting a
data_abort as well:

Fatal data abort:
  x0: ffffa0003b25dad0
  x1:                8
  x2: ffff00000088db8d (do_execve.fexecv_proc_title + 7674)
  x3:              78a
  x4:                0
  x5:               69
  x6:         40a7152f
  x7:         f2db3c10
  x8: ffffa0003b25dad0
  x9:        200000000
 x10: ffffa00000000000
 x11:         3b25dad0
 x12: 725f696665006966
 x13:  100000102ff0001
 x14: ffff000000b07300 (lock_class_mtx_sleep + 0)
 x15:                0
 x16:                8
 x17:         f4b3707d
 x18: ffff000000fa79b0 (initstack + 39b0)
 x19: ffffa000008db380
 x20: ffff000000ab4810 (efirt_moddata + 0)
 x21: ffff000000911163 (console_pausestr + 13a59)
 x22: ffff000000c6d000 (db_watch_table + b88)
 x23: ffff000000ba1000 (compiler_version + 20)
 x24: ffff000000dfb000 (gdb_tx_u + aa0)
 x25:                0
 x26: ffff0000008a1723 (do_execve.fexecv_proc_title + 1b20a)
 x27:          3100000
 x28: ffff000000dfb000 (gdb_tx_u + aa0)
 x29: ffff000000fa79c0 (initstack + 39c0)
  sp: ffff000000fa79b0
  lr: ffff000000157ac4 (efirt_modevents + 78)
 elr: ffff000000157ad0 (efirt_modevents + 84)
spsr:         200000c5
 far: ffffa0003b25dad0
 esr:         96000007
panic: vm_fault failed: ffff000000157ad0 error 1
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
vpanic() at vpanic+0x174
panic() at panic+0x44
data_abort() at data_abort+0x2f0
handle_el1h_sync() at handle_el1h_sync+0x10
--- exception, esr 0x96000007
efirt_modevents() at efirt_modevents+0x84
module_register_init() at module_register_init+0xc4
mi_startup() at mi_startup+0x130
virtdone() at virtdone+0x7c
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x44: undefined       f902011f

===
Mark Millard
marklmi at yahoo.com