Date: Mon, 12 Jan 2026 21:26:48 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: Ben Hutton <ben@benhutton.com.au> Cc: ports@freebsd.org Subject: Re: Performance Issues with latest DRM Message-ID: <20260112212648.46a3118556072647ad26ab17@dec.sakura.ne.jp> In-Reply-To: <d86aa485-123a-4140-97b6-4de449a6848c@benhutton.com.au> References: <63A514D3-C74C-4D6C-9A20-3DD1C5D65160@benhutton.com.au> <20260103134618.c5625ef41eeb01240cd2784b@dec.sakura.ne.jp> <bd77f2f8-46af-420f-87e9-0105a728dc2c@benhutton.com.au> <d86aa485-123a-4140-97b6-4de449a6848c@benhutton.com.au>
index | next in thread | previous in thread | raw e-mail
On Mon, 12 Jan 2026 08:21:19 +0800 Ben Hutton <ben@benhutton.com.au> 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 <ben@benhutton.com.au> 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. -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20260112212648.46a3118556072647ad26ab17>