Solved Latest update gives "Fatal trap 12: page fault while in kernel mode" when i915kms.ko is loaded

lgrant · Saturday at 2:50 AM

After the latest FreeBSD update (freebsd-version -kru gives: 14.1-RELEASE-p5, 14.1-RELEASE-p5, 14.1-RELEASE-p6), the system crashes when I do a kldload /boot/modules/i915kms.ko. The CPU is an Alder Lake, which was just getting supported when I started using it. I wonder if the code for its driver has lagged behind. Here is the dmesg:

Code:

drmn0: <drmn> on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
drmn0: [drm] Incompatible option enable_guc=-1 - undocumented flag
[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
[drm] Got stolen memory base 0x4b800000, size 0x4000000
lkpi_iic0: <LinuxKPI I2C> on drmn0
iicbus0: <Philips I2C bus> on lkpi_iic0
iic0: <I2C generic I/O> on iicbus0
lkpi_iic1: <LinuxKPI I2C> on drmn0
iicbus1: <Philips I2C bus> on lkpi_iic1
iic1: <I2C generic I/O> on iicbus1
lkpi_iic2: <LinuxKPI I2C> on drmn0
iicbus2: <Philips I2C bus> on lkpi_iic2
iic2: <I2C generic I/O> on iicbus2
lkpi_iic3: <LinuxKPI I2C> on drmn0
iicbus3: <Philips I2C bus> on lkpi_iic3
iic3: <I2C generic I/O> on iicbus3
lkpi_iic4: <LinuxKPI I2C> on drmn0
iicbus4: <Philips I2C bus> on lkpi_iic4
iic4: <I2C generic I/O> on iicbus4
lkpi_iic5: <LinuxKPI I2C> on drmn0
iicbus5: <Philips I2C bus> on lkpi_iic5
iic5: <I2C generic I/O> on iicbus5
lkpi_iic6: <LinuxKPI I2C> on drmn0
iicbus6: <Philips I2C bus> on lkpi_iic6
iic6: <I2C generic I/O> on iicbus6
lkpi_iic7: <LinuxKPI I2C> on drmn0
iicbus7: <Philips I2C bus> on lkpi_iic7
iic7: <I2C generic I/O> on iicbus7
lkpi_iic8: <LinuxKPI I2C> on drmn0
iicbus8: <Philips I2C bus> on lkpi_iic8
iic8: <I2C generic I/O> on iicbus8
drmn0: successfully loaded firmware image 'i915/adlp_dmc_ver2_10.bin'
drmn0: [drm] Finished loading DMC firmware i915/adlp_dmc_ver2_10.bin (v2.10)
drmn0: successfully loaded firmware image 'i915/adlp_guc_62.0.3.bin'
drmn0: successfully loaded firmware image 'i915/tgl_huc_7.9.3.bin'


Fatal trap 12: page fault while in kernel mode
cpuid = 7; apic id = 16
fault virtual address    = 0x458
fault code        = supervisor read data, page not present
instruction pointer    = 0x20:0xffffffff80b0f0c9
stack pointer            = 0x28:0xfffffe00ca3d7510
frame pointer            = 0x28:0xfffffe00ca3d7590
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        = 7570 (kldload)
rdi: fffffe00cc458da8 rsi: 0000000000000004 rdx: 0000000000000000
rcx: 0000000000000000  r8: 0000000000000000  r9: 0000000000000000
rax: 0000000000000000 rbx: fffffe00cc458d80 rbp: fffffe00ca3d7590
r10: fffff800021af400 r11: fffffe00131c5a40 r12: 0000000000000000
r13: fffff80007f1f000 r14: fffffe00ca3d7538 r15: fffffe00cc458da8
trap number        = 12
panic: page fault
cpuid = 7
time = 1731423074
KDB: stack backtrace:
#0 0xffffffff80b7fefd at kdb_backtrace+0x5d
#1 0xffffffff80b32bd1 at vpanic+0x131
#2 0xffffffff80b32a93 at panic+0x43
#3 0xffffffff8100091b at trap_fatal+0x40b
#4 0xffffffff81000966 at trap_pfault+0x46
#5 0xffffffff80fd6d48 at calltrap+0x8
#6 0xffffffff80db0a67 at xa_load+0x77
#7 0xffffffff83443669 at guc_lrc_desc_pin+0x49
#8 0xffffffff8344203d at intel_guc_submission_enable+0x7d
#9 0xffffffff83446c1f at __uc_init_hw+0x46f
#10 0xffffffff8341da91 at intel_gt_init_hw+0x481
#11 0xffffffff83420c7c at intel_gt_resume+0x5cc
#12 0xffffffff8341e343 at intel_gt_init+0x213
#13 0xffffffff83318732 at i915_gem_init+0x92
#14 0xffffffff83314cd6 at i915_driver_probe+0xd56
#15 0xffffffff83325db0 at i915_pci_probe+0x40
#16 0xffffffff80da4aa2 at linux_pci_attach_device+0x472
#17 0xffffffff80b6f5ac at device_attach+0x3ac
Uptime: 8s
Dumping 581 out of 7929 MB

Has anyone else run into this?

cy@ · Saturday at 5:51 AM

The kernel KBI has changed and your drm-kmod doesn't match it (use the same KBI).

KBI is kernel binary interface. Just as you compile a program using an API (application programming interface) to produce an ABI (application binary interface), one (developers) compile the kernel using the KPI (kernel programming interface) to produce binaries and those binaries communicate with each other functions calling other functions (subroutines). You also need to rebuild your drm-kmod using the latest kernel header files (KPI) so that the drm-kmod's KBI matches that of the kernel's.

If you're using binary packages, the package builders haven't been updated and rebuilt packages yet to catch up with the new kernel. You can work around this by building and installing your drm-kmod port yourself. I use graphics/drm-61-kmod here. You may be using a different version. Rebuild and reinstall that version.

The API and KPI are the C header files. They're akin to DSECTs in the IBM mainframe world. When a DSECT containing some control block (data structure) changed you need to reassemble all modules (CSECTs) that used that DSECT in order to use the new offsets. Similarly in the C world if a header file (.h) changed one needs to rebuild all sources (.c) to generate the same offsets within data structures. This is automatic with the base FreeBSD but ports and packages need to be rebuilt (by the ports package management team, if using binary packages, or by you, if using ports). You can hurry up the process by rebuilding/reinstalling the port yourself.

lgrant · Saturday at 6:42 AM

Thank you! I will try that in the morning.

Emrion · Saturday at 7:58 AM

The binary packages are built on 14.1-RELEASE since several weeks now. You don't need to compile kernel modules.
I don't see the connection with the update to p6 because these updates do not touch the kernel.

Check the drm version you have
pkg info drm-*-kmod

And then, show the output of:
pkg info your_drm_version| grep FreeBSD_version

lgrant · Saturday at 2:32 PM

The version id drm-515-,mod-5.15.160. The FreeBSD version is 1401000.

This issue seems to be that I really need drm-61-kmod. Switching to that fixed the problem.

But while I was looking into this, I ran into something confusing. I installed the ports tree when I installed the system. According to the FreeBSD handbook, before installing any ports, I should issue this command to update the ports tree:

git -C /usr/ports pull

when I do, I get this error message:

fatal: not a git repository (or any parent up to mount point /usr)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

And /usr/ports/graphics/ does not contain drm-61-kmod, so it is apparently out of date.

If I check out the ports tree, like this:

git clone --depth 1 https://git.FreeBSD.org/ports.git /usr/new-ports

drm-61-kmod is there. If I check out the quarterly ports tree, drm-61-kmod is also there.

How is the ports tree supposed to get updated if you install it with the system?

cy@ · Saturday at 2:36 PM

Emrion said:
The binary packages are built on 14.1-RELEASE since several weeks now. You don't need to compile kernel modules.
I don't see the connection with the update to p6 because these updates do not touch the kernel.

Sometimes they do.

Emrion said:
Check the drm version you have
pkg info drm-*-kmod

And then, show the output of:
pkg info your_drm_version| grep FreeBSD_version

Typically a kernel page fault when starting X is caused by a mismatch.

For 15-CURRENT users (me) the problem is a little more involved and out of scope of this discussion.

cy@ · Saturday at 2:37 PM

lgrant said:
The version id drm-515-,mod-5.15.160. The FreeBSD version is 1401000.

This issue seems to be that I really need drm-61-kmod. Switching to that fixed the problem.

But while I was looking into this, I ran into something confusing. I installed the ports tree when I installed the system. According to the FreeBSD handbook, before installing any ports, I should issue this command to update the ports tree:

git -C /usr/ports pull

when I do, I get this error message:

fatal: not a git repository (or any parent up to mount point /usr)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

And /usr/ports/graphics/ does not contain drm-61-kmod, so it is apparently out of date.

If I check out the ports tree, like this:

git clone --depth 1 https://git.FreeBSD.org/ports.git /usr/new-ports

drm-61-kmod is there. If I check out the quarterly ports tree, drm-61-kmod is also there.

How is the ports tree supposed to get updated if you install it with the system?

It doesn't. Ports are separate from source and have been for 10-15 years. This is why ports release quarterly and src releases versions. Back in the day when ports and src were in sync it was a serious headache for the release engineer to make sure all the ducks were lined up. We developers were prohibited from committing anything for up to weeks just so everything could be fixed up for next release. The new workflow is better but at the cost of decoupling src and ports.

drm-61-kmod uses facilities only found in newer kernels. A likely API change, like new fields in data structures (control blocks) too.

Emrion · Saturday at 5:27 PM

cy@ said:
Sometimes they do.

I know well. I'm looking for a solution for people that get bite by this.

Sometimes, it's just incomprehensible for a newcomer. She/he installs the last RELEASE version, wants to have some decent graphic performances or to use, let's say, VirtualBox... And that doesn't work if you are inside this three month period between the advent of a new RELEASE and the repositories become in sync with this last RELEASE.

lgrant said:
The version id drm-515-,mod-5.15.160. The FreeBSD version is 1401000.

So, you have deducted that's not the problem as this package was compiled on 14.1-RELEASE. You don't need to compile drm-61-kmod. The binary package give you the same files (for the moment). But, that's ok, that works as well.

cracauer@ · Saturday at 5:45 PM

A panic might not be the best reaction to the mismatch.

Running into a segmentation fault punishes the user a bit hard.

lgrant · Saturday at 7:01 PM

Agreed....if it just gave you an error message and left you in command line mode, it would be a lot more user-friendly.

cy@ · Saturday at 7:08 PM

Emrion said:
I know well. I'm looking for a solution for people that get bite by this.

Sometimes, it's just incomprehensible for a newcomer. She/he installs the last RELEASE version, wants to have some decent graphic performances or to use, let's say, VirtualBox... And that doesn't work if you are inside this three month period between the advent of a new RELEASE and the repositories become in sync with this last RELEASE.

I've been doing this for 50 years. It's incomprehensible for the newcomer and some concepts -- paging and dynamic address translation, and inode/file retention after files were apparently deleted -- are incomprehensible to many old timers as well. At $JOB I work with people with 25 years experience and they still don't understand some of these concepts. I butt heads with them all the time. For instance, a machine is paging too much so the recommendation by one of my colleagues with 25 years experience was, give the java heap more RAM. Like, what could possibly go wrong?

Much of this stuff is unintuitive.

cracauer@ · Saturday at 7:22 PM

Java GC is a hotbed of misconceptions.

shivars · Tuesday at 1:00 AM

Hi, hopefully this isn't an unwelcome hijack - but I believe I have the same crash, for similar reasons.

This is on a 13900K with integrated UHD 770, plus 2 x Intel ARC A380 GPUs - running 15.0-CURRENT. I got the crash on a fresh install (~2 weeks ago), with the pkg of drm-61-kmod. I've also checked out the kernel source and built the kernel, plus checked out the drm-61-kmod source (i.e. ports) and built that -> but with the same crash.

(kernel + ports were latest main branch, didn't check out any tag)

Could this still be a KBI mismatch (e.g. maybe if I somehow didn't use the newly compiled kernel) - or a hardware/driver issue? Admittedly my setup is probably unusual.

I don't have a nice paste of the output, just a camera screenshot I'm afraid - but happy to provide more debug info if it would be helpful (and/or post to a new post if better to keep this separate):

Many thanks,

lgrant · Tuesday at 7:04 AM

Did you get this message just after i915kms.ko loads? (It would be about one page ahead of what you photographed.)

drmn0: [drm] Incompatible option enable_guc=-1 - undocumented flag

That would seem to definitely point to a mismatch in the drm driver. I built drm-61-kmod from ports, and it fixed the problem. Then I realized there was now a package for drm-61-kmod, so I installed that, and that also fixed the problem. But I am running 14.1-RELEASE. I have no idea what goes on at the 15-CURRENT level.

BTW, I removed the "Solved" tag from the thread, so people are more likely to stop by and look at it.

Erichans · Tuesday at 9:35 AM

lgrant said:
BTW, I removed the "Solved" tag from the thread, so people are more likely to stop by and look at it.

From where I stand it looks like:
- You ran a supported release and had "The version id drm-515-,mod-5.15.160. The FreeBSD version is 1401000."
- The default for 14.1-R is drm61-kmod; you might have gotten drm-515-kmod installed during the three month overlap period.
- You installed drm-61-kmod, a) build from the port b) installed it as a package (now available)

Your problems are solved and you marked the thread accordingly.

Reversing the Solved marker by removing it, seems akin to having found the source of the problem and resolving it successfully and then for-whatever-reason wanting to draw attention to it by means of click-baiting. This runs against the advice and gentle urging of many here towards users to mark their thread as "solved" when it is actually solved.

P.S.

shivars said:
This is on a 13900K with integrated UHD 770, plus 2 x Intel ARC A380 GPUs - running 15.0-CURRENT.

doing these kmod sleuthings in the context of -CURRENT is a) not supported here and b) something totally different alltogether. Running -CURRENT on a (very) modern GPU, you probably should consider running the next version beyond drm-61-kmod.

