I'd comment outfuse_load andkld_list and see if it helps.
Since there is no more hal, you can remove hald_enable anyhow.
Edit: It most probably is the graphics driver, so the kld_list line should do it.
It's always been commented out.Just to be sure:
is still commented out in loader.conf?Code:i915kms_load="YES"
I'm a little unsure how to answer this. Uname -a gives out 13.1-RELEASE-p3 after I chroot using single user mode and do:Hi again
What version of FreeBSD are you using ?? And what graphics (or in this case cpu) are you using ??
I would be sure you was using a supported FreeBSD version. If not that could be your problem. But you are on latest releaseIt's always been commented out.
In the dmesg | less output after crash im still seeing something to do with : !drm_modeset_is_locked.... Error I can was referring to earlier.
I'm a little unsure how to answer this. Uname -a gives out 13.1-RELEASE-p3 after I chroot using single user mode and do:
zfs set readonly=off latest-zfs-snapshot-i-see-with-zfs-list
i somewhat remember it being upgraded to P4 release. I've tried upgrading from single user mode as well but seems to be showing 13.1-RELEASE-p3 ..... Will try again.
Regarding graphics it's an Intel cpu with no graphics card I think. It's been working flawlessly for a couple of years except the minor hiccups.
Also BE is set to latest snapshot that was taken when trying to perform upgrade in single user mode. Maybe I should set that back? But wont that affect new data not being shown/recovered?
This is definitely not something exotic. Always upgraded through standard freebsd update fetch/installI would be sure you was using a supported FreeBSD version. If not that could be your problem. But you are on latest release
As far I know if your old snapshot is booting your data is still there and should be able to find. But as I am on UFS I will not acclaim myself ZFS guru.
Rebooted when it was compiling? If so again, this could be a faulty RAM. Creating memtest usb takes few minutes and you can verify that modules are ok.I tried to do make install clean and the system rebooted again! Instead of throwing any errors or warning.
Yes, it rebooted while compiling. I tried to compile some other game just to see if it was drm-510--kmod specific and same thing. Rebooted again! Seems like it could be RAM (which might make sense also because my Chrome instance was a memory hog). ThanksRebooted when it was compiling? If so again, this could be a faulty RAM. Creating memtest usb takes few minutes and you can verify that modules are ok.
Can you share what is the virtual address you had the page fault on ?
iung: iun_read_firmuare: ucode rev=0x89dd8401 ulang: link state changed to UP
c:619
WARNING !drm_modeset_is_locked (&crtc->mutex) failed at /urkdirs/usr/ports cs/drm-518-kmod/work/drm-kmod-drn_v5.10.113_8/drivers/gpu/drm/drm_atomic_ HARNING Idrm_modeset_is_locked(&crtc->mutex) failed at /urkdirs/usr/ports.
c:619
drm/drm_atomic_helper.c:669
kernel trap 12 with interrupts disabled
cs/drm-510-kmod/work/drm-kmod-drm_v5.10.113_8/drivers/gpu/drm/drm_atomic_h HARNING !drm_modeset_is_locked (&dev->mode_config.connection_mutex) failed a kdirs/usr/ports/graphics/drm-518-kmod/work/drm-kmod-drm_v5.18.113_8/drivers
Fatal trap 12: page fault while in kernel mode cpuid 8: apic id = 89 fault virtual address = 8x1d8858fdb85
kld_list="/boot/modules/i915kms.ko"
pkg update -f
pkg install -f gpu-firmware-kmod
I am running memtest86 v4.10 currentlyThe best way is to boot the memtest itself, OS independent. You can download it (free version is ok) from here.
That virtual address is bogus (expected with kernel panic), not sure if you made some mistakes during manual "copy-paste". But even 0x1d8858fdb85 would be a bogus one.
Will try this after the memtest86 cycle is complete. Will report back.Try to comment out the line
ThenCode:kld_list="/boot/modules/i915kms.ko"
Code:pkg update -f pkg install -f gpu-firmware-kmod
It's been running since a couple of hours now, 3 passes done - memtest86 .... No errors so far. Should I let it continue running? See image below.Ok, let it run through all the tests. I'm assuming you mean "1 pass of the test pass, not the entire testing". It does show the fancy all over the screen "PASS" text once it's done.
The virtual address is totally bogus, it doesn't show signs of small buffer overruns, etc. As you had GPF and now page fault we can assume it was jumping "all over". It would help to see if the issue is always on the same function, i.e. stack trace. Maybe you should find out how to decrease the sizeof the picture and post it that way.
It was mentioned here above, you should comment practically everything out from rc.conf to see if it boots up.
But .. you said you are having troubles compiling stuff. That usually is what I mentioned above - HW issue. That sudden reboot is a sign of triple fault.
I have a 12.x stick available - would that be fine? Right now just running memtest86 since 3-4 hrs now. Not sure how much longer I should let it run.Can you boot a fresh 13.1-RELEASE stick into multi user mode?
That would be an enlightening test.
I guess 12.x is a good first test.I have a 12.x stick available - would that be fine? Right now just running memtest86 since 3-4 hrs now. Not sure how much longer I should let it run.
Memory modules are OK, memtest does pass as shown in the picture.I have a 12.x stick available - would that be fine? Right now just running memtest86 since 3-4 hrs now
intel_bw_cal_min_cdclk+0x89
. You could open a PR (bug report) for this too.On FreeBSD 13/ZFS I think you'd be ok even with empty rc.conf (zfs_enable="YES" is not needed for boot to succeed I think). This way you can test the boot without the intel driver.Regarding rc.conf (after this memtest86 is done) - what about trying to put in the default rc.conf instead
I'll try with the current one 12.x iirc. Last time I tried it took me to the installation screen then I turned it off not sure if there was a multiuser option there - will check again.I guess 12.x is a good first test.
If it boots fine this indicates it might be a borked installation and not a hardware error.
If it boots fine I‘d create a 13.1 stick to double check.
Ok. I'll try backing up current rc.conf as rc.comf.backup and having an empty rc.comf (or even zfs enable option)On FreeBSD 13/ZFS I think you'd be ok even with empty rc.conf (zfs_enable="YES" is not needed for boot to succeed I think). This way you can test the boot without the intel driver