From nobody Mon Jan 12 15:08:26 2026 X-Original-To: ports@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 4dqbNx4Zspz6NhjN for ; Mon, 12 Jan 2026 15:08:33 +0000 (UTC) (envelope-from ben@benhutton.com.au) Received: from mail.myuniquemail.com (mail.myuniquemail.com [115.70.107.139]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dqbNw61lHz3dP2 for ; Mon, 12 Jan 2026 15:08:32 +0000 (UTC) (envelope-from ben@benhutton.com.au) Authentication-Results: mx1.freebsd.org; none Received: from [10.128.2.124] (unknown [10.128.10.1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mail.myuniquemail.com (Postfix) with ESMTPSA id 45F231FFB07; Mon, 12 Jan 2026 23:08:27 +0800 (AWST) Message-ID: <3f4dc592-8c30-4b2d-a688-54cb3039f8f7@benhutton.com.au> Date: Mon, 12 Jan 2026 23:08:26 +0800 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-ports@freebsd.org Sender: owner-freebsd-ports@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Performance Issues with latest DRM To: Tomoaki AOKI Cc: ports@freebsd.org References: <63A514D3-C74C-4D6C-9A20-3DD1C5D65160@benhutton.com.au> <20260103134618.c5625ef41eeb01240cd2784b@dec.sakura.ne.jp> <20260112212648.46a3118556072647ad26ab17@dec.sakura.ne.jp> Content-Language: en-AU From: Ben Hutton In-Reply-To: <20260112212648.46a3118556072647ad26ab17@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10143, ipnet:115.70.104.0/21, country:AU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dqbNw61lHz3dP2 Thank you for the response. I'll investigate your suggestions. I have already opened a bug report (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292140). I'm not sure I'm clear enough. However I am not 100% sure myself what's actually going on at present, just that rolling back the nvidia version resolves the issue. On 1/12/26 20:26, Tomoaki AOKI wrote: > On Mon, 12 Jan 2026 08:21:19 +0800 > Ben Hutton wrote: > >> Which mailing list can I use to contact the DRM guys? > Maybe here is the proper ML. > There is freebsd-x11 ML, but it's used almost for any PRs > assigned to x11 group maintainer that at least some of DRM guys > belong to. You'll see almost nothing is "actually" discussed there. > > The best option would be to file a PR on Bugzilla if you have > account for it. > > https://www.freebsd.org/support/bugreports/ > > Other ways would require patch to review, but you can report > to Bugzilla without patches. > > Don't forget to start the summary with seemingly problematic > ports origin like below. > > graphics/drm-66-kmod, graphics/nvidia-drm-66-kmod-devel: ... > > It would allow Bugzilla to automatically notify it to > the maintainers. > > And you need to describe about your hardware having issues. > > For laptops, maybe most of them does NOT allow nvidia dGPU > to drive internal display panel directly (forces Optimus). > > Some (like ThinkPad P52 with nvidia dGPU) allows disabling > iGPU and let nvidia dGPU to drive the panel directly. > > Some forces dGPU to drive internal panel via Optimus only > but give dGPU to drive external monitor via specific limited > DP / HDMI port. > > So without precise and detailed information, no good advice > and/or fixes cannot be provided. > > > Maybe unrelated with your issue (slowness), nvidia seems to be > working on issues introduced recently (possibly in conjunction > with any of fixed issues). > > See the comments starting from below. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291919#c4 > > >> Currently I'm stuck on version 580.105.08 of the nvidia drivers until I >> can find a solution to this issue. Note I have also tried the devel >> nvidia ports when on the latest commit of the ports tree. I'm currently >> using commit 011d8882ade1f40a4f39e08ad9d183733cc43fd4 to compile the >> previous versions. >> >> I'm also on commit 5d73fca1f4b2bac8833e2b9233fa496059dab745 for /usr/src. >> >> Kind regards >> Ben >> >> On 1/3/26 21:54, Ben Hutton wrote: >>> Current version is 1600007 >>> >>> Head is 2e92aeede85c8986bd6f4dde65d2ac2449eccf51 >>> >>> I'm using latest for all packages >>> >>> drm packages have all been built from ports. >>> >>> ports tree latest updated with 'portsnap fetch extract' >>> >>> pkg version -v | grep nvidia >>> nvidia-driver-580.119.02           =   up-to-date with port >>> nvidia-drm-66-kmod-580.119.02.1600007_2 =   up-to-date with port >>> nvidia-kmod-580.119.02.1600007     =   up-to-date with port >>> nvidia-settings-580.119.02         =   up-to-date with port >>> nvidia-xconfig-580.119.02          =   up-to-date with port >>> >>> >>> pkg version -v | grep drm >>> drm-66-kmod-6.6.25.1600007_8       =   up-to-date with port >>> libdrm-2.4.131,1                   =   up-to-date with port >>> linux-rl9-libdrm-2.4.123           =   up-to-date with port >>> nvidia-drm-66-kmod-580.119.02.1600007_2 =   up-to-date with port >>> >>> I did find the following in /var/log/messages >>> >>> Jan  3 20:00:38 tesla kernel: nvidia-modeset: Loading NVIDIA Kernel >>> Mode Setting Driver for UNIX platforms  580.119.02  Mon Dec  8 >>> 07:29:16 UTC 2025 >>> Jan  3 20:00:38 tesla kernel: [drm] [nvidia-drm] [GPU ID 0x00000100] >>> Loading driver >>> Jan  3 20:00:38 tesla kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: >>> Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] >>> (20251212/nsarguments- >>> 212) >>> Jan  3 20:00:38 tesla kernel: sysctl_add_oid: can't re-use a leaf >>> (hw.dri.debug)! >>> Jan  3 20:00:38 tesla kernel: sysctl_add_oid: can't re-use a leaf >>> (hw.dri.vblank_offdelay)! >>> Jan  3 20:00:38 tesla kernel: sysctl_add_oid: can't re-use a leaf >>> (hw.dri.timestamp_precision)! >>> Jan  3 20:00:38 tesla kernel: [drm] Initialized nvidia-drm 0.0.0 >>> 20160202 for nvidia0 on minor 1 >>> >>> I'm not 100% sure how the hybrid graphics works on this laptop however >>> I'm under the impression that the Intel GPU is generally used when on >>> the laptop screen and the Nvidia GPU runs the externals screens under >>> normal workloads. How do I verify? >>> >>> Kind regards >>> Ben >>> >>> >>> On 1/3/26 12:46, Tomoaki AOKI wrote: >>>> On Sat, 3 Jan 2026 11:02:40 +0800 >>>> Ben Hutton wrote: >>>> >>>>> Hi, >>>>> >>>>> Since I upgraded the drm drivers about a week ago I’ve been having >>>>> issues. Either I can get XFCE performing correctly with the Intel >>>>> GPU or suspend but not both. I was able to roll back to and older >>>>> Current version 1600004 and get old versions of the DRM drivers >>>>> installed which get it working. Basically it was been about a week >>>>> of painful trial and error working out what is going on. >>>>> >>>>> 1. XFCE is unusably slow when switching to laptop only screen. It >>>>> works perfectly when using an external screen. Being a hybrid >>>>> graphics laptop I’m assuming the Intel drivers aren’t working and >>>>> the Nvidia is working perfectly fine. >>>>> 2. If using XFCE suspend no longer works. >>>>> >>>>> Curiously it seem to work ok on KDE Plasma 6. >>>>> >>>>> I’m currently running Current with drm-66-kmod and the equivalent >>>>> Nvidia drivers. Curiously installing older versions of the Nvidia >>>>> drivers will get XFCE performing better however it then breaks >>>>> suspend. I’m suspecting something is going wrong with the switchover >>>>> from Nvidia to intel drivers. Quite often when you disconnect the >>>>> external screen you get a black screen on the laptop where the mouse >>>>> still works but nothing else. I’ve had this before when hybrid >>>>> graphics mode is not working correctly. If I plug in the and >>>>> disconnect the external screen it tends to work the second time. >>>>> This wasn’t happening before. >>>>> >>>>> Before updating the DRM drivers it was working very well with XFCE >>>>> with suspend working most of the time. >>>>> >>>>> Is there a way I can work out what is actually failing. I’ve looked >>>>> in /var/log/messages but so far haven’t found any errors that would >>>>> give any idea of what’s going on. >>>>> >>>>> >>>>> Ben Hutton >>>>> ben@benhutton.com.au >>>>> 0434 211 939 >>>> Hi. >>>> >>>> At which commit your main (16-Current) installation is? >>>> >>>> Are you building from ports? Or using pkg? >>>> At which branch of ports tree (or pkg repo) are you using? >>>> Latest (aka main)? Or quarterly (for now, still 2025Q4)? >>>> >>>> If you're using ports, at which commit your ports tree is? >>>> >>>> How pkg (8) says on: >>>>    `pkg version -v | grep nvidia` >>>>    `pkg version -v | grep drm` >>>> >>>> How do you configure nvidia drivers? >>>> Using graphics/nvidia-drm-*-kmod[-devel] that corresponds >>>> to matching graphics/drm-*-kmod? >>>> >>>> Or using graphics/drm-*-kmod for iGPU with internal display >>>> and x11/nvidia-kmod* with corresponding x11/nvidia-driver* >>>> for nvidia dGPU with external display only? >>>> >>>> IIRC, there were some laptops allowing such a configuration >>>> but disallowing internal display to be used by nvidia dGPU >>>> unless hybrid graphics (Optimus) is in use. >>>> >>>> Anyway, at least your main (16-Current) installation is already >>>> outdated. (Currently at #define __FreeBSD_version 1600007.) >>>> >>>> Seemingly there's nothing I can help further if nvidia >>>> dGPU is sanely working. But info above would help digging >>>> into by DRM guys. >>>> >>>> Regards. >