Fedora 40 xfce Steam games 2nd monitor

Ask Fedora
, , , ,
1

I recently switched from Fedora 37 Xfce to Fedora 40 Xfce. On F37 I was able to play Steam games on my 2nd (external) monitor by making the 2nd monitor primary (Settings->Display). With F40 this doesn’t seem to work. Even though I’ve set the 2nd external monitor as primary, the game only start on the 1st (laptop) display.

$ xrandr | grep ' connected'
eDP-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
DP-1-0 connected primary 1920x1080+1920+0 (normal left inverted right x axis y axis) 527mm x 296mm

Is there something different between F37 and F40 with regards to making the external monitor primary?

Is there something else I need to do to force Steam and/or the games to use the 2nd monitor?

I’m using an Nvidia GeForce RTX 3080 laptop GPU with the RPM Fusion Nvidia drivers (560.35.03), in case that’s relevant.

2

IME most apps start on the screen where the mouse is and the launcher is clicked (or the command in a terminal window is used.

Which screen are you using to click the launcher?

It also may be related to the GPU in use. Optimus laptops with dual gpu normally use the iGPU to manage the internal screen and the dGPU to manage the external screen. If you have an nvidia GPU and have not installed the nvidia drivers then the dGPU cannot do hardware acceleration for graphics so the better performance will be seen on the internal screen.

3

I tried moving both the Steam client window (where the game is launched) and the mouse to the external monitor, but that made no difference, regardless where it’s launched or where the mouse is, the games start on the internal (laptop) monitor… mostly…

After trying a few more games, I’m starting to wonder if this is caused by and/or related to Proton (wine). Of the games I’ve tried, most of the ones that start on the internal monitor are Windows games and thus require Proton. Some (not all) of the native linux games will start on the external monitor. I think I’m using the same version of Proton that I was using in F37, but can’t say that for sure, I’ll need to check.

With regards to the nvidia driver. Yes, I have installed the nvidia driver via RPM Fusion (see dnf output below). Except I did not install the Cuda package (xorg-x11-drv-nvidia-cuda) because I thought (perhaps incorrectly) that it’s not needed for playing games. The GPU isn’t used for anything other than games. Is the Cuda package needed or desired for games? I did just now notice cuda-libs is installed, but not the Cuda package mentioned above.

# dnf list installed '*nvidia*'
Installed Packages
akmod-nvidia.x86_64                        3:560.35.03-1.fc40   @rpmfusion-nonfree-updates
kmod-nvidia-6.10.5-200.fc40.x86_64.x86_64  3:555.58.02-1.fc40   @@commandline             
kmod-nvidia-6.10.6-200.fc40.x86_64.x86_64  3:560.35.03-1.fc40   @@commandline             
nvidia-gpu-firmware.noarch                 20240811-2.fc40      @updates                  
nvidia-modprobe.x86_64                     3:560.35.03-1.fc40   @rpmfusion-nonfree-updates
nvidia-settings.x86_64                     3:560.35.03-1.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia.x86_64                 3:560.35.03-2.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-cuda-libs.x86_64       3:560.35.03-2.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-kmodsrc.x86_64         3:560.35.03-2.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-libs.i686              3:560.35.03-2.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-libs.x86_64            3:560.35.03-2.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-power.x86_64           3:560.35.03-2.fc40   @rpmfusion-nonfree-updates

And, at least according to lspci and lsmod I seem to be using the nvidia driver. I don’t know how to tell if I have an “Optimus” laptop. It’s an MSI GS66 Stealth 10UH254.

# lspci -n -n -k | grep -A 2 -e VGA -e 3D
00:02.0 VGA compatible controller [0300]: Intel Corporation CometLake-H GT2 [UHD Graphics] [8086:9bc4] (rev 05)
	DeviceName: Onboard - Video
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:12ed]
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104M [GeForce RTX 3080 Mobile / Max-Q 8GB/16GB] [10de:249c] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:12ed]
	Kernel driver in use: nvidia

