[Bug 274278] "debug.late_console=0" option causes kernel panic
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 274278] "debug.late_console=0" option causes kernel panic"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 274278] "debug.late_console=0" option causes kernel panic"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 274278] "debug.late_console=0" option causes kernel panic"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 274278] "debug.late_console=0" option causes kernel panic"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 274278] "debug.late_console=0" option causes kernel panic"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 05 Oct 2023 10:27:39 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274278
Bug ID: 274278
Summary: "debug.late_console=0" option causes kernel panic
Product: Base System
Version: 13.2-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: bugs@FreeBSD.org
Reporter: oliver.giersch@b-tu.de
Setting "debug.late_console=0" in loader.conf leads to machdep.c:hammer_time to
initialize console device(s) before `getmemsize` is called.
This causes a kernel panic: "pmap_mapdev_internal:too many preinit mappings",
with the following callstack (examined through QEMU+GDB):
pmap_mapdev_internal@0xffffffff808cf591
(/usr/local/src/freebsd/sys/amd64/amd64/pmap.c:9094)
pmap_mapdev_attr@0xffffffff808cf518
(/usr/local/src/freebsd/sys/amd64/amd64/pmap.c:9150)
vt_efifb_init@0xffffffff803cc9f2
(/usr/local/src/freebsd/sys/dev/vt/hw/efifb/efifb.c:143)
vtterm_cnprobe@0xffffffff803d0852
(/usr/local/src/freebsd/sys/dev/vt/vt_core.c:1677)
termcn_cnprobe@0xffffffff805555df
(/usr/local/src/freebsd/sys/kern/subr_terminal.c:579)
cninit@0xffffffff80435f79 (/usr/local/src/freebsd/sys/kern/kern_cons.c:166)
hammer_time@0xffffffff808b349e
(/usr/local/src/freebsd/sys/amd64/amd64/machdep.c:1532)
btext@0xffffffff8029ffc0 (/usr/local/src/freebsd/sys/amd64/amd64/locore.S:78)
From a quick look at the code, the cause of the panic seems to stem from this:
`pmap_mapdev_internal` expects `virtual_avail` (defined in amd64/pmap.c) to be
initialized to a non-zero value, but `virtual_avail` is only initialized in
`pmap_bootstrap`, which is called during execution of `getmemsize`, i.e., after
the attempted early console init.
--
You are receiving this mail because:
You are the assignee for the bug.