Bug 241101 - i915kms working with 12.0 but not 12.1-BETA3
Summary: i915kms working with 12.0 but not 12.1-BETA3
Status: Closed Works As Intended
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 (Nobody)
URL:
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: 2021-11-20 21:57 UTC (History)
21 users (show)

See Also:


Attachments

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:

https://wiki.freebsd.org/Graphics#Intel_Integrated_Graphics_.28aka_HD_Graphics.29

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 freebsd_triage 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 freebsd_triage 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:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

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 ?? ()
(kgdb)
Comment 7 Niclas Zeising freebsd_committer freebsd_triage 2019-11-04 14:16:13 UTC
Hi!
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.
Regards
Niclas
FreeBSD Graphics Team
Comment 8 Ed Maste freebsd_committer freebsd_triage 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 freebsd_triage 2019-11-08 21:06:54 UTC
*** Bug 241787 has been marked as a duplicate of this bug. ***
Comment 10 Tomasz "CeDeROM" CEDRO 2019-12-08 16:56:58 UTC
The issue is NOT FIXED!!!

After I had to manually build the port, PKG did a replace with a newer version that was built on 12.0 and again CAUSED REBOOT LOOP ON A MOUNTED WORKING FILESYSTEMS.

Another workaround, except building the port by hand, is to PKG LOCK it, so updates won't break your system.

I would say:
1. THIS MODULE IS HIGHLY EXPERIMENTAL AND BREAKS THE PRODUCTION SYSTEMS IN MANY WAYS.
2. THIS MODULE SHOULD NOT BE AVAILABLE IN A RELEASE.
3. THIS MODULE SHOULD NOT BE AVAILABLE VIA PKG.
4. THIS MODULE SHOULD NOT MAKE FreeBSD LOOK LIKE LINUX.