# lsmod | sort | egrep -i 'nouveau|nvidia'
nvidia              72577024  42 nvidia_uvm,nvidia_modeset
nvidia_drm            135168  5
nvidia_modeset       1650688  3 nvidia_drm
nvidia_uvm           6844416  0
video                  81920  3 msi_wmi,i915,nvidia_modeset
4

It is optimus since it has 2 different GPUs.

Are you using X11 or wayland for the DE?

Once the game starts you should be able to drag it over to the other monitor as long as it is not in full screen mode.

5

X11

$ loginctl show-session 2 -p Type
Type=x11

In F37, I could start the game on the external monitor in fullscreen (or borderless window matching the size of fullscreen). That’s what I’m trying to get back to with F40. If I have to start each game in a window and move it over, then I’m stuck with a window (which I don’t want). So that’s not a solution.

If trying to move the game as a window is just to TEST to see if it works, and that test will indicate something that leads to a solution, then I’d be happy to do some more testing. I have tried doing that but it’s very game specific how get a window that can be moved and even then it doesn’t seem to work. In fact with Fallout 4, the main game I’ve been testing with, the game hangs as soon as I move the window.

6

Try to update the nvidia driver packages xorg-x11-drv-nvidia* from the rpmfusion-nonfree testing repository. They do fix some packaging errors regarding vulkan and egl.

7

So, it turns out the 2nd monitor issue appears to be a problem with Proton 9. See:

Games not launching on primary monitor with Proton 9.0-1 on multiple monitors.

I switched to Proton 8 and now the same games that would only start on the internal monitor will start on the external (primary) monitor. There are other issues I haven’t really started to test - even though the games now start on the external monitor, they freeze up almost immediately or soon after. So, I may be interested in the suggestion below…

I’m not completely opposed to trying this, but I’d rather not start using test software if I can help it. In fact, I didn’t realize Proton 9 was beta until I found the above link. There was no indication it was beta in the Steam client when I installed it.

Is there a way I can update the nvidia drivers from testing without “committing” to using the testing repo? In other words, can I either just install from testing without enabling the testing repo or temporarily add the testing repo and remove it?

If I do update the packages from testing, then can I undo it if it doesn’t help… or what happens when those packages move to the normal (non-testing) updates repo. Will dnf automatically recognize it’s the same package from a different repo and just handle it or do I need to do something special to get back onto the non-testing version of the packages?

For reference, I generally try to keep my system up-to-date from the command line:

# dnf check-update
glance at the list of updates
# dnf update

Actually, I do try to separate out *kernel* *nvidia* updates using --exclude and then do them as their own update.

8

The link above is empty.

The rpms will be pushed to stable next week anyway.
dnf upgrade <packages> --enablerepo=<reponame>
this enables a repository for this transaction only.

dnf repolist disabled to get a list of the repositories.

As a workaround, you could deactivate the internal display when you start a game with proton 9.

9

Sorry about that… fixed, link above should work now.

OK, I may just wait… depends what I find with my other testing regarding the game freezing. If that can be solved using Proton 8, then I’m not sure there’s any immediate need to start using Proton 9.

But, I’m still a bit confused about what happens if I DO install something from testing. Take this as more of a general question, not necessary related to the nvidia drivers. If have SOMEREPO enabled, but do NOT have SOMEREPO-testing enabled and I upgrade a package from SOMEREPO-testing, eg

dnf upgrade Package-X --enablerep=SOMEREPO-testing

Then what happens when the same version of that package is pushed to stable at some point in the future and I do “dnf upgrade Package-X”? Does dnf simply ignore Package-X for this version since it’s the same as the installed version from the testing repo? Or does it recognize they are from different repos and reinstall it? Or some other behavior?

