Date: Wed, 25 Dec 2019 02:10:03 -0500 From: grarpamp <grarpamp@gmail.com> To: freebsd-x11@freebsd.org Subject: i915kms load locks up Haswell 4.16.g20191120 STABLE_12 Message-ID: <CAD2Ti2-B5Gya7g_eLKnqw1Mf05rU5L6_fQ-WG_zZwRNdMdTSQA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Christian Weisgerber <naddy@mips.inka.de> wrote: >> grarpamp <grarpamp@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.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD2Ti2-B5Gya7g_eLKnqw1Mf05rU5L6_fQ-WG_zZwRNdMdTSQA>