:-(
Comment 11 Tomasz "CeDeROM" CEDRO 2019-12-08 17:00:47 UTC
Here is a GitHub issue to follow: https://github.com/FreeBSDDesktop/kms-drm/issues/183
Comment 12 Niclas Zeising freebsd_committer freebsd_triage 2019-12-08 17:15:05 UTC
(In reply to Tomasz "CeDeROM" CEDRO from comment #10)

No one has claimed this  has been fixed.  Byt keeping track of which ports need to be installed from ports, and which from packages, must be done by the person administrating the system.

I would also like to ask a question, how would you go about this?  We can't put the code in the base system for a number of reasons, licensing being one, and different pace of updating being another, so it has to live in ports.
Comment 13 Theron Tarigo 2019-12-08 18:09:00 UTC
This is really two bugs:
(1) Package repository contains an incompatible kmod which panics the system instead of checking compatibility.
(2) Package repository doesn't contain a working i915kms for 12.1

(In reply to Niclas Zeising from comment #12)
To fix (1) I propose a much simpler fix: Patch the kmod itself to take responsibility for checking whether the kernel is compatible, since the kernel otherwise assumes modules to be forward compatible.

While indeed, working around the issue is easy enough for the system administrator, I agree with Tomasz that the binary pkg situation is unacceptable.
Comment 14 Tomasz "CeDeROM" CEDRO 2019-12-08 18:22:22 UTC
Hey Niclas :-)

My "not fixed" was response to  Vincent DEFERT 2019-11-04 19:32:26 UTC / Status: New → Closed / Resolution: --- → FIXED.

> No one has claimed this  has been fixed.  Byt keeping track of which ports
> need to be installed from ports, and which from packages, must be done by
> the person administrating the system.

Negative. Providing malicious PKG that WILL CRASH the system and lead to DESTROY ITS DATA is the responsibility of the package creator, committer and maintainer. Also the FreeBSD Core Team NOT to allow such situation to happen. If there is such _risk_ it should not land in production/release! Now we have such _existing_situation_ in the production systems! Really not cool :-(

User / Admin hits the `pkg update upgrade` on a _PRODUCTION_ system with an official production packages so it gets a production system updated and working.

We cannot get with FreeBSD to a Linux mindset where user needs to perform additional 472847824 tasks to make things work. It never happened before and I really hope it never will.

> I would also like to ask a question, how would you go about this?

The answer is above. The situation should never happen. Do not push the bleeding edge into the production. Block all known issues in a way they would not happen on a production system.

1. Remove DRM-KMOD out of PKG at all until there is a working solution. Leaving it in PKG causes production systems to crash. What more evidence do you need?

2. Do not allow Linux like programming where API changes from release to release into FreeBSD Kernel. I am sure most users are good to wait for quality code rather than bleeding edge Kernel. We avoid Linux for that reason.

Cheers :-)
Comment 15 Warner Losh freebsd_committer freebsd_triage 2019-12-08 18:30:58 UTC
Tomasz "CeDeROM" CEDRO that was uncalled for. being a dick about it isn't going to help. We're quite aware of the situation and are working on a solution. You can speed that along, of course, by providing patches. Until then, if you can't conduct yourself in a civil manner, please don't say anything.
Comment 16 Warner Losh freebsd_committer freebsd_triage 2019-12-08 18:39:54 UTC
Tomasz "CeDeROM" CEDRO your tone is insulting and not helpful. There's no need to be a dick about this. Please refrain from commenting further if you can't conduct yourself in a civil manner.
Comment 17 Tomasz "CeDeROM" CEDRO 2019-12-08 18:44:57 UTC
(In reply to Theron Tarigo from comment #13)

Thank you Tarigo :-) I did a fix by rebuilding the module on a 12.1, but then it was replaced by pkg upgrade, causing the problem again. I would prefer to have such package globally blacklisted rather than blocking it myself after it crashed my production machine.

I would really prefer to see a message from PKG "Please build this package from Ports otherwise it will not work reliably on this system" rather than getting back into system crash loop after I considered problem to be solved.

The root cause of this problem, and I hope no more problems like this in future, is allowing Linux like bleeding edge approach in Kernel, including Kernel API changes with each release. I am sure there can be a good solution for that, so we do don't need to "fix problems that never existed before"^TM. Otherwise what would be the difference between FreeBSD and Linux? :-)
Comment 18 Adam Weinberger freebsd_committer freebsd_triage 2019-12-08 18:46:13 UTC
I think the initial question we have to answer here is: are we intending to produce a drm-fbsd12.1-kmod port, or are we going to wait until the new year for 12.0 to EOL so the problem will resolve itself?

If the latter, that's fine, but we should at least add a pkg-message saying not to use i915kms on 12.1. And we should have a separate discussion about how to address this scenario in the future.
Comment 19 Tomasz "CeDeROM" CEDRO 2019-12-08 18:48:29 UTC
(In reply to Warner Losh from comment #16)

Just remove that package from PKG repository. I already proposed that over mailing lists. That would push user to use Ports which is a working quick fix for the time.

Regarding the dicks, I would really prefer not to see them in my Kernel. I stopped using Linux at 2.4.10 exactly when the same issue arised with graphics card kernel api change. Then it became standard. Please do not do that in FreeBSD.
Comment 20 Niclas Zeising freebsd_committer freebsd_triage 2019-12-08 18:49:28 UTC
(In reply to Tomasz "CeDeROM" CEDRO from comment #19)

You don't have to install the package, at all.  It is not possible to have it in ports, but not available as a package, and that would also break for people using FreeBSD 12.0, where the package works.
Comment 21 Tomasz "CeDeROM" CEDRO 2019-12-08 18:53:09 UTC
Guys I really appreciate your work on FeeBSD my beloved OS. I know the difference between user and creator. You have far more works and responsibilities. I know.  Please just do not go the Linux way. That's all :-)
Comment 22 Niclas Zeising freebsd_committer freebsd_triage 2019-12-08 18:55:29 UTC
(In reply to Adam Weinberger from comment #18)

Hi Adam!
We (the graphcis team) have some patches and ideas about providing a drm kmod package that builds on FreeBSD 12.0 using 12.1 headers, and then would work on FreeBSD 12.1 (but not 12.0).  This task is not as easy as it seams, though.

We are also working on a more long term solution to the problem, probably using a DKMS like approach, where the module is built when it is installed, rather than on the ports cluster.  The package would probably contain two parts, a pre-built module that would be installed if the local system version matches the system version where the package was built, and the means to build it locally if this is not the case.  This solution requires more thought though.

Having a way to not load the module (or issue an error when it is loaded, and then stop loading) if the versions doesn't match is also something we have discussed.  A similar approach has been suggested for virtualbox kmod, which exhibits the same issues, but not been accepted there: https://reviews.freebsd.org/D16119 .
Comment 23 Tomasz "CeDeROM" CEDRO 2019-12-08 18:56:30 UTC
(In reply to Niclas Zeising from comment #20)
Well, the difference is:

1. Linux: It works on 12.0 but crashes 12.1 but we will ship it anyway.

2. BSD: It works on 12.0 but crashes 12.1 so we block it so no one gets hurt.
Comment 24 Theron Tarigo 2019-12-08 19:23:41 UTC
What is the resistance to adding NO_PACKAGE=yes to the port *right now* and the issue resolves itself next time the repository is rebuilt?  12.0 users will revolt?  At this point: Existing installations of 12.0 will keep working, just not receive any drm-kmod pkg upgrades.  New installations of 12.0 (why?) would be in exactly same camp as 12.1: need to build the port locally.
Comment 25 Adam Weinberger freebsd_committer freebsd_triage 2019-12-08 19:34:50 UTC
(In reply to Niclas Zeising from comment #22)

I think that seems like a great long-term approach, Niclas!

For now though, can we please add something to pkg-message? We need to warn people that this problem exists. Let's take some sort of step to prevent others from hitting this showstopping bug.

A long-term solution is great, but people are going to keep running into this bug, and we can at least do something about that.
Comment 26 Theron Tarigo 2020-02-28 18:41:26 UTC
(In reply to Niclas Zeising from comment #22)
How far has this gotten?  In the mean time I've played with another approach: review D23881
Comment 27 jdrch 2020-03-09 02:58:23 UTC
Same problem here. Dell OptiPlex 390 SFF (Intel Core 2nd Gen.) Thanks to this I pretty much can't run 12.1 (I need a DE.) Since I don't run outdated OS releases, I'm gonna have to abandon FreeBSD. Basic functionality like this not working is a major shortcoming of the project, and before someone chimes in with the "manpower" excuse, OpenIndiana runs quite well on the same hardware.
Comment 28 Theron Tarigo 2020-03-09 03:07:26 UTC
(In reply to jdrch from comment #27)
Are you sure you are encountering the same problem?  Since 12.0 reached end-of-life, binary packages are built for 12.1.
Comment 29 jdrch 2020-03-09 03:44:03 UTC
(In reply to Theron Tarigo from comment #28)
I'm reasonably sure it's the same problem. My machine has an onboard HDMI and VGA port. The default KDE setup on FreeBSD 12.1-RELEASE results in both displays defaulting to the lower resolution of the VGA monitor.

I figured this was because there was no Intel driver installed, but when I did pkg install drm-kmod I noticed pkg pulled down the 12.0 version despite me being on 12.1. After following the instructions here https://wiki.freebsd.org/Graphics#Intel_Integrated_Graphics_.28aka_HD_Graphics.29 I rebooted into a mangled desktop: https://imgur.com/wNvNWV6

This led me to suspect that the drm-kmod for 12.1 might not actually exist. I googled it, which is how I discovered this thread. 

I've since followed the instructions here https://www.freebsd.org/doc/handbook/x-config.html and wound up with 2 flashing displays at a prompt where KDE should have started.

In short, this is just way too much effort required for *basic* functionality that other projects nail right off the bat. If I'm struggling with simple stuff like monitors I can't imagine how much worse it will get when I'm attempting something that should be more complicated.

The funny thing is, I've been running FreeBSD in some shape or form since 2018. 1st with Project Trident, then GhostBSD. I decided to migrate to FreeBSD proper after getting frustrated with incompatibilities resulting from GhostBSD's use of OpenRC instead of rc.d. And now here I am.

It's just too frustrating.
Comment 30 Theron Tarigo 2020-03-09 05:30:55 UTC
(In reply to jdrch from comment #29)
> when I did pkg install drm-kmod I noticed pkg pulled down the 12.0 version despite me being on 12.1.
I think you are being confused by the unfortunate naming of the port: "drm-fbsd12.0-kmod" really is the port for 12.x, and currently gets built for 12.1 as that is currently the only supported 12.x release.

> This led me to suspect that the drm-kmod for 12.1 might not actually exist.
It very much does exist, I've just reinstalled it to be sure:
$ uname -r 
    12.1-RELEASE
$ pkg info drm-fbsd12.0-kmod
    drm-fbsd12.0-kmod-4.16.g20200221
    Name           : drm-fbsd12.0-kmod
    Version        : 4.16.g20200221
    Origin         : graphics/drm-fbsd12.0-kmod
    Architecture   : FreeBSD:12:amd64
...
    Annotations    :
	FreeBSD_version: 1201000
	repo_type      : binary
	repository     : FreeBSD

If you can be sure you do have a 12.1 kernel installed and your packages are up to date, then there is some other reason your system panics on startup.
Comment 31 jdrch 2020-03-09 06:24:38 UTC
I figured it out (using FuryBSD) and documented the solution here: https://github.com/jdrch/Hardware/wiki/Useful-Links#how-to-set-up-multiple-monitors-on-dell-optiplex-390-sff

As it turns out, neither the drm-kmod nor its legacy counterpart work, but instead some obscure x86(possible incorrect spelling) driver option FuryBSD gives you the option of automatically setting up.

Thanks for your input. Looks like I'll be staying with FreeBSD for a bit longer at the least ;)
Comment 32 Emmanuel Vadot freebsd_committer freebsd_triage 2021-11-19 14:17:01 UTC
drm-kmod (and most external kmods that uses unstable KBI like vm) cannot work on different minor version.
No need to keep this PR opened.
Comment 33 Theron Tarigo 2021-11-19 16:31:56 UTC
(In reply to Emmanuel Vadot from comment #32)
Is there another bug to track this limitation of the kmod packages?  If I try to search for this problem all I find is drm-kmod related.
Comment 34 jdrch 2021-11-19 16:37:37 UTC
(In reply to Emmanuel Vadot from comment #32)

Pretty stunning admission, but I've already moved on from FreeBSD due to the awful DE support, and this is more proof thereof. Thanks for being honest, at least.
Comment 35 Tomasz "CeDeROM" CEDRO 2021-11-19 17:08:56 UTC
Feedback from the future: I am on 13-STABLE now, previously 13.0-RELEASE, graphics works like a charm on Intel laptop (Panasonic Toughbook), quite efficiently, multiple monitors setup with Enlightenment WM, BIG THANK YOU, and I am really happy that we did not go the Linux way, FreeBSD ROX! Thank you :-)
Comment 36 jdrch 2021-11-19 19:08:11 UTC
(In reply to Tomasz "CeDeROM" CEDRO from comment #35)

From personal experience I can pretty much guarantee that will fall apart at some point. Maybe not this year. I ran FreeBSD from 2018 to earlier this year when I couldn't stand to spend more time addressing DE issues other distros handle just fine. You'll run into issues eventually, and when you do, you'll most likely remember this thread.
Comment 37 rkoberman 2021-11-20 21:57:29 UTC
I have been running X on FreeBSD for about a quarter of a century and I can assure you that:
You will never be able to use packages unless you are running RELEASEs. You will need kernel sources on the build systems. Those sources MUST match the running kernel. This is unlikely to ever change.

Things are much better than they have been in years. I have not had any significant issues in about a decade. I did need to wait a short time for support for Comet Lake to make it to a RELEASE and run 13-CURRENT for a few months until 13 was released. My older system (Sandy Bridge) has been rock solid for over a decade.

On any particular graphics device, it will fail in time. The primary X hardware support developers are quick to drop support for older hardware as are manufacturers. Nvidia and Intel support seems excellent.