Solved Page fault during 15.1 update

balanga said:
have just done a reboot after running
Click to expand...
That didn't change anything. I suspect you did freebsd-update install, then rebooted.

Boot to single user mode, disable kld_list in rc.conf. Reboot and continue with the upgrade.

Your DRM driver is the one that's crashing the system, it was built for 15.0 and now gets loaded on a 15.1 kernel.
 
hm, I am having this on my 15.0 for quite some time, however, have always procrastinated research and root cause analysis.
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0xbe2e3f50
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xbdbc3907
stack pointer = 0x28:0xfffffe0148b23c50
frame pointer = 0x28:0x1
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (thread taskq)
rdi: fffffe0148b23d18 rsi: fffff801029b9cd0 rdx: 0000000000000000
rcx: 00000000bdbc5158 r8: 00000000bdbc53d8 r9: 0000000000000005
rax: 00000000be2e3e10 rbx: fffffe0148b23de8 rbp: 0000000000000001
r10: 0000000000000000 r11: 000000000000000b r12: fffff800015a6358
r13: 0000000000000000 r14: fffffe0148b23e20 r15: fffffe0148b23dc0
trap number = 12
EFI RT page fault
Click to expand...
 
SirDice said:
That didn't change anything. I suspect you did freebsd-update install, then rebooted.

Boot to single user mode, disable kld_list in rc.conf. Reboot and continue with the upgrade.

Your DRM driver is the one that's crashing the system, it was built for 15.0 and now gets loaded on a 15.1 kernel.
Click to expand...
Thanks for the explanation.

Everything is fixed now.
 
And updating loader.efi on ESP should be needed on major base upgrades if you're booting via UEFI.

This is because loader including loader.efi could get some fixes or functional updates (i.e., passing newly available information via kenv that updated kernel additionally wants).
And more, specific with upgrading to 15.1 (and at some point for 15.0-p*) gets important fix to allow latest CPU microcodes to be updated on boot.

Note that legacy BIOS boots doesn't need to be upgraded manually, as prior steps (bootcodes) does NOTHING loader does.

MBR or PMBR looks for partition boot codes at the top of partitions or boot codes in freebsd-boot partiton respectively and load it, then, pass control to what's loaded.

Partition boot codes (in case MBR partition schemes) looks for /boot/{zfs}loader with regard to the partition type, loads it, and pass control to it.

Boot code in freebsd-boot partition looks for /boot/{zfs}loader (in case GPT partition schemes) with regard to the partition type, loads it, and pass control to it.

Yes partition boot codes and/or boot codes in freebsd-boot partition need to know about the structure of the target filesystem (basically UFS or ZFS) and how to look for /boot/{zfs}loader there. So updating these are basically needed on major upgrades.
 
fernandel said:
I agre with both of drhowarddrfine and T-Aoki but are packages built for 15.1? Possible kmods...
Click to expand...
Basically, API/ABI keeps backward compatibilities throuout single major version, so official pkgs on main repo are built against oldest supported minor releases (in case 15.x, currently 15.0).

The exceptions are kmods.

Many of kmod ports would be fine for pkgs built against 15.0 even on 15.1, but some wouldn't. This is the reason kmod repo is provided for each supported minor releases.

The most significant example would be anything requiring LinuxKPI to run.
These are quite keen on even single commits to LinuxKPI. And this is why I strongly recommend to build graphics/{nvidia-}drm-*-kmod* ports locally using 100% matching src tree for running kernel, in commit level.
 
You must log in or register to reply here.
Back
Top