I often use the internal display while playing a game, so I wouldn’t view this as a real solution. For testing something, sure I’d be happy to test it. As a short term temp solution… maybe. But again, if I can get the games to run without freezing using Proton 8, then I don’t think there’s much reason to use Proton 9. And since the games worked fine (both on external display and without freezing) on F37 using Proton 8, then it seems like they should also work fine on F40.

10

The latest drivers have already been moved from testing to the release repo.
Simply update everything with dnf upgrade or only the nvidia drivers with dnf upgrade akmod-nvidia which should pull in all the latest nvidia packages to the 560.35.03 version

11

Take a closer look at my previous post where I showed the output “dnf list installed” and Mark’s post about the testing repo. I’m already using 560.35.03-2, but the testing repo contains 560.35.03-3.

# dnf list xorg-x11-drv-nvidia.x86_64
Last metadata expiration check: 0:06:02 ago on Sat 31 Aug 2024 04:15:58 PM PDT.
Installed Packages
xorg-x11-drv-nvidia.x86_64        3:560.35.03-2.fc40        @rpmfusion-nonfree-updates

# dnf --enablerepo=rpmfusion-nonfree-updates-testing list xorg-x11-drv-nvidia.x86_64
Last metadata expiration check: 0:06:05 ago on Sat 31 Aug 2024 04:15:58 PM PDT.
Installed Packages
xorg-x11-drv-nvidia.x86_64    3:560.35.03-2.fc40     @rpmfusion-nonfree-updates       
Available Packages
xorg-x11-drv-nvidia.x86_64    3:560.35.03-3.fc40     rpmfusion-nonfree-updates-testing
12

I updated my nvidia drivers to 560.35.03-3.fc40 which was pushed to the release repo earlier this week, but it didn’t help. I’ve also done a lot more testing with Proton 8/9 and F37/40.

There seems to be 2 problems, which may or may not be related.

  1. Games freeze on Fedora 40 if started on external monitor.
  2. Games started with Proton 9 use position 0,0 and ignore Primary (see below).

On Fedora 37, regardless which monitor the game is started on, it runs fine.

On Fedora 40, if the game is started on the external monitor it will freeze after a short period of time. This only seems to be true for games using Proton, not native linux games, so I suspect it’s somehow Proton related, but then it only happens on Fedora 40 not 37 so that would suggest something related to the kernel? X11? nvidia?

With regards to which monitor a game starts on - it seems to be consistent between F37 and F40 and depends on Proton version:

Proton 8: Game starts on monitor defined as Primary.

Proton 9: Game starts on monitor at position 0,0 and ignores Primary. So, if the external monitor is configured on the left of internal or above internal, the game will start on the external monitor. If the external monitor is configured right of internal or below internal, the game starts on the internal monitor.

All of my testing was done on the same hardware (laptop and external monitor). I have a multi-boot system with one partition Fedora 37 and another Fedora 40.

13

I haven’t found any solutions and I’m considering downgrading the NVIDIA drivers to see if that helps. From what I can tell, the only prior version available via rpmfusion is 550.67-1 in the rpmfusion-nonfree repo (see below).

Looking through a couple other posts (Post 1, Post 2), it seems like these commands should (hopefully) do the trick:

# dnf downgrade \*nvidia\* --exclude nvidia-gpu-firmware --allowerasing
(wait for akmod to complete - ie. watch ps/top)
# dnf config-manager --set-disabled rpmfusion-nonfree-updates
# reboot

Before I screw my system up, I’d just like to know if that seems reasonable or if I’ll need to do more than that? Or something other than that?

Do I also need/want to downgrade nvidia-gpu-firmware? It looks like version 20240312-1 is available in the fedora repository. Since it doesn’t use the same version as the drivers it’s not obvious (to me) if the firmware version is dependent on the driver version.

And then, assuming that does work, if/when the NVIDIA drivers are updated with a possible fix, I would just need to do something like this?

# dnf config-manager --set-enabled rpmfusion-nonfree-updates
# dnf update \*nvidia\*
(wait...)
# reboot