lgrant · Tuesday at 1:31 PM

Erichans said:
Reversing the Solved marker by removing it, seems akin to having found the source of the problem and resolving it successfully and then for-whatever-reason wanting to draw attention to it by means of click-baiting.

Click-baiting? Really?

This isn’t Facebook or Instagram, where everyone is trying to maximize “likes”.

Shivars tacked their problem on the end of mine. While a different release, it is similar symptoms, so I didn’t have a big problem with that. But nobody is going to help them if they skip the thread because it is marked solved. I’m just trying to help a guy out.

Shivars…perhaps you could cut and paste your problem into a new post that references this one, so I don’t have to take a bunch of flak on your behalf,

Thanks.

P.S. Changing the @*%#$ header back to “Solved”.

shivars · 2024-11-20T16:41:15+0000

Hi, thanks both, appreciate the help.

And apologies for causing confusion - it looked/felt like the same problem and I wasn't sure it had been solved (despite being marked as such), hence posting here.

Erichans said:
doing these kmod sleuthings in the context of -CURRENT is a) not supported here and b) something totally different alltogether. Running -CURRENT on a (very) modern GPU, you probably should consider running the next version beyond drm-61-kmod.

thanks - I hadn't realised that (either about -CURRENT, nor about more recent versions of drm-61-kmod).

I will of course repost as a separate post.

(meantime I'll check that 'incompatible option' piece - thanks Igrant. Also thx re the FreeBSD version - I'd assumed that I'd need 15-CURRENT for later hardware support and it appeared stable enough generally from what I could see, but will give 14.1 a shot. Anecdotally... ...I had tried the 14.1 installer + live environment previously, but couldn't see how to install anything (like the drm packages!) to test the hardware compatibility... ...so just ended up installing with 15.0 to try it all out properly I'll give it another whirl with 14.1).

Thanks again, and sorry for confusing the thread/status! The help is appreciated!