Bug 241101 - i915kms working with 12.0 but not 12.1-BETA3
Summary: i915kms working with 12.0 but not 12.1-BETA3
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-x11 mailing list
Keywords: regression
: 241787 (view as bug list)
Depends on:
Blocks: 240700
  Show dependency treegraph
Reported: 2019-10-06 15:05 UTC by Vincent DEFERT
Modified: 2019-11-10 19:21 UTC (History)
11 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Vincent DEFERT 2019-10-06 15:05:04 UTC
My Lenovo Ideapad 120S laptop has an Intel Graphics 505 adapter (CPU: Pentium N4200 Apolo Lake).

With 12.0-RELEASE, I can kldload /boot/modules/i915kms.ko, /dev/dri and /dev/drm are populated and Xorg's Intel driver works.

With 12.1-BETA3, the same causes my machine to reboot.

When I use /boot/kernel/i915kms.ko from both FreeBSD versions, I have no error message, but /dev/dri and /dev/drm are not created.
Comment 1 nunneorth 2019-10-07 16:34:27 UTC
The same issue on my VAIO Fit15s notebook (i915 Kabylake). 

Following this:


Under 12.0 stable works OK but in 12.1-RC1, 12.1-RC2 and 12.1-RC3 FreeBSD restart at the moment of the load the module.
Comment 2 pete 2019-10-07 16:41:33 UTC
(In reply to Vincent DEFERT from comment #0)
You will need to rebuild graphics/drm-fbsd12.0-kmod locally, I have run into this issue as well.  I believe there is a incompatibility between 12.1-*'s linuxkpi and 12.0 which requires a rebuild of the kmod.
Comment 3 Mark Johnston freebsd_committer 2019-10-08 14:53:37 UTC
(In reply to pete from comment #2)
Do you happen to have the backtrace available from a crash caused by this incompatibility?  I think we will want to fix this for 12.1.
Comment 4 Vincent DEFERT 2019-10-08 15:40:37 UTC
(In reply to Mark Johnston from comment #3)
Are the instructions from the Handbook (https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html) appropriate to provide you with a useful backtrace?
Comment 5 Mark Johnston freebsd_committer 2019-10-08 15:41:43 UTC
(In reply to Vincent DEFERT from comment #4)
Yes, in particular the "backtrace" command at the kgdb prompt.
Comment 6 Vincent DEFERT 2019-10-08 16:55:02 UTC
GNU gdb (GDB) 8.3.1 [GDB v8.3.1 for FreeBSD]
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:
<6>[drm] Connector eDP-1: get mode from tunables:
<6>[drm]   - kern.vt.fb.modes.eDP-1
<6>[drm]   - kern.vt.fb.default_mode
<6>[drm] Connector HDMI-A-1: get mode from tunables:
<6>[drm]   - kern.vt.fb.modes.HDMI-A-1
<6>[drm]   - kern.vt.fb.default_mode

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 04
fault virtual address	= 0x1
fault code		= supervisor read data, page not present
instruction pointer	= 0x20:0xffffffff837a690f
stack pointer	        = 0x28:0xfffffe000047f810
frame pointer	        = 0x28:0xfffffe000047f880
code segment		= base rx0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 0 (softirq_2)
trap number		= 12
panic: page fault
cpuid = 2
time = 1570553153
KDB: stack backtrace:
#0 0xffffffff80c1d207 at kdb_backtrace+0x67
#1 0xffffffff80bd053d at vpanic+0x19d
#2 0xffffffff80bd0393 at panic+0x43
#3 0xffffffff810a7d2c at trap_fatal+0x39c
#4 0xffffffff810a7d79 at trap_pfault+0x49
#5 0xffffffff810a736f at trap+0x29f
#6 0xffffffff8108129c at calltrap+0x8
#7 0xffffffff838a2480 at tasklet_handler+0x100
#8 0xffffffff80c1bac4 at gtaskqueue_run_locked+0x144
#9 0xffffffff80c1b728 at gtaskqueue_thread_loop+0x98
#10 0xffffffff80b90b93 at fork_exit+0x83
#11 0xffffffff810822de at fork_trampoline+0xe
Uptime: 5m12s
Dumping 619 out of 3880 MB:..3%..11%..21%..31%..42%..52%..62%..73%..81%..91%

__curthread () at /usr/src/sys/amd64/include/pcpu.h:234
234		__asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (OFFSETOF_CURTHREAD));
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu.h:234
#1  doadump (textdump=<optimized out>) at /usr/src/sys/kern/kern_shutdown.c:371
#2  0xffffffff80bd0138 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:451
#3  0xffffffff80bd0599 in vpanic (fmt=<optimized out>, ap=<optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:877
#4  0xffffffff80bd0393 in panic (fmt=<unavailable>)
    at /usr/src/sys/kern/kern_shutdown.c:804
#5  0xffffffff810a7d2c in trap_fatal (frame=0xfffffe000047f750, eva=1)
    at /usr/src/sys/amd64/amd64/trap.c:943
#6  0xffffffff810a7d79 in trap_pfault (frame=0xfffffe000047f750, usermode=0)
    at /usr/src/sys/amd64/amd64/trap.c:767
#7  0xffffffff810a736f in trap (frame=0xfffffe000047f750)
    at /usr/src/sys/amd64/amd64/trap.c:443
#8  <signal handler called>
#9  0xffffffff837a690f in ?? ()
#10 0xffffffff81a01004 in hc_source_mask ()
#11 0x0000000100000001 in ?? ()
#12 0x0000000000000000 in ?? ()
Comment 7 Niclas Zeising freebsd_committer 2019-11-04 14:16:13 UTC
The issue is that packages for FreeBSD are built on the lowest common supported version.  This means that packages for FreeBSD 12 (both 12.0 and 12.1, as well as 12-STABLE) are built on FreeBSD 12.0.
There has been a change somewhere in the time between 12.0 and 12.1 that makes certain kernel modules, i915kms.ko is one of them (both drm-fbsd12.0-kmod and drm-legacy-kmod) fail when loaded on a FreeBSD 12.1 kernel.
The best work around for this is to simply build the kernel module from ports on FreeBSD 12.1.  This is safe to do even on systems that otherwise use binary packages.
This is a known issue, with no really good solution currently.
It has been discussed within the graphics team quite a lot, however, I was unaware that this PR existed.
https://github.com/FreeBSDDesktop/kms-drm/issues/183 is the issue we have open on github.
FreeBSD Graphics Team
Comment 8 Ed Maste freebsd_committer 2019-11-04 19:37:25 UTC
Reopen, this is going to be a significant issue on 12.1 until 12.0 goes EOL and this PR is useful for tracking the issue.
Comment 9 Niclas Zeising freebsd_committer 2019-11-08 21:06:54 UTC
*** Bug 241787 has been marked as a duplicate of this bug. ***