Bug 241787 - graphics/drm causes machine reboot after upgrade from 12.0 to 12.1.
Summary: graphics/drm causes machine reboot after upgrade from 12.0 to 12.1.
Status: Closed DUPLICATE of bug 241101
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.1-RELEASE
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: panic, regression
Depends on:
Blocks:
 
Reported: 2019-11-07 19:43 UTC by Tomasz "CeDeROM" CEDRO
Modified: 2020-02-11 15:12 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomasz "CeDeROM" CEDRO 2019-11-07 19:43:01 UTC
Hello world :-)

I have just upgraded my machine from 12.0-RELEASE to 12.1-RELEASE with `freebsd-update upgrade -r 12.1-RELEASE`. Unfortunately the DRM module causes machine to reboot on load. I had to get into single mode and remove DRM and i915 modules from rc.conf. I cannot see a DRM for 12.1 yet. Rebuilding module does not help. I am without DRM right now unable to use external monitor/projector.

Any hints welcome :-)
Tomek

FreeBSD 0xCFMX4 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC  amd64

0xCFMX4% pkg info drm-kmod
drm-kmod-g20190710
Name           : drm-kmod
Version        : g20190710
Installed on   : Thu Nov  7 11:55:49 2019 CET
Origin         : graphics/drm-kmod
Architecture   : FreeBSD:12:*
Prefix         : /usr/local
Categories     : graphics
Licenses       :
Maintainer     : x11@FreeBSD.org
WWW            : https://github.com/FreeBSDDesktop/kms-drm
Comment        : Metaport of DRM modules for the linuxkpi-based KMS components
Annotations    :
Flat size      : 0.00B
Description    :
amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components on
amd64, i915 and radeonkms DRM modules from the former base DRM component on
other architectures.
Metaport for different versions of Linux DRM based on the FreeBSD version
in use. This port encompasses the recommendations of the FreeBSDDesktop team
of DRM versions for FreeBSD versions based on the last update to the LinuxKPI
in that code base. In general, the most recent supported stable DRM for a give
FreeBSD version will be installed. CURRENT receives the most recent development
DRM.
This port does not however hinder the expert user to make other decisions and
continue to install DRM ports directly.

WWW: https://github.com/FreeBSDDesktop/kms-drm
Comment 1 Mateusz Piotrowski freebsd_committer 2019-11-07 21:04:20 UTC
Could that be related?

https://github.com/FreeBSDDesktop/kms-drm/issues/183
Comment 2 Niclas Zeising freebsd_committer 2019-11-08 21:06:54 UTC

*** This bug has been marked as a duplicate of bug 241101 ***
Comment 3 vermaden 2019-12-08 11:56:22 UTC
Why not just create two additional ports?

These already exist:
/usr/ports/graphics/drm-fbsd11.2-kmod
/usr/ports/graphics/drm-fbsd12.0-kmod

Create these (along with packages against 11.3 and 12.1 source):
/usr/ports/graphics/drm-fbsd11.3-kmod
/usr/ports/graphics/drm-fbsd12.1-kmod

Problem solved.

Treating older 12.0 version as 'more important' instead of newer 12.1 seems out of logic.

Regards.
Comment 4 Tomasz "CeDeROM" CEDRO 2019-12-08 17:03:56 UTC
I fully agree, this module is highly experimental, not production ready, should be banned from a RELEASE and PKG because it breaks them in many ways on a production environments.

