[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.