Whenever fwupd starts (during system boot or via "service fwupd start"), my system immediately panics with "Unknown caching mode" error: Unread portion of the kernel message buffer: [85459] panic: Unknown caching mode -518004449 [85459] [85459] cpuid = 3 [85459] time = 1782567400 [85459] KDB: stack backtrace: [85459] #0 0xffffffff8073ffb3 at kdb_backtrace+0x63 [85459] #1 0xffffffff806fad84 at vpanic+0x134 [85459] #2 0xffffffff806fac43 at panic+0x43 [85459] #3 0xffffffff809c1e9d at pmap_qenter+0x12d [85459] #4 0xffffffff809c8d9e at pmap_map_io_transient+0xce [85459] #5 0xffffffff809dacc2 at uiomove_fromphys+0xf2 [85459] #6 0xffffffff8075a33f at physcopyout+0xbf [85459] #7 0xffffffff839a6207 at copy_table+0x127 [85459] #8 0xffffffff839a8092 at efidev_ioctl+0x222 [85459] #9 0xffffffff80602f2b at devfs_ioctl+0xbb [85459] #10 0xffffffff807e114d at vn_ioctl+0xbd [85459] #11 0xffffffff80603564 at devfs_ioctl_f+0x24 [85459] #12 0xffffffff807614b7 at kern_ioctl+0x267 [85459] #13 0xffffffff807611e7 at sys_ioctl+0x117 [85459] #14 0xffffffff809d9fa9 at amd64_syscall+0x129 [85459] #15 0xffffffff809b310b at fast_syscall_common+0xf8 [85459] Uptime: 23h44m19s [38] Dumping 2059 out of 65323 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/modules/i915kms.ko... (No debugging symbols found in /boot/modules/i915kms.ko) Reading symbols from /boot/modules/drm.ko... (No debugging symbols found in /boot/modules/drm.ko) Reading symbols from /boot/kernel/iicbus.ko... Reading symbols from /usr/lib/debug//boot/kernel/iicbus.ko.debug... <CUT> Reading symbols from /usr/lib/debug//boot/kernel/nlsysevent.ko.debug... __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 57 __asm("movq %%gs:%c1,%0" : "=r" (td) (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 #1 doadump (textdump=<optimized out>) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff806fa8d7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:519 #3 0xffffffff806fae15 in vpanic (fmt=0xffffffff80afcce9 "Unknown caching mode %d\n", ap=ap@entry=0xfffffe0182cd89e0) at /usr/src/sys/kern/kern_shutdown.c:974 #4 0xffffffff806fac43 in panic (fmt=<unavailable>) at /usr/src/sys/kern/kern_shutdown.c:887 #5 0xffffffff809c1e9d in pmap_cache_bits (mode=<unavailable>, is_pde=false, pmap=<optimized out>) at /usr/src/sys/amd64/amd64/pmap.c:2758 #6 pmap_qenter (sva=<optimized out>, ma=<optimized out>, ma@entry=0xfffffe0182cd8ae0, count=<unavailable>, count@entry=1) at /usr/src/sys/amd64/amd64/pmap.c:3953 #7 0xffffffff809c8d9e in pmap_map_io_transient (page=0xfffffe0182cd8ae0, page@entry=<unavailable>, vaddr=vaddr@entry=0xfffffe0182cd8a88, count=count@entry=1, can_fault=true) at /usr/src/sys/amd64/amd64/pmap.c:10545 #8 0xffffffff809dacc2 in uiomove_fromphys (ma=ma@entry=0xfffffe0182cd8ae0, offset=offset@entry=24, n=16, uio=uio@entry=0xfffffe0182cd8af0) at /usr/src/sys/amd64/amd64/uio_machdep.c:93 #9 0xffffffff8075a33f in physcopyout (src=<optimized out>, dst=<optimized out>, len=len@entry=16) at /usr/src/sys/kern/subr_uio.c:132 #10 0xffffffff839a6207 in get_table_length (type=<optimized out>, table_len=0xfffffe0182cd8d68, taddr=<optimized out>) at /usr/src/sys/dev/efidev/efirt.c:388 #11 copy_table (guid=0xfffffe0182cd8d58, buf=0x0, buf_len=<optimized out>, table_len=0xfffffe0182cd8d68) at /usr/src/sys/dev/efidev/efirt.c:512 #12 0xffffffff839a8092 in efi_copy_table (guid=<unavailable>, buf=<unavailable>, buf_len=<unavailable>, table_len=<unavailable>) at /usr/src/sys/sys/efi.h:318 #13 efidev_ioctl (dev=<optimized out>, cmd=<optimized out>, addr=0xfffffe0182cd8d50 "", flags=<optimized out>, td=<optimized out>) at /usr/src/sys/dev/efidev/efidev.c:59 #14 0xffffffff80602f2b in devfs_ioctl (ap=0xfffffe0182cd8c58) at /usr/src/sys/fs/devfs/devfs_vnops.c:964 #15 0xffffffff807e114d in VOP_IOCTL (vp=<optimized out>, command=<optimized out>, data=<optimized out>, fflag=<optimized out>, cred=<optimized out>, td=<optimized out>) at ./vnode_if.h:633 #16 0xffffffff807e114d in vn_ioctl (fp=<optimized out>, com=<unavailable>, data=<unavailable>, active_cred=<unavailable>, td=<unavailable>) #17 0xffffffff80603564 in devfs_ioctl_f (fp=<unavailable>, com=<unavailable>, data=<unavailable>, cred=<unavailable>, td=<unavailable>) at /usr/src/sys/fs/devfs/devfs_vnops.c:895 #18 0xffffffff807614b7 in fo_ioctl (fp=0xfffff80184917000, com=3223864577, data=0xfffffe0182cd8d50, active_cred=<unavailable>, td=0xfffff8061f751000) at /usr/src/sys/sys/file.h:388 #19 kern_ioctl (td=td@entry=0xfffff8061f751000, fd=<optimized out>, com=com@entry=3223864577, data=data@entry=0xfffffe0182cd8d50 "") at /usr/src/sys/kern/sys_generic.c:811 #20 0xffffffff807611e7 in sys_ioctl (td=<optimized out>, uap=<optimized out>) at /usr/src/sys/kern/sys_generic.c:716 #21 0xffffffff809d9fa9 in syscallenter (td=0xfffff8061f751000) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:193 #22 amd64_syscall (td=0xfffff8061f751000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1267 #23 <signal handler called> #24 0x0000000831bca4ea in ?? () Backtrace stopped: Cannot access memory at address 0x8209ceaa8 "-518004449" value appears to be the same. fwupd built in local poudriere, in a releng/15.1 jail (so same commit as the host which it's installed onto): $ pkg info fwupd fwupd-2.1.5 Name : fwupd Version : 2.1.5 Installed on : Fri Jun 19 13:34:41 2026 EEST Origin : sysutils/fwupd Architecture : FreeBSD:15:amd64 Prefix : /usr/local Categories : sysutils Licenses : LGPL21 Maintainer : decke@FreeBSD.org WWW : https://github.com/fwupd/fwupd/ Comment : Update firmware automatically, safely, and reliably Options : DOCS : off TEST : off Shared Libs required: libblkid.so.1 libc.so.7 libcurl.so.4 libdrm.so.2 libdrm_amdgpu.so.1 libefivar.so.1 libgio-2.0.so.0 libglib-2.0.so.0 libgmodule-2.0.so.0 libgnutls.so.30 libgobject-2.0.so.0 libintl.so.8 liblzma.so.5 libreadline.so.8 libsqlite3.so.0 libthr.so.3 libusb.so.3 libxmlb.so.2 libz.so.6 Shared Libs provided: libfwupd.so.3 Annotations : FreeBSD_version: 1501000 build_timestamp: 2026-06-19T09:22:20+0000 built_by : poudriere-git-3.4.8 repo_type : binary repository : poudriere Flat size : 16.1MiB Description : Make firmware updates automatic, safe, and reliable. fwupd is a simple daemon to allow session software to update device firmware on your local machine. It is designed for desktops, but also usable on phones and headless servers. You can either use a GUI software manager like GNOME Software to view and apply updates, the command-line tool, or the system D-Bus interface directly. At the same time, efibootmgr/efivar from base system work as expected, so efirt kernel module and /dev/efi appear to work. The host has been upgraded from 14.4-R to 15.1-R, then I discovered that pkg didn't offer to remove devel/efivar automatically (which was a dependency for fwupd), so I did that manually, and I guess crashes started after that. Not sure if host/poudriere {src,make}.conf/kernel config/build log/whatever are relevant, thus not attaching at the moment, but available upon request.
(In reply to Anton Saietskii from comment #0) > devel/efivar automatically (which was a dependency for fwupd) Clarification: which was a dependency, but now is not, and I have fwupd installed since efivar was a declared dependency.
Plesse try to remove efivar and see if it helps.
(In reply to Bernhard Froehlich from comment #2) Perhaps I wasn't clear enough in comment #0, but it _started_ after removing devel/efivar, despite the fact fwupd was built in poudriere jail, which is a clean environment and that didn't have efivar at build time.
This is definitely a problem within efirt so on kernel side and we need some help with that.
(In reply to Bernhard Froehlich from comment #4) I was thinking of that, but it's unclear for me who to blame. Seems like fwupd does something nasty which built-in tools like efivar don't, but on the other hand userland programs shouldn't crash kernel I'd say... For now, I'll need to check 15.1R-p1—there are unrelated changes, but I was cleaning old core dumps (thus, p0 gone). Also, I may still have 14.4 BE, so I'll check if it still has efivar from ports installed, then try to remove it too and see what happens.
Thanks for the CC At first glance this doesn't seem to be an issue with efirt, looks like it sanitizes the table table info fine before calling physcopyout. Anton, can you provide the output of efitable -t esrt please?
Created attachment 272865 [details] full backtrace, 15.1R-p1 (In reply to Ahmad Khalifa from comment #6) Apparently, I can not--got same crash with same value immediately (attaching full backtrace). So it seems like fwupd is not guilty, but rather something in my firmware is wrong? This is Dell Precision 7720 laptop with latest fw installed (1.40), but it's dated 2025, which may mean servicing updates are ended.
Created attachment 272868 [details] full backtrace, 14.4R-p7 14.4R-p7 crashes same way, but value of "caching mode" is different--"-254569525". It is also the same across panic occurrences.
(In reply to Anton Saietskii from comment #7) I'm not sure I'd blame the firmware for this. I was thinking maybe we were passing an abnormally long length to physcopyout, but the call seems fairly innocent. This may be a bug in the VM subsystem, I'll CC some people who know more about it than I do.
From the frame 7, print out the *page[0]
(In reply to Anton Saietskii from comment #0) It'd be useful to see output from `p/x *page` in frame 7. It'd also be good to see the table's physical address (i.e., "src" in the physcopyout() frame, though that's optimized out) and the memory map (sysctl machdep.efi_map, sysctl vm.phys_segs). In particular I wonder if that table is covered by the physical memory map.
(In reply to Mark Johnston from comment #11) physcopyout is called with these three local variables in get_table_length: esrt = 0x7927e018 len = 16 buf = 0xfffff80c97fe79c0
(In reply to Mark Johnston from comment #11) (kgdb) f 7 #7 0xffffffff809c9abe in pmap_map_io_transient (page=0xfffffe0182d8cae0, page@entry=<unavailable>, vaddr=vaddr@entry=0xfffffe0182d8ca88, count=count@entry=1, can_fault=true) at /usr/src/sys/amd64/amd64/pmap.c:10545 warning: Source file is more recent than executable. 10545 pmap_qenter(vaddr[i], &page[i], 1); (kgdb) p/x *page $1 = 0xfffffe00029a55d0 (kgdb) > though that's optimized out I have 'COPTFLAGS=-O2 -pipe' configured. Would you think it will help to change optimization level to something else to get values?
Created attachment 272869 [details] sysctl machdep.efi_map vm.phys_segs
(In reply to Anton Saietskii from comment #13) Try `p/x *pages[0]` as kib suggested.
(In reply to Mark Johnston from comment #15) I guess 'page[0]' without 's'? Otherwise it says no such symbol. (kgdb) p/x *page[0] $1 = {plinks = {q = {tqe_next = 0x83edd17974503e02, tqe_prev = 0x836dd1f974d03e82}, s = {ss = {sle_next = 0x83edd17974503e02}}, memguard = {p = 0x83edd17974503e02, v = 0x836dd1f974d03e82}, uma = {slab = 0x83edd17974503e02, zone = 0x836dd1f974d03e82}}, object = 0x836dd1f974d03e82, pindex = 0x936dc1f964d02e82, phys_addr = 0x137d41e9e4c0ae92, md = {pv_list = {tqh_first = 0x133d41a9e480aed2, tqh_last = 0xc11bc11bc11bc11b}, pv_gen = 0xe11fe11f, pat_mode = 0xe11fe11f}, ref_count = 0xe117e117, busy_lock = 0xe117e117, a = {{ flags = 0xe017, queue = 0x17, act_count = 0xe0}, _bits = 0xe017e017}, order = 0x17, pool = 0xe0, flags = 0x17, oflags = 0xe0, psind = 0x17, segind = 0xe0, valid = 0x17, dirty = 0xe0} (kgdb)
(In reply to Anton Saietskii from comment #16) As expected, the page is garbage. I think we need to initialize all elements in the vm_page_array[] with some sane values. At very minimum, we should initialize all elements that are covered by the EFI map before ExitBootServices().
(In reply to Ahmad Khalifa from comment #12) Thanks, I missed that. So this is covered by the following entry in the EFI map: RuntimeServicesData 000078e1f000 000078e1f000 000006ff UC WC WT WB RUNTIME (In reply to Konstantin Belousov from comment #17) Isn't it enough to register a fictitious range for each EFI RT data segment in the EFI map? We do not want to add those ranges to the physmap, I believe.
(In reply to Mark Johnston from comment #18) Not to add them to physmap of course. Yes, vm_phys_fictitious_reg_range() should be enough, I forgot that it reuses vm_page_array[] if it covers the range. But I should correct myself, the registration should be done only for the Runtime memory.
Try https://reviews.freebsd.org/D58274
(In reply to Konstantin Belousov from comment #20) I can confirm that with patch applied, my system doesn't crash anymore: $ sudo efitable -t esrt FwResourceCount: 1 FwResourceCountMax: 1 FwResourceVersion: 1 Entries: FwClass: fe771285-6926-4d47-a0bc-0f6e2a71e3ad FwType: 1 FwVersion: 75776 LowestSupportedFwVersion: 75776 CapsuleFlags: 0x20000 LastAttemptVersion: 0 LastAttemptStatus: 0 sysutils/fwupd also starts fine.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a2f50c4b32d1c126cf2309dab61d27d6329908f8 commit a2f50c4b32d1c126cf2309dab61d27d6329908f8 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2026-07-16 06:49:21 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2026-07-16 15:32:50 +0000 amd64 efirt: register all runtime regions as fictitious This is needed for VM_PHYS_TO_PAGE() to work, which is needed for pmap_map_io_transient() to work, which is needed for uiomove_fromphys() to work. PR: 296348 Reported and tested by: Anton Saietskii <vsasjason@gmail.com> Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D58274 sys/amd64/amd64/efirt_machdep.c | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=842e271b7b8bf8a3bb039db57dce2107600ab883 commit 842e271b7b8bf8a3bb039db57dce2107600ab883 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2026-07-16 06:49:21 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2026-07-20 20:24:27 +0000 amd64 efirt: register all runtime regions as fictitious PR: 296348 (cherry picked from commit a2f50c4b32d1c126cf2309dab61d27d6329908f8) sys/amd64/amd64/efirt_machdep.c | 3 +++ 1 file changed, 3 insertions(+)
(In reply to commit-hook from comment #22) This commit makes my kernel panic on load. panic: Invalid range passed on search for vm_fictitious page cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper() vpanic() vm_phys_fictitious_to_vm_page() efi_create_1t1_map() efirt_modevents() module_register_init() mi_startup() KDB: enter: panic (typed from screen by hand, exact addresses omitted, happy to supply them if needed)
(In reply to David Israelsson from comment #24) Show me the output from sysctl machdep.efi_map
I suspect that the following would be good enough commit 3f3508cccb65b0f57e4d28d1af857484428f48c7 Author: Konstantin Belousov <kib@FreeBSD.org> Date: Mon Aug 10 21:09:11 2026 +0300 vm/vm_phys.c: allow PHYS_TO_VM_PAGE(0) for registered fictitious page @0 PR: 296348 diff --git a/sys/vm/vm_phys.c b/sys/vm/vm_phys.c index 975754264fee..509d71b69854 100644 --- a/sys/vm/vm_phys.c +++ b/sys/vm/vm_phys.c @@ -212,9 +212,6 @@ static inline int vm_phys_fictitious_in_range(struct vm_phys_fictitious_seg *p, struct vm_phys_fictitious_seg *range) { - - KASSERT(range->start != 0 && range->end != 0, - ("Invalid range passed on search for vm_fictitious page")); if (p->start >= range->end) return (1); if (p->start < range->start)
(In reply to Konstantin Belousov from comment #25) Type Physical Virtual #Pages Attr RuntimeServicesData 000000000000 000000000000 00000001 UC WC WT WB RUNTIME ConventionalMemory 000000001000 000000000000 0000008f UC WC WT WB RuntimeServicesCode 000000090000 000000090000 00000001 UC WC WT WB RUNTIME ConventionalMemory 000000091000 000000000000 0000000e UC WC WT WB BootServicesData 00000009f000 000000000000 00000001 UC WC WT WB ConventionalMemory 000000100000 000000000000 00000f00 UC WC WT WB BootServicesData 000001000000 000000000000 00000080 UC WC WT WB ConventionalMemory 000001080000 000000000000 00008d7f UC WC WT WB Reserved 000009dff000 000000000000 00000201 UC WC WT WB ConventionalMemory 00000a000000 000000000000 00000200 UC WC WT WB ACPIMemoryNVS 00000a200000 000000000000 00000010 UC WC WT WB ConventionalMemory 00000a210000 000000000000 00000df0 UC WC WT WB Reserved 00000b000000 000000000000 00000020 UC WC WT WB ConventionalMemory 00000b020000 000000000000 000acb7e UC WC WT WB LoaderData 0000b7b9e000 000000000000 0000000c UC WC WT WB LoaderCode 0000b7baa000 000000000000 00004000 UC WC WT WB LoaderData 0000bbbaa000 000000000000 00004300 UC WC WT WB LoaderCode 0000bfeaa000 000000000000 000000a8 UC WC WT WB BootServicesCode 0000bff52000 000000000000 0000011d UC WC WT WB LoaderData 0000c006f000 000000000000 00000001 UC WC WT WB BootServicesCode 0000c0070000 000000000000 00000983 UC WC WT WB ConventionalMemory 0000c09f3000 000000000000 00003967 UC WC WT WB BootServicesData 0000c435a000 000000000000 00000085 UC WC WT WB ConventionalMemory 0000c43df000 000000000000 00000002 UC WC WT WB BootServicesData 0000c43e1000 000000000000 00000030 UC WC WT WB ConventionalMemory 0000c4411000 000000000000 00000001 UC WC WT WB BootServicesData 0000c4412000 000000000000 00000273 UC WC WT WB ConventionalMemory 0000c4685000 000000000000 00000003 UC WC WT WB BootServicesData 0000c4688000 000000000000 00000e38 UC WC WT WB ConventionalMemory 0000c54c0000 000000000000 00000001 UC WC WT WB BootServicesData 0000c54c1000 000000000000 0000001e UC WC WT WB ConventionalMemory 0000c54df000 000000000000 00000002 UC WC WT WB BootServicesData 0000c54e1000 000000000000 000000b8 UC WC WT WB Reserved 0000c5599000 000000000000 00000001 UC WC WT WB BootServicesData 0000c559a000 000000000000 00001b97 UC WC WT WB ConventionalMemory 0000c7131000 000000000000 00000001 UC WC WT WB BootServicesData 0000c7132000 000000000000 000018c1 UC WC WT WB Reserved 0000c89f3000 000000000000 0000035e UC WC WT WB ACPIReclaimMemory 0000c8d51000 000000000000 00000325 UC WC WT WB ACPIMemoryNVS 0000c9076000 000000000000 000016fa UC WC WT WB RuntimeServicesData 0000ca770000 0000ca770000 000013fd UC WC WT WB RUNTIME RuntimeServicesCode 0000cbb6d000 0000cbb6d000 00000092 UC WC WT WB RUNTIME BootServicesData 0000cbbff000 000000000000 00000401 UC WC WT WB ConventionalMemory 0000cc000000 000000000000 00000104 UC WC WT WB BootServicesData 0000cc104000 000000000000 00000100 UC WC WT WB BootServicesCode 0000cc204000 000000000000 0000003b UC WC WT WB BootServicesData 0000cc23f000 000000000000 0000004b UC WC WT WB BootServicesCode 0000cc28a000 000000000000 0000001b UC WC WT WB BootServicesData 0000cc2a5000 000000000000 0000001a UC WC WT WB BootServicesCode 0000cc2bf000 000000000000 0000000a UC WC WT WB BootServicesData 0000cc2c9000 000000000000 00000cb1 UC WC WT WB BootServicesCode 0000ccf7a000 000000000000 00000003 UC WC WT WB BootServicesData 0000ccf7d000 000000000000 00000013 UC WC WT WB BootServicesCode 0000ccf90000 000000000000 00000002 UC WC WT WB BootServicesData 0000ccf92000 000000000000 00000011 UC WC WT WB BootServicesCode 0000ccfa3000 000000000000 00000003 UC WC WT WB BootServicesData 0000ccfa6000 000000000000 00000013 UC WC WT WB BootServicesCode 0000ccfb9000 000000000000 00000003 UC WC WT WB BootServicesData 0000ccfbc000 000000000000 00000013 UC WC WT WB BootServicesCode 0000ccfcf000 000000000000 00000004 UC WC WT WB BootServicesData 0000ccfd3000 000000000000 00000014 UC WC WT WB BootServicesCode 0000ccfe7000 000000000000 0000000b UC WC WT WB BootServicesData 0000ccff2000 000000000000 00000008 UC WC WT WB BootServicesCode 0000ccffa000 000000000000 00000006 UC WC WT WB ConventionalMemory 000100000000 000000000000 00b2f380 UC WC WT WB Reserved 0000000a0000 000000000000 00000060 UC WC WT WB Reserved 0000cd000000 000000000000 00003000 UC WC WT WB MemoryMappedIO 0000f0000000 0000f0000000 00008000 UC WT WB WP RUNTIME MemoryMappedIO 0000fd200000 0000fd200000 00000100 UC RUNTIME MemoryMappedIO 0000fd600000 0000fd600000 00000200 UC RUNTIME MemoryMappedIO 0000fea00000 0000fea00000 00000010 UC RUNTIME MemoryMappedIO 0000feb80000 0000feb80000 00000082 UC RUNTIME MemoryMappedIO 0000fec10000 0000fec10000 00000001 UC RUNTIME MemoryMappedIO 0000fec30000 0000fec30000 00000001 UC RUNTIME MemoryMappedIO 0000fed00000 0000fed00000 00000001 UC RUNTIME MemoryMappedIO 0000fed40000 0000fed40000 00000005 UC RUNTIME MemoryMappedIO 0000fed80000 0000fed80000 00000010 UC RUNTIME MemoryMappedIO 0000fedc2000 0000fedc2000 0000000e UC RUNTIME MemoryMappedIO 0000fedd4000 0000fedd4000 00000002 UC RUNTIME MemoryMappedIO 0000ff000000 0000ff000000 00001000 UC RUNTIME Reserved 000c2f380000 000000000000 00000c80 UC WC WT WB
(In reply to David Israelsson from comment #27) > Type Physical Virtual #Pages Attr > RuntimeServicesData 000000000000 000000000000 00000001 UC WC WT WB RUNTIME As expected, your machine has the runtime data at physical address zero. I do expect that the patch I posted would help, and curious about any other consequences of it.
(In reply to Konstantin Belousov from comment #26) Confirmed to be working. Applied the patch to HEAD of main, and the kernel boots without panicing now.
https://reviews.freebsd.org/D58785
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=6a8558cf9f0190cb166042f97d2c883d822e66b2 commit 6a8558cf9f0190cb166042f97d2c883d822e66b2 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2026-08-10 18:09:11 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2026-08-11 13:26:35 +0000 vm/vm_phys.c: allow PHYS_TO_VM_PAGE(0) for registered fictitious page @0 PR: 296348 Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D58785 sys/vm/vm_phys.c | 3 --- 1 file changed, 3 deletions(-)
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=70f48109503b0e17ff7e2e2a493af8b8d0397f01 commit 70f48109503b0e17ff7e2e2a493af8b8d0397f01 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2026-08-10 18:09:11 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2026-08-13 00:34:41 +0000 vm/vm_phys.c: allow PHYS_TO_VM_PAGE(0) for registered fictitious page @0 PR: 296348 (cherry picked from commit 6a8558cf9f0190cb166042f97d2c883d822e66b2) sys/vm/vm_phys.c | 3 --- 1 file changed, 3 deletions(-)