i915kms load locks up Haswell 4.16.g20191120 STABLE_12

[grarpamp]

Christian Weisgerber <naddy at mips.inka.de> wrote:
>> grarpamp <grarpamp at gmail.com> wrote:
>> Is i915kms supposed to work on this plaform?

>> Intel Haswell HD Graphics "Gen7" GT2 [P]4x00
>> drm-fbsd12.0-kmod-4.16.g20191120-88dc2c4884.txz

>> I think wiki/Graphics said yes, but the wiki is down.

"For haswell based systems, if the drm-kmod port does not work"

This implies that it is supposed to work. Same with table on...
wiki/Graphics/Intel-GPU-Matrix

There are some lists here that can help users identify...
https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units
https://en.wikipedia.org/wiki/Intel_Graphics_Technology
https://en.wikipedia.org/wiki/Haswell_(microarchitecture)

>> These load fine in top to bottom order...

>> linuxkpi.ko
>> linuxkpi_gplv2.ko
>> debugfs.ko
>> drm.ko

>> Then attempting to load i915kms locks the system, does
>> not print anything to the console, and requires a hard reset.

>> Straight from the tarball, thus no version conflicts...
>> kern.module_path=''
>> kldload -v $(pwd)/<module>.ko

>> Both of the below load fine...

>> - drm-legacy-kmod-g20191217-913dabbc41.txz
>> - the set in /boot/kernel of the latest snapshot,
>> FreeBSD-12.1-STABLE-amd64-20191219-r355880


> Maybe you ran afoul of the API change 12.0->12.1 issue that
> has caused numerous reports here...?

Btw, no blurb is in src or ports UPDATING, relnotes, or errata.

Though yes now I see a downrev buldbox issue that maybe
you are refer to (they seem to panic, not lock)...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241101
https://github.com/FreeBSDDesktop/kms-drm/issues/183

If this is the case, adding some logic to the [meta] pkg,
and making a 12.1 pkg would seem to solve.
That way none of the release train and progress are held back.
It might be possible to bundle and autoselect based on base
rev from multiple module KBI/ABI/API revs in one package.
Or to point with logic to another pkg repo that is building
just kern mods from a set of light VMs. Or some combination.
Maybe even put some checks or logic in kld mechanism.
Should also see if other kernel modules in ports have this
compatibility problem scheme, so to solve all uniformly.
NO_PACKAGE seems questionable if the result is that hardware
that does work, doesn't, requiring beginner users to build.

No worries.


> [i915kms] does.
> The Xeon E3-1225 v3 machine I'm typing this on attests to it.

What is your base revision? It may be different than the above
snapshot. If different, users could try that snapshot, or build
the revision.

> Built from the graphics/drm-fbsd12.0-kmod port on 12.1-STABLE

What is your ports revision? It may be different than the above
tarball that the pkg tool is downloading. If different, users could
fetch and confirm the contents of the tarball, or build the revision.

What is your output from kldstat -v | egrep '/.*/' ?

Looks like ports head is coming from FreeBSDDesktop,
will put a build on todo.

There are even much newer iGPU uarch's under fbsd
now so looks like something is happening for users :)


(Corrected subject to be stable, not releng.)