The problem with PKG is that 12.1 packages are built on 12.0 system, while this module changed KERNEL API and this is the root cause of the problem. SO LINUX :-(

Here is a bug to follow: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241101
Comment 5 Niclas Zeising freebsd_committer 2019-12-08 17:15:44 UTC
(In reply to vermaden from comment #3)

That won't help the situation.
The problem is that ports are built on the lowest common platform, which means, for 12 it is built on 12.0 until 12.0 is EOL (same for 11.2 and 11.3).
The issue here is that while the kernel modules are indeed compatible with their respective branch (drm-fbsd11.2-kmod works on 11.3 and 11-stable, and 12.0-kmod on 12.1 and 12-stable), they have to be built together with kernel sources of the same version of the kernel actually running the module.

Creating drm-fbsd12.1-kmod, or 11.3-kmod would not help, they would either be built on 12.0 and 11.2 respectively (well, 11.2 is EOL now, so the 11.2 module should work on 11.3 out of the box these days), or not built at all, depending on how the version check in the ports' Makefile is set up.

I can agree that the naming of the modules are unfortunate and somewhat confusing, but renaming 11.2-kmod to 11.3-kmod was ruled out when Rene removed 11.2 support from the ports tree.  See https://reviews.freebsd.org/D21974 for that discussion.

In the end, the ambition is to have the user simply install drm-kmod and let that port pick the proper kernel module port for your specific system.

Regards
Niclas Zeising
FreeBSD Graphics Team.

PS.  Please keep the discussion in the open PR (or the github issue, it gets more visibility that way).
Comment 6 vermaden 2019-12-08 22:54:05 UTC
(In reply to Niclas Zeising from comment #5)

That is the root cause of the problem. Packages for 12.1 should be built on 12.1.

Other - more important aspect of such bugs/problems - why FreeBSD would instantly  panic on loading a module with wrong version? This is so Windows like.

It was the same with VirtualBox package between 11.2 and 11.3 when VNET became the default on 11.3.

IMHO the first thing to do should be making these modules NOT INSTANTLY PANIC entire system.

Second should be separate package repositories for each version, currently for 'Production' releases which means - 12.1 / 12.0 / 11.3 - as stated on FreeBSD page.

Current situation is far from 'production ready'.

Regards.
Comment 7 Mark Linimon freebsd_committer freebsd_triage 2019-12-08 23:29:26 UTC
(In reply to vermaden from comment #6)

> Packages for 12.1 should be built on 12.1.

If we did that, as soon as 12.1 came out, we would have stranded the users of pkg on 12.0 (you can't assume you can go downwards).

Or, we could buy enough hardware to have every single branch built -- plus, enough people to look after the build results.  (disclaimer: I am one of the people that looks after the build results)

No, it can't be farmed out to virtual instances somewhere, due to security implications.

tl:dr; some thought has actually gone into these decisions.  This is the one rare case where we've been bitten.
Comment 8 Tomasz "CeDeROM" CEDRO 2019-12-09 00:56:20 UTC
(In reply to vermaden from comment #6)

> That is the root cause of the problem. Packages for 12.1 should be built on 12.1.

I would humbly point that the root cause is Kernel API changes between releases of the same major number.. maybe even different major number.

If we had an architecture designed first in a way that would provide stable Kernel API there would be no problem at all.

Kernel API changes between each release is so Linux.

It smells like a maintenance nightmare we are observing right now because we try to fix the problem that creates a complication with a new complications.

Is it really necessary here in FreeBSD? I don't think so.

Is there really no way to avoid it?

:-)
Comment 9 Denis Polygalov 2020-02-11 13:09:19 UTC
From naive user's point of view this problem can be described as 'bad user
experience' when executing action according to the documentation
(# freebsd-update -r XX.X-RELEASE upgrade) lead to a dead system.

Very rough estimation shows that this problem can be potentially
triggered by any of ~56 ports:

# find /usr/ports -type f -name Makefile|xargs cat|grep USES|grep kmod|wc -l

Moving graphics/drm entirely into ports (e.g. no binary packages for users)
will kick back FreeBSD into stone age and discard all enormous and amazing
work done by graphics team (IMHO).

How about *in addition* to whatever solution will be found for the 
graphics/drm package change behavior of 'freebsd-update'?
Well, strictly speaking - pitch such idea to mainstream FreeBSD developers?

If user execute 'freebsd-update -r XX.X-RELEASE upgrade' the script analyze
current content of /etc/rc.conf and /boot/loader.conf and detect
presence of configuration that includes loading of 3rd-party modules
(any kernel module not shipped with the base system).

If such presence is detected - freebsd-upgrade print warning message
and exit (refuse to execute upgrade) until user disable 3-rd party
modules in his/her config files or specify new argument such as:

# freebsd-update -r XX.X-RELEASE --UNSAFE upgrade

Doing this will eliminate unintentional unsafe upgrade and
mitigate possible bad UX.

Regards,
Denis
Comment 10 vermaden 2020-02-11 15:12:38 UTC
The solution is simple. Just build packages for FreeBSD 12.1 on 12.1 system.

You are wasting time looking for other solutions/workarounds.

Eventually to save time/compute power first use 12.0 packages and then rebuild 'problematic' or kernel related packages again so that 12.1 packages will be fully working out of the box.

The situation where the most up to date FreeBSD 12.1 is less supported (and broken) then older 12.0 version seems stupid to me to say the least ...

Regards,
vermaden