Bug 223906 - arm64 kassert failure on boot in efi_create_1t1_map
Summary: arm64 kassert failure on boot in efi_create_1t1_map
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Konstantin Belousov
URL: https://reviews.freebsd.org/D13273
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-27 14:26 UTC by Ed Maste
Modified: 2020-06-10 21:09 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Maste freebsd_committer freebsd_triage 2017-11-27 14:26:44 UTC
--- Kernel configuration ---
include GENERIC

ident   PACKET

nooptions       VIMAGE
options         ALT_BREAK_TO_DEBUGGER
options         DEBUG_LOCKS
options         DEBUG_VFS_LOCKS
options         DIAGNOSTIC
-------

Panic on boot, 2-socket 96-core ThunderX at packet.net:

FreeBSD/SMP: Multiprocessor System Detected: 96 CPUs
random: unblocking device.
MAP 500000 mode 2 pages 2048
MAP fffec000 mode 2 pages 20
MAP 10ffe7b9000 mode 2 pages 3071
MAP 10fff3b8000 mode 2 pages 3143
MAP 803000000000 mode 1 pages 4096
MAP 804000001000 mode 1 pages 8192
MAP 87e006001000 mode 1 pages 4096
MAP 87e024000000 mode 1 pages 4096
MAP 87e0d0001000 mode 1 pages 1
MAP 903000000000 mode 1 pages 4096
MAP 904000001000 mode 1 pages 8192
MAP 97e006001000 mode 1 pages 4096
panic: efi_1t1_l3: Already mapped: va 0x97e006400000 *pt 0x87e007000707
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
         pc = 0xffff0000005f2b08  lr = 0xffff000000087048
         sp = 0xffff000000010710  fp = 0xffff000000010920

db_trace_self_wrapper() at vpanic+0x184
         pc = 0xffff000000087048  lr = 0xffff000000316934
         sp = 0xffff000000010930  fp = 0xffff0000000109b0

vpanic() at kassert_panic+0x158
         pc = 0xffff000000316934  lr = 0xffff0000003167ac
         sp = 0xffff0000000109c0  fp = 0xffff000000010a80

kassert_panic() at efi_create_1t1_map+0x26c
         pc = 0xffff0000003167ac  lr = 0xffff0000005f44a0
         sp = 0xffff000000010a90  fp = 0xffff000000010b00

efi_create_1t1_map() at efirt_modevents+0x100
         pc = 0xffff0000005f44a0  lr = 0xffff0000000ca6e4
         sp = 0xffff000000010b10  fp = 0xffff000000010b20

efirt_modevents() at module_register_init+0xc8
         pc = 0xffff0000000ca6e4  lr = 0xffff0000002f6654
         sp = 0xffff000000010b30  fp = 0xffff000000010b60

module_register_init() at mi_startup+0xc8
         pc = 0xffff0000002f6654  lr = 0xffff0000002b4848
         sp = 0xffff000000010b70  fp = 0xffff000000010bb0

mi_startup() at virtdone+0x54
         pc = 0xffff0000002b4848  lr = 0xffff000000001084
         sp = 0xffff000000010bc0  fp = 0x0000000000000000

KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      0
Comment 1 commit-hook freebsd_committer freebsd_triage 2017-11-28 09:34:53 UTC
A commit references this bug:

Author: kib
Date: Tue Nov 28 09:34:43 UTC 2017
New revision: 326311
URL: https://svnweb.freebsd.org/changeset/base/326311

Log:
  Fix index calculation for the page table pages for efirt 1:1 map.

  Stop issuing pre-assigned number to enumerate all page table pages,
  the assignment is incorrect.  Instead automatically calculate the next
  unused index. This index in fact does not serve any purpose except to
  be unique to satisfy vm_page_grab() interface, we do not look up the
  page by the index later.

  Reported and tested by:	emaste
  Reviewed by:	andrew
  Sponsored by:	The FreeBSD Foundation
  MFC after:	2 weeks
  PR:	223906
  Differential revision:	https://reviews.freebsd.org/D13273

Changes:
  head/sys/amd64/amd64/efirt_machdep.c
  head/sys/arm64/arm64/efirt_machdep.c
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:43:28 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 3 Ed Maste freebsd_committer freebsd_triage 2020-06-10 21:09:53 UTC
Fixed years ago, no need for MFC any longer