From nobody Fri Jan 19 08:04:16 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TGXFj1hQJz587LG for ; Fri, 19 Jan 2024 08:04:25 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TGXFh1Vfkz4HGD; Fri, 19 Jan 2024 08:04:24 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of bsd-lists@bsdforge.com has no SPF policy when checking 24.113.41.81) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 40J84Hmp059014; Fri, 19 Jan 2024 00:04:23 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Fri, 19 Jan 2024 00:04:16 -0800 From: Chris To: Jan Beich Cc: freebsd-current Subject: Re: Alder lake supported? (graphics) In-Reply-To: References: <666f1d1b09c1e23a36a90a125546f0f3@bsdforge.com> <4bae65e0dc5766ce8c2cf58cff91af0d@bsdforge.com> User-Agent: UDNSMS/17.0 Message-ID: <38ab771d76d26fd8dd026793aa9d37a7@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4TGXFh1Vfkz4HGD X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.00 / 15.00]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; MIME_TRACE(0.00)[0:+]; local_wl_ip(0.00)[24.113.41.81]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] On 2024-01-18 15:42, Chris wrote: > On 2024-01-18 15:28, Chris wrote: >> On 2024-01-18 08:47, Jan Beich wrote: >>> Chris writes: >>> >>>> On 2024-01-16 19:02, Jan Beich wrote: >>>> >>>>> Chris writes: >>>>> >>>>>> I upgraded to an alder lake based machine and installed 14. >>>>>> But I can't seem to get the intel graphics loaded (drm-515-kmod). >>>>>> It simply freezes at load. >>>>>> Are Alder lake graphics supported? >>>>> Try drm-61-kmod instead (with gpu-firmware-intel-kmod-alderlake >= >>>>> 20230625). >>>>> Reported success in >>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270888#c8 >>> [...] >>>> I'm on 14. Commenting that conditional indicates I don't have a necessary >>>> file (linux/iosys-map.h). So looks like I'll we'll have to wait. Or I'll >>>> need to track 15. :( >>> >>> On current@ list -CURRENT is expected. Due to backward compatibility it's >>> possible to run -CURRENT kernel with -RELEASE userland (world + packages). >>> For example, poudriere (as used by the package cluster) relies on this >>> to build binary packages for older FreeBSD versions on the same machine. >>> >>> Alternatively, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274770#c5 >>> proposed a branch which removes .require_force_probe for both ADL-S and >>> ADL-P. >>> It builds fine on 14.0-RELEASE "as is" e.g., see ports/ diff below. >>> >>> diff --git a/graphics/drm-515-kmod/Makefile.version >>> b/graphics/drm-515-kmod/Makefile.version >>> index 4a7c27611bc8..469071220731 100644 >>> --- a/graphics/drm-515-kmod/Makefile.version >>> +++ b/graphics/drm-515-kmod/Makefile.version >>> @@ -1,5 +1,5 @@ >>> # drm-kmod common version definition >>> # >>> # This will be included from consumers such as nvidia-drm >>> -DRM_KMOD_DISTVERSION= 5.15.118 >>> -DRM_KMOD_GH_TAGNAME= drm_v5.15.118_4 >>> +DRM_KMOD_DISTVERSION= 5.15.focal >>> +DRM_KMOD_GH_TAGNAME= 97a4ad4364 >>> diff --git a/graphics/drm-515-kmod/distinfo >>> b/graphics/drm-515-kmod/distinfo >>> index 3599fc42317b..cadc6be14456 100644 >>> --- a/graphics/drm-515-kmod/distinfo >>> +++ b/graphics/drm-515-kmod/distinfo >>> @@ -1,3 +1,3 @@ >>> -TIMESTAMP = 1703336317 >>> -SHA256 (freebsd-drm-kmod-5.15.118-drm_v5.15.118_4_GH0.tar.gz) = >>> 58e2fc195979e2361346ca57cc158e44413e5de26b83b951a631d09849caf90c >>> -SIZE (freebsd-drm-kmod-5.15.118-drm_v5.15.118_4_GH0.tar.gz) = 26092371 >>> +TIMESTAMP = 1698298780 >>> +SHA256 (freebsd-drm-kmod-5.15.focal-97a4ad4364_GH0.tar.gz) = >>> fc6a94a74aea714bb25ccf788b8361de4db348ef1893fc391d00bd346e828732 >>> +SIZE (freebsd-drm-kmod-5.15.focal-97Thank you very mua4ad4364_GH0.tar.gz) >>> = 26126042 >> Thank you very much for all your time and efforts in your replies, Jan. >> I examined the the forum thread and applied your patch to a current pull of >> ports. >> After deinstalling my current install of 515.118, I performed a make >> install. Which >> proceeded as expected. A kld_list resulted in a hard lock, in the same way >> 515.118 did. >> Requiring the use of the power button to power it down. Then a boot to >> single-user for >> an fsck(8). Nothing reported in the logs. A boot without loading via >> rc.conf was went >> without incident. A kldload i915kms locked it up hard. Again, nothing >> reported in the >> logs. I'm keeping recent copies of /var/logs/messages in case there is >> anything anyone >> might be interested in looking at. >> At this point I've resolved to boot a recent 15 and format my current >> slices and unpack >> a recent snapshot of 15 in hopes of getting decent graphics support on >> this. I'm happy >> to test or further report anything that might be helpful for others. >> > I forgot to mention. When calling kldload i915kms > the screen returned only (transcribed): > > iic0: < I2C generic I/O > iicbus0 > iic1: < I2C generic I/O > iicbus1 > Lindebugfs registered > UPDATE It's not i915kms that causes the problem. Turns out to be the graphics/gpu-firmware-intel-kmod. I opened a pr (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276451). Thanks again for all your help, Jan. --Chris