Intel GPU fails in 12.2-RELEASE

[probonopd]

Intel GPU fails in 12.2-RC3 when its driver is activated using the tool. Why?

[probonopd]

Because:
https://github.com/furybsd/furybsd-livecd/issues/241

[probonopd]

Using GhostBSD kernel-related packages on FreeBSD is an equal mess, since GhostBSD apparently has a slightly different kernel version 👎

+ /usr/local/sbin/pkg-static -c /usr/local/furybsd/uzip add http://pkg.ghostbsd.org/stable/FreeBSD:12:amd64/latest/All/drm-fbsd12.0-kmod-4.16.g20200221.txz
Fetching drm-fbsd12.0-kmod-4.16.g20200221.txz: .......... done
Installing drm-fbsd12.0-kmod-4.16.g20200221...
Newer FreeBSD version for package drm-fbsd12.0-kmod:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1202502
- running kernel: 1202000
Ignore the mismatch and continue? [y/N]: 
Failed to install the following 1 package(s): http://pkg.ghostbsd.org/stable/FreeBSD:12:amd64/latest/All/drm-fbsd12.0-kmod-4.16.g20200221.txz

[probonopd]

https://darkness-pi.monwarez.ovh/posts/synth-repository/ seems to have a version for 12.2-RELEASE:

https://darkness-pi.monwarez.ovh/amd64/All/drm-fbsd12.0-kmod-4.16.g20200221.txz

Source: https://forums.freebsd.org/threads/i915kms-package-breaks-on-12-2-release-workaround-build-from-ports.77501/#post-483344

[probonopd]

Getting device_attach: drmn0 attach returned 19. What does this mean?

[probonopd]

https://darkness-pi.monwarez.ovh/amd64/All/drm-fbsd12.0-kmod-4.16.g20200221.txz can be loaded using kldload, but when the Xorg conf file is deleted and Xorg is restarted, then it crashes. Log says:

open /dev/dri/card0: No such file or directory

[probonopd]

With https://darkness-pi.monwarez.ovh/amd64/All/drm-fbsd12.0-kmod-4.16.g20200221.txz being loaded using

/usr/sbin/sysrc -f /etc/rc.conf kld_list+="sysctlinfo cuse utouch i915kms" >/dev/null 2>/dev/null

everything crashes entirely on MacBook Pro:

This code is deprecated. Install the graphics/drm-kmod pkg

Followed by a kernel panic.

Seems to be somehow related to https://github.com/freebsd/freebsd/blob/385c75cbde809d365679483a04ed3c77d213bf4b/sys/dev/drm2/drm_os_freebsd.h#L159.

[probonopd]

For now, reverting to 12.1 until the driver pkg is targeting 12.2.

[grahamperrin]

https://www.freshports.org/graphics/drm-fbsd12.0-kmod/#history graphics/drm-fbsd12.0-kmod was updated a few hours ago; consider retrying. Thanks.

(12.1 is expected to reach end of life in less than a week.)

[probonopd]

When a port was updated, it can take some time until the binary package gets updated. How much time? I don't know.

Besides, we are not using this quarter's packages but last quarter's ones, because quarterly can have missing packages any day...

[grahamperrin]

last quarter's

Thanks, I wasn't aware of that.

Document it? Maybe at or near https://hellosystem.github.io/docs/user/troubleshooting.html

until the binary package gets updated.

https://www.freshports.org/graphics/drm-fbsd12.0-kmod/#packages shows:

FreeBSD:12:amd64 | 4.16.g20201016 | 4.16.g20201016

Now I see, 4.16.g20201016 appears at two points in the commit history. https://www.freshports.org/graphics/drm-fbsd12.0-kmod/#distinfo the timestamp equates to:

UTC 2020-11-16T09:38:11.000Z

– so yes, it appears that we're waiting for a build of the same version based on yesterday's commit.

[grahamperrin]

I struck through part of my previous comment. I lacked an understanding of things.

#135 shows FreeBSD 12.2-RELEASE-p3 working with (loading) kernel modules from packages from latest.

I'm changing the test system there from latest to quarterly, with a consequent downgrade of some packages through a forced upgrade of all packages. I'll restart the system then recheck that /boot/modules/i915kms.ko can load. Another success is expected.

[probonopd]

0.4.0 is using FreeBSD 12.1 (because 12.2 had issues with the Intel GPU driver being incompatible) and last quarter's packages (because this quarter's packages can disappear from one day to the next, making it impossible to build the ISO).
We still need to find a better way for this.

For 0.5.0 we will possibly switch to 12.2, if we can get Intel GPU to work. But we will still be unable to use this quarter's packages for the same reason. Unless we mirror a full set of "known good" packages.

[grahamperrin]

#135 (comment)

… does it work?

With my everyday hardware, which does not have Intel graphics:

• I can't tell.

With Intel Mobile 4 Series Chipset Integrated Graphics Controller:

• yes
• Packages built for FreeBSD 12.2 - NomadBSD Development - NomadBSD Forum

[grahamperrin]

From last night's https://old.reddit.com/r/freebsd/comments/lj7pns/issues_with_drmkmod/gnay5z6/:

You shouldn't have to compile drm-kmod from ports … I did a clean install … installed drm-kmod through pkg and everything is running fine. Same goes for my desktop … Intel. …

From the related probe https://bsd-hardware.info/?probe=cfc7d86b5a:

Intel Atom Processor Z36xxx/Z37xxx Series Graphics & Display

[probonopd]

crees@8e4ed05 by @crees works around this by using custom-built packages. However, we would like this issue to be resolved in upstream FreeBSD "properly" and rather not use (or build) third-party packages for what is already a part of FreeBSD.

But if this issue doesn't get resolved in upstream FreeBSD anytime soon, we may be forced to use such a workaround. In this case, we need to find a way to produce the pkgs in question using Cirrus CI.

[crees]

@probonopd, this will not be fixed in FreeBSD during the lifetime of 12, as it simply can't-- I'm sorry. I absolutely agree that this is sub-optimal, and as a FreeBSD developer I am disappointed, but it does appear to be a rather strange and unique issue.

It's very easy to custom build packages, but I'm happy to take on maintenance of this part.

Cirrus CI is definitely capable of dealing with poudriere- I'll take a look at this.

In the meantime, I strongly recommend that you pull this commit (I'll open a request) as it's far better to have working but slightly messy build procedure IMO than having it look awful on the default VESA driver, no? :)

[probonopd]

Thank you very much @crees.

It is not yet decided what will be the basis for the upcoming 0.5.0 release - I am still experimenting. If we can't get 12.2 to work with Intel GPUs, then we have no choice but to use 12.1. Which of course would be even further from ideal.

Cirrus CI is definitely capable of dealing with poudriere- I'll take a look at this.

As much as I trust you personally as a FreeBSD developer, I would like to not pull in packages from "random" places without at least a clear audit trail/reproducability, such as Cirrus CI. So if we can make a GitHub repository that builds the 3 packages in question using Cirrus CI and uploads them to GitHub Releases, then I'd be much more happy to merge a pull request that would use such packages.

I hope you can understand my position. Again, thank you very much for looking into this issue.

[probonopd]

Thanks to @crees this is working now and we can use 12.2 as the base for 0.5.0.
Thank you very much 👍

[grahamperrin]

Using GhostBSD kernel-related packages on FreeBSD is an equal mess, since GhostBSD apparently has a slightly different kernel version -1

Why the thumbs-down?

[probonopd]

Because GhostBSD and FreeBSD packages seem not to be binary compatible.

In any case, I think the FreeBSD team has recognized the Intel GPU driver issue and is working on it, and for this I give a big 👍 :-)