Here’s the aforementioned NVIDIA package versions, both currently installed and what looks to be available in rpmfusion-nonfree.

# dnf list installed '*nvidia*'
Installed Packages
akmod-nvidia.x86_64                        3:560.35.03-1.fc40   @rpmfusion-nonfree-updates
kmod-nvidia-6.10.5-200.fc40.x86_64.x86_64  3:555.58.02-1.fc40   @@commandline             
kmod-nvidia-6.10.6-200.fc40.x86_64.x86_64  3:560.35.03-1.fc40   @@commandline             
kmod-nvidia-6.10.7-200.fc40.x86_64.x86_64  3:560.35.03-1.fc40   @@commandline             
nvidia-gpu-firmware.noarch                 20240811-2.fc40      @updates                  
nvidia-modprobe.x86_64                     3:560.35.03-1.fc40   @rpmfusion-nonfree-updates
nvidia-persistenced.x86_64                 3:560.35.03-1.fc40   @rpmfusion-nonfree-updates
nvidia-settings.x86_64                     3:560.35.03-1.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia.x86_64                 3:560.35.03-3.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-cuda.x86_64            3:560.35.03-3.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-cuda-libs.i686         3:560.35.03-3.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-cuda-libs.x86_64       3:560.35.03-3.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-kmodsrc.x86_64         3:560.35.03-3.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-libs.i686              3:560.35.03-3.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-libs.x86_64            3:560.35.03-3.fc40   @rpmfusion-nonfree-updates
xorg-x11-drv-nvidia-power.x86_64           3:560.35.03-3.fc40   @rpmfusion-nonfree-updates

# dnf --showduplicates --disablerepo="*" --enablerepo=rpmfusion-nonfree list available '*nvidia*'
Last metadata expiration check: 2:06:45 ago on Mon 09 Sep 2024 11:49:37 AM PDT.
Available Packages
akmod-nvidia.x86_64                            3:550.67-1.fc40           rpmfusion-nonfree
kmod-nvidia.x86_64                             3:550.67-1.fc40           rpmfusion-nonfree
nvidia-modprobe.x86_64                         3:550.67-1.fc40           rpmfusion-nonfree
nvidia-persistenced.x86_64                     3:550.67-1.fc40           rpmfusion-nonfree
nvidia-settings.x86_64                         3:550.67-1.fc40           rpmfusion-nonfree
nvidia-xconfig.x86_64                          3:550.67-1.fc40           rpmfusion-nonfree
xorg-x11-drv-nvidia.x86_64                     3:550.67-1.fc40           rpmfusion-nonfree
xorg-x11-drv-nvidia-cuda.x86_64                3:550.67-1.fc40           rpmfusion-nonfree
xorg-x11-drv-nvidia-cuda-libs.i686             3:550.67-1.fc40           rpmfusion-nonfree
xorg-x11-drv-nvidia-cuda-libs.x86_64           3:550.67-1.fc40           rpmfusion-nonfree
xorg-x11-drv-nvidia-devel.i686                 3:550.67-1.fc40           rpmfusion-nonfree
xorg-x11-drv-nvidia-devel.x86_64               3:550.67-1.fc40           rpmfusion-nonfree
xorg-x11-drv-nvidia-kmodsrc.x86_64             3:550.67-1.fc40           rpmfusion-nonfree
xorg-x11-drv-nvidia-libs.i686                  3:550.67-1.fc40           rpmfusion-nonfree
xorg-x11-drv-nvidia-libs.x86_64                3:550.67-1.fc40           rpmfusion-nonfree
xorg-x11-drv-nvidia-power.x86_64               3:550.67-1.fc40           rpmfusion-nonfree
14

Downgrading the driver will not fix the issue with Proton9.

Not sure if downgrading is supported by the nvidia rpms.
What def. should work is a dnf remove, don’t reboot, dnf install with rpmfusion-nonfree-updates repo disabled, wait for akmods to build the kernel modules and reboot.

You can also find other versions on koji.rpmfusion.org
e.g. for package xorg-x11-drv-nvidia
xorg-x11-drv-nvidia | Package Info | koji
the latest available version was 550.90.07, search for the other required packages nvidia*

download the packages you want into one directory e.g nvidia-550.90.07.fc40
and install with dnf install nvidia-550.90.07.fc40/*rpm

15

I agree… it’s the “game freezes on external monitor” issue I’m hoping to solve by downgrading the drivers. As mentioned before, there’s 2 issues:

  1. F40 only - games freeze if started on external monitor - both Proton 8 and 9
  2. Proton 9 only - games ignore Primary monitor and use 0,0 - both F37 and F40

Downgrading the NVIDIA drivers is an attempt to fix the 1st issue only.

I’m not sure either, I took it from this post. But if removing and installing accomplishes the same thing, I’m fine with that. So, I assume that means this:

# dnf remove \*nvidia\* --exclude nvidia-gpu-firmware
# dnf config-manager --set-disabled rpmfusion-nonfree-updates
# dnf install akmod-nvidia xorg-x11-drv-nvidia-cuda
(wait for akmods)
# reboot

When I originally installed the NVIDIA drivers a few weeks ago, I only explicitly installed the akmod-nvidia package, so I assume that still holds true now - ie. installing akmod-nvidia will trigger installing all the other xorg-x11-drv-nvidia* packages needed.

I initially didn’t install xorg-x11-drv-nvidia-cuda because I didn’t think it was needed for gaming. I later installed it only because it contains the nvidia-smi command, which I’ve been using for testing purposes.

Ah… thank you. Good to know.

16

careful with that, this will also remove libva-nvidia-driver

you can also use
dnf install akmod-nvidia xorg-x11-drv-nvidia-cuda --disablerepo=rpmfusion-nonfree-updates

and then add a versionlock
dnf repoquery --installed nvidia-\* xorg-x11-drv-nvidia\* akmod-nvidia --exclude nvidia-gpu\* | xargs dnf versionlock add

verify with dnf versionlock list
remove all = clear with dnf versionlock clear

man dnf-versionlock for more details

Proton9: as it’s creating the window/surface on the monitor with the coordinate 0,0 (top left corner), I wonder if it’s possible to define a layout where your ext. primary display starts at 0,0 and the internal FHD display has the coordinates of -1920,0 (top left corner)?

That’s how Windows configures the primary display. The top left corner of the primary display is always 0,0 and every other display is configured accordingly relative to this monitor.

17

I don’t have the libva-nvidia-driver package installed (although maybe I should since I use Firefox), but that’s a warranted caution for anyone else viewing this in the future. Make sure the packages to be removed are only the ones you want to remove.

Interesting. To be clear, I don’t KNOW Proton 9 is using 0,0, that’s just my assumption based on what I’ve seen. I suppose it could be looking at the coordinates and taking whatever is the lowest number (including negative) to be “Primary”. But it might be worth testing.

I use the Xfce Settings->Display dialog to configure the display positions and it doesn’t have any options (I’m aware of) to set specific coordinates. So, I assume this will require manual configuration of the xorg.conf file? I’m not too familiar with creating/editing xorg.conf… I think I’ve done it in the past, but it’s been many many years.

Or maybe it could be done with nvidia-xconfig (I don’t currently have it installed and have never used it), or maybe via xrandr?

Also, I assume that if I change the layout by any of those methods (edit xorg.conf, nvidia-xconfig or xrandr) I’ll need to avoid using Settings->Display since it would presumably overwrite those changes?

18

I removed 560.35.03 and installed 550.67. That part seemed to go fine, I didn’t see any errors. But after waiting for akmod to finish and rebooting, I’m now using the nouveau drivers, so something didn’t work.

I see this while booting (I removed “rhgb quiet” from /etc/default/grub):

[  OK  ] Finished akmods.service - Builds and install new kmods from akmod packages.
         Starting nvidia-fallback.service - Fallback to nouveau as nvidia did not load...

When I first installed the nvidia drivers back on Aug 21st (555.58.02 at that time), there was no issues with akmod. And I upgraded the nvidia drivers (a couple times I think) since then and there was no issues then either.

Is there a log file that shows what akmod did? I couldn’t find one.

A few things:

  1. I added --noautoremove to the dnf remove command under the (possibly mistaken) assumption that all those deps would just need to be installed again, so there’s no point in removing them.

  2. The “remove” list included the kmod-nvidia packages (one for each of 3 kernels). I assumed (again perhaps incorrectly), that akmod-nvidia would regenerate those packages. They are listed as from the “@@commandline” repo.

  3. I waited to reboot until after I’d installed 550.67. Is it possible some aspect of 560.35.03 was still hanging around which caused a problem with akmod?

So, this is what I did:

# dnf remove '*nvidia*' --exclude nvidia-gpu-firmware --noautoremove
# dnf config-manager --set-disabled rpmfusion-nonfree-updates
# dnf install akmod-nvidia xorg-x11-drv-nvidia-cuda
(wait for akmod)
# reboot

And 550.67 is definitely installed, although what’s noticeably missing are the kmod-nvidia packages for the kernels.

# dnf list installed '*nvidia*'
Installed Packages
akmod-nvidia.x86_64                      3:550.67-1.fc40      @rpmfusion-nonfree
nvidia-gpu-firmware.noarch               20240909-1.fc40      @updates          
nvidia-modprobe.x86_64                   3:550.67-1.fc40      @rpmfusion-nonfree
nvidia-persistenced.x86_64               3:550.67-1.fc40      @rpmfusion-nonfree
nvidia-settings.x86_64                   3:550.67-1.fc40      @rpmfusion-nonfree
xorg-x11-drv-nvidia.x86_64               3:550.67-1.fc40      @rpmfusion-nonfree
xorg-x11-drv-nvidia-cuda.x86_64          3:550.67-1.fc40      @rpmfusion-nonfree
xorg-x11-drv-nvidia-cuda-libs.i686       3:550.67-1.fc40      @rpmfusion-nonfree
xorg-x11-drv-nvidia-cuda-libs.x86_64     3:550.67-1.fc40      @rpmfusion-nonfree
xorg-x11-drv-nvidia-kmodsrc.x86_64       3:550.67-1.fc40      @rpmfusion-nonfree
xorg-x11-drv-nvidia-libs.i686            3:550.67-1.fc40      @rpmfusion-nonfree
xorg-x11-drv-nvidia-libs.x86_64          3:550.67-1.fc40      @rpmfusion-nonfree
xorg-x11-drv-nvidia-power.x86_64         3:550.67-1.fc40      @rpmfusion-nonfree

Here’s the list of packages that would have been removed if I had not used --noautoremove. Or at least this is the list that will be removed if I remove 550.67, I assume it was the same set for 560.35.03:

akmods                      noarch   0.5.8-8.fc40      @fedora
fakeroot                    x86_64   1.34-1.fc40       @updates
fakeroot-libs               x86_64   1.34-1.fc40       @updates
kernel-devel-matched        x86_64   6.10.8-200.fc40   @updates
kmodtool                    noarch   1.1-10.fc40       @fedora
libgit2                     x86_64   1.7.2-4.fc40      @updates
libglvnd-opengl             i686     1:1.7.0-4.fc40    @fedora
llhttp                      x86_64   9.2.1-1.fc40      @updates
opencl-filesystem           noarch   1.0-20.fc40       @fedora
openssl                     x86_64   1:3.2.2-3.fc40    @updates
python3-babel               noarch   2.16.0-1.fc40     @updates
python3-click               noarch   8.1.7-4.fc40      @fedora
python3-click-plugins       noarch   1.1.1-19.fc40     @fedora
python3-progressbar2        noarch   3.53.2-11.fc40    @fedora
python3-pygit2              x86_64   1.14.0-1.fc40     @fedora
python3-rpmautospec         noarch   0.7.2-1.fc40      @updates
python3-rpmautospec-core    noarch   0.1.5-1.fc40      @updates
python3-typing-extensions   noarch   4.12.2-2.fc40     @updates
python3-utils               noarch   3.7.0-3.fc40      @fedora
rpmdevtools                 noarch   9.6-7.fc40        @fedora
19

Found the akmods log and ran “akmods --force” as it suggested. Also tried “akmods --force --rebuild”.

2024/09/11 17:37:51 akmods: Checking kmods exist for 6.10.8-200.fc40.x86_64
2024/09/11 17:37:51 akmods: Building and installing nvidia-kmod
2024/09/11 17:37:51 akmods: Building RPM using the command '/usr/sbin/akmodsbuild --kernels 6.10.8-200.fc40.x86_64 /usr/src/akmods/nvidia-kmod.latest'
2024/09/11 17:38:11 akmods: Building rpms failed; see /var/cache/akmods/nvidia/550.67-1-for-6.10.8-200.fc40.x86_64.failed.log for details
2024/09/11 17:38:11 akmods: Hint: Some kmods were ignored or failed to build or install.
2024/09/11 17:38:11 akmods: You can try to rebuild and install them by by calling
2024/09/11 17:38:11 akmods: '/usr/sbin/akmods --force' as root.

The top part of /var/cache/akmods/nvidia/550.67-1-for-6.10.8-200.fc40.x86_64.failed.log is:

2024/09/11 17:37:51 akmods: Building RPM using the command '/usr/sbin/akmodsbuild --kernels 6.10.8-200.fc40.x86_64 /usr/src/akmods/nvidia-kmod.latest'
/tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/nvidia/nv-ibmnpu.c:428:5: warning: no previous prototype for ‘nv_get_ibmnpu_chip_id’ [-Wmissing-prototypes]
  428 | int nv_get_ibmnpu_chip_id(nv_state_t *nv)
      |     ^~~~~~~~~~~~~~~~~~~~~
/tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/nvidia/nv-ibmnpu.c:437:6: warning: no previous prototype for ‘nv_ibmnpu_cache_flush_numa_region’ [-Wmissing-prototypes]
  437 | void nv_ibmnpu_cache_flush_numa_region(nv_state_t *nv)
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/nvidia/nv-report-err.c:25:
/tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/common/inc/nv-linux.h: In function ‘nv_vmalloc’:
/tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/common/inc/nv-linux.h:477:33: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
  477 |         NV_MEMDBG_ADD(ptr, size);
      |                                 ^
/tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/common/inc/nv-linux.h: In function ‘nv_ioremap’:
/tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/common/inc/nv-linux.h:495:33: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
  495 |         NV_MEMDBG_ADD(ptr, size);
      |                                 ^
/tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/common/inc/nv-linux.h: In function ‘nv_ioremap_cache’:
/tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/common/inc/nv-linux.h:531:33: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
  531 |         NV_MEMDBG_ADD(ptr, size);
      |                                 ^
/tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/common/inc/nv-linux.h: In function ‘nv_ioremap_wc’:
/tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/common/inc/nv-linux.h:548:33: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
  548 |         NV_MEMDBG_ADD(ptr, size);
      |                                 ^
/tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/common/inc/nv-linux.h: In function ‘nv_vmap’:
/tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64/common/inc/nv-linux.h:674:51: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
  674 |         NV_MEMDBG_ADD(ptr, page_count * PAGE_SIZE);
      |                                                   ^
make[2]: *** [/usr/src/kernels/6.10.8-200.fc40.x86_64/Makefile:1946: /tmp/akmodsbuild.PlEYnPA9/BUILD/nvidia-kmod-550.67/_kmod_build_6.10.8-200.fc40.x86_64] Error 2
make[1]: *** [Makefile:252: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/kernels/6.10.8-200.fc40.x86_64'
make: *** [Makefile:85: modules] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.nO2j1i (%build)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.nO2j1i (%build)

And /var/tmp/rpm-tmp.nO2j1i:

#!/bin/sh

  
  RPM_SOURCE_DIR="/tmp/akmodsbuild.PlEYnPA9/SOURCES"
  RPM_BUILD_DIR="/tmp/akmodsbuild.PlEYnPA9//BUILD"
  RPM_OPT_FLAGS="-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer"
  RPM_LD_FLAGS="-Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes "
  RPM_ARCH="x86_64"
  RPM_OS="linux"
  RPM_BUILD_NCPUS="12"
  RPM_SPECPARTS_DIR="/tmp/akmodsbuild.PlEYnPA9//BUILD/nvidia-kmod-550.67-SPECPARTS"
  export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_ARCH RPM_OS RPM_BUILD_NCPUS RPM_SPECPARTS_DIR RPM_LD_FLAGS
  RPM_DOC_DIR="/usr/share/doc"
  export RPM_DOC_DIR
  RPM_PACKAGE_NAME="nvidia-kmod"
  RPM_PACKAGE_VERSION="550.67"
  RPM_PACKAGE_RELEASE="1.fc40"
  export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE
  LANG=C.UTF-8
  export LANG
  unset CDPATH DISPLAY ||:
  unset DEBUGINFOD_URLS ||:
  unset RPM_CONFIG_DIR ||:
  RPM_BUILD_ROOT="/tmp/akmodsbuild.PlEYnPA9/BUILDROOT/nvidia-kmod-550.67-1.fc40.x86_64"
  export RPM_BUILD_ROOT
  
  PKG_CONFIG_PATH="${PKG_CONFIG_PATH}:/usr/lib64/pkgconfig:/usr/share/pkgconfig"
  export PKG_CONFIG_PATH
  CONFIG_SITE=${CONFIG_SITE:-NONE}
  export CONFIG_SITE 
  set -x
  umask 022
  cd "/tmp/akmodsbuild.PlEYnPA9//BUILD" 
  
  CFLAGS="${CFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer }" ; export CFLAGS ; 
  CXXFLAGS="${CXXFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer }" ; export CXXFLAGS ; 
  FFLAGS="${FFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules }" ; export FFLAGS ; 
  FCFLAGS="${FCFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules }" ; export FCFLAGS ; 
  VALAFLAGS="${VALAFLAGS:--g}" ; export VALAFLAGS ;
  RUSTFLAGS="${RUSTFLAGS:--Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes -Clink-arg=-specs=/usr/lib/rpm/redhat/redhat-package-notes --cap-lints=warn}" ; export RUSTFLAGS ; 
  LDFLAGS="${LDFLAGS:--Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes }" ; export LDFLAGS ; 
  LT_SYS_LIBRARY_PATH="${LT_SYS_LIBRARY_PATH:-/usr/lib64:}" ; export LT_SYS_LIBRARY_PATH ; 
  CC="${CC:-gcc}" ; export CC ; 
  CXX="${CXX:-g++}" ; export CXX 
  
cd 'nvidia-kmod-550.67'

for kernel_version in 6.10.8-200.fc40.x86_64___/usr/src/kernels/6.10.8-200.fc40.x86_64; do
  pushd _kmod_build_${kernel_version%___*}/
    make V=1 -j12 \
        KERNEL_UNAME="${kernel_version%___*}" SYSSRC="${kernel_version##*___}" \
        IGNORE_CC_MISMATCH=1 IGNORE_XEN_PRESENCE=1 IGNORE_PREEMPT_RT_PRESENCE=1 \
        module
  popd
done




  RPM_EC=$?
  for pid in $(jobs -p); do kill -9 ${pid} || continue; done
  exit ${RPM_EC}
20

The tail end of the failed log should show what actually failed near the bottom, not the top.