Bug 1280461

Can you please attach a kernel log, preferably one from after a lockup so I may have some idea of what might have occurred.

Thanks,
Ben.

I don't mean to sound stupid, but, with all the fluff that's been added to Linux lately, "kernel log" has become a pretty nebulous term. Would "journalctl -k -b -1" suffice? Tell me what would be most helpful to you.

Same problem, x86_64, Nvidia Quadro K600, KDE spin of F23.

(In reply to Ben Skeggs from comment #1)
> Can you please attach a kernel log, preferably one from after a lockup so I
> may have some idea of what might have occurred.
> 
> Thanks,
> Ben.

I'll copy this from comment 2, since apparently I should have replied instead of commenting.

I don't mean to sound stupid, but, with all the fluff that's been added to Linux lately, "kernel log" has become a pretty nebulous term. Would "journalctl -k -b -1" suffice? Tell me what would be most helpful to you.

(In reply to Roy A. Gilmore from comment #4)
> (In reply to Ben Skeggs from comment #1)
> > Can you please attach a kernel log, preferably one from after a lockup so I
> > may have some idea of what might have occurred.
> > 
> > Thanks,
> > Ben.
> 
> I'll copy this from comment 2, since apparently I should have replied
> instead of commenting.
> 
> I don't mean to sound stupid, but, with all the fluff that's been added to
> Linux lately, "kernel log" has become a pretty nebulous term. Would
> "journalctl -k -b -1" suffice? Tell me what would be most helpful to you.

That should be fine.

Created attachment 1098253 [details]
output of journalctl -k -b -1

Created attachment 1103346 [details]
Workaround: /etc/modprobe.d/0-local-nouveau-noaccel.conf

After doing some further research I found that apparently this is actually a very old known bug. See this link (among others):

https://fedoraproject.org/wiki/Common_kernel_problems#Systems_with_nVidia_adapters_using_the_nouveau_driver_lock_up_randomly

Workaround:

1. Put the attached file in /etc/modprobe.d
2. Run mkinitrd -f
3. Reboot
4. Success! No more lock ups!

While this workaround appears to work, I'm not aware what the full ramifications of setting noaccel=1. I have a feeling I'm probably missing some feature of the driver by setting this, but, at least it's not locking up. This needs to be fixed.

I have had four freezes since I started using F23 three days ago. I am using the Nouveau driver with F23 because of issues described by the original reporter. At least three of the freezes happened when I used Chrome. See the log below, there is a write fault of the Nouveau driver at 13:19:46, the last time it froze (time displayed by GkrellM). After the freeze I pressed the reset button on my PC (MSI motherboard).


Dec 30 13:16:49 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26175 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:05 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26203 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:05 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26205 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:05 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26206 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:05 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26207 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:05 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26208 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:05 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26209 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:05 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26210 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:07 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26214 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:07 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26215 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:07 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26216 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:07 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26217 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:07 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26218 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:07 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26219 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:07 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26220 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:07 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26221 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:08 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26223 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:08 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26224 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:16 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26228 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:16 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26229 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:19 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26231 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:19 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26230 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:18:59 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26243 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:19:19 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26249 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:19:45 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26257 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:19:45 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26258 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:19:45 tornado audit: SECCOMP auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=26260 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c000003e syscall=273 compat=0 ip=0x7fe20eb605a4 code=0x50000
Dec 30 13:19:46 tornado kernel: nouveau E[   PFIFO][0000:01:00.0] write fault at 0x00002c5000 [PTE] from GR/GPC1/GPCCS on channel 0x023fc20000 [Xorg[812]]
Dec 30 13:19:46 tornado kernel: nouveau E[   PFIFO][0000:01:00.0] PGRAPH engine fault on channel 2, recovering...
Dec 30 13:21:41 tornado journal: Runtime journal is using 8.0M (max allowed 396.8M, trying to leave 595.1M free of 3.8G available → current limit 396.8M).
Dec 30 13:21:41 tornado journal: Runtime journal is using 8.0M (max allowed 396.8M, trying to leave 595.1M free of 3.8G available → current limit 396.8M).
Dec 30 13:21:41 tornado kernel: microcode: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29
Dec 30 13:21:41 tornado kernel: Initializing cgroup subsys cpuset
Dec 30 13:21:41 tornado kernel: Initializing cgroup subsys cpu
Dec 30 13:21:41 tornado kernel: Initializing cgroup subsys cpuacct
Dec 30 13:21:41 tornado kernel: Linux version 4.2.8-300.fc23.x86_64 (mockbuild.fedoraproject.org) (gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) ) #1 SMP Tue Dec 15 16:49:06 UTC 2015
Dec 30 13:21:41 tornado kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.2.8-300.fc23.x86_64 root=/dev/sda5

(In reply to Roy A. Gilmore from comment #7)
> Created attachment 1103346 [details]
> Workaround: /etc/modprobe.d/0-local-nouveau-noaccel.conf
> 
> After doing some further research I found that apparently this is actually a
> very old known bug. See this link (among others):
> 
> https://fedoraproject.org/wiki/
> Common_kernel_problems#Systems_with_nVidia_adapters_using_the_nouveau_driver_
> lock_up_randomly
> 
> Workaround:
> 
> 1. Put the attached file in /etc/modprobe.d
> 2. Run mkinitrd -f
> 3. Reboot
> 4. Success! No more lock ups!
> 
> While this workaround appears to work, I'm not aware what the full
> ramifications of setting noaccel=1. I have a feeling I'm probably missing
> some feature of the driver by setting this, but, at least it's not locking
> up. This needs to be fixed.

Hi Roy,

I am thinking of trying your workaround. With it, does one need to run mkinitrd every time the kernel is updated? And how to revert the change if needed?

(In reply to Piscium from comment #9)
> (In reply to Roy A. Gilmore from comment #7)
> > Created attachment 1103346 [details]
> > Workaround: /etc/modprobe.d/0-local-nouveau-noaccel.conf
> > 
> > After doing some further research I found that apparently this is actually a
> > very old known bug. See this link (among others):
> > 
> > https://fedoraproject.org/wiki/
> > Common_kernel_problems#Systems_with_nVidia_adapters_using_the_nouveau_driver_
> > lock_up_randomly
> > 
> > Workaround:
> > 
> > 1. Put the attached file in /etc/modprobe.d
> > 2. Run mkinitrd -f
> > 3. Reboot
> > 4. Success! No more lock ups!
> > 
> > While this workaround appears to work, I'm not aware what the full
> > ramifications of setting noaccel=1. I have a feeling I'm probably missing
> > some feature of the driver by setting this, but, at least it's not locking
> > up. This needs to be fixed.
> 
> Hi Roy,
> 
> I am thinking of trying your workaround. With it, does one need to run
> mkinitrd every time the kernel is updated? And how to revert the change if
> needed?

Hi Piscium,

No, if the file is placed in /etc/modprobe.d, the kernel-core package has a postinstall scriptlet that (among other things) will indirectly call mkinitrd for you.

If you remove the file /etc/modprobe.d/0-local-nouveau-noaccel.conf, you will need to call mkinitrd or dracut for kernels that have had their initrd/initramfs modified. To try to keep all installed kernels consistent, I use the following commands:

--- 8< --- BEGIN --- 8< ---
for k in $(rpm -q --queryformat="%{VERSION}-%{RELEASE}.%{ARCH}\n" kernel-core | sort) ; do
  /usr/sbin/depmod -e -F /boot/System.map-"$k" -w "$k" ;
  /usr/sbin/restorecon -vRF /lib/modules/"$k" ;
  /usr/bin/mkinitrd -f -v /boot/initramfs-"$k".img "$k" ;
done

/usr/sbin/restorecon -vRF /boot
--- 8< ---  END  --- 8< ---

One thing that I have found when setting noaccel=1, is that when I am not logged in (i.e. at the gdm login screen), the mouse and keyboard are VERY unresponsive, and almost unusable. Once I finally do get logged in, everything appears to work OK. This is not an ideal solution, but, at least the system doesn't lock up. This still really needs to get fixed.

Thanks a lot, Roy.

As a preliminary test I entered nouveau.noaccel=1 in grub, and confirmed it like so:
[root@tornado ~]# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.2.8-300.fc23.x86_64 root=/dev/sda5 nouveau.noaccel=1
[root@tornado ~]# 

I use the kdm login manager and all was normal - I did not experience the unresponsive behaviour you experienced with gdm.

Since the upgrade to F23 I have had either 1 or 2 freezes a day. If I can go one week without a freeze I will be (relatively) happy!

(In reply to Piscium from comment #11)
> Thanks a lot, Roy.
> 
> As a preliminary test I entered nouveau.noaccel=1 in grub, and confirmed it
> like so:
> [root@tornado ~]# cat /proc/cmdline
> BOOT_IMAGE=/boot/vmlinuz-4.2.8-300.fc23.x86_64 root=/dev/sda5
> nouveau.noaccel=1
> [root@tornado ~]# 
> 
> I use the kdm login manager and all was normal - I did not experience the
> unresponsive behaviour you experienced with gdm.
> 
> Since the upgrade to F23 I have had either 1 or 2 freezes a day. If I can go
> one week without a freeze I will be (relatively) happy!

I'm glad this works for somebody. Apparently my combination of hardware and/or software and/or configuration is really stressing the nouveau driver, because before I added noaccel=1, my system was locking up dozens of times a day.

Are you using Gnome? I don't use a full-blown desktop environment, but rather a window manager: openbox.

This may explain why I had less freezes than you.

On top of openbox I run conky on the root window, a few dockapps one of which is GkrellM, and 3 instances of lxpanel.

Now the wait is on for a freeze that I hope will not happen! If it happens I will report it here with log entries as before.

(In reply to Piscium from comment #13)
> Are you using Gnome? I don't use a full-blown desktop environment, but
> rather a window manager: openbox.
> 
> This may explain why I had less freezes than you.
> 
> On top of openbox I run conky on the root window, a few dockapps one of
> which is GkrellM, and 3 instances of lxpanel.
> 
> Now the wait is on for a freeze that I hope will not happen! If it happens I
> will report it here with log entries as before.

Yes, I run GNOME, and I'm sure it contributes to the problem since it is getting more and more bloated with every release. But, I'm also sure the problem is with the nouveau driver, GNOME just exacerbates the problem.

When I COULD run the proprietary nVidia driver, I had no problems. But, Fedora decided to go with a pre-release version of X11 in F23 that changed the API, and made the proprietary nVidia driver incompatible. nVidia released a Beta version that uses the new API. BUT, apparently there has been some other change(s) to the kernel (which I can't seem to track down, and which I have submitted another bug report on) that if I try to blacklist the nouveau driver to prevent it from loading, the kernel hangs early in the boot cycle (even in single user mode), before logging is available. I think it has something to do with kernel mode-setting (KMS) and/or direct rendering manager (DRM). Single user mode should NOT require any video driver, it should gracefully fall back to generic VGA.

Anyway, glad that it is working for somebody, even if it doesn't work for me.

[root@tornado ~]# uptime -p
up 4 days, 9 hours, 1 minute

---

No freeze yet since I entered nouveau.noaccel=1 in grub, so this solved the freeze problem for me. It is not a perfect solution as the card is a tad bit slow, but my graphics card is a gamer's card and I am not a gamer, so even without acceleration it performs adequately for my daily needs. I can live with this workaround until the Nvidia driver becomes available through RPM Fusion as it used to be.

---

@Roy
Now going (very) off topic: 
I used Gnome 2 until Gnome 3 came out, at which time I decided to downgrade to a window manager. Neither bloat nor performance were my main concern, but rather stability and my wish for a slow changing environment when upgrading from a Fedora version to another.

I tried several desktop environments and experienced bugs with all of them. In decreasing order of number of bugs at the time I tested them they were: KDE, Gnome 2, XFCE, LXDE. Window managers, because they are simpler with a smaller number of lines of code, have (supposedly) fewer bugs. I evaluated about 20 window managers and chose Openbox, and I have been using it ever since (at home). It is reasonably stable, and certainly far more stable that KDE, Gnome 2 and XFCE (at the time I tested them). With the way I have Openbox configured, it looks a bit like a fancier version of LXDE (because of lxpanel, conky and dockaps).

(In reply to Piscium from comment #15)
> [root@tornado ~]# uptime -p
> up 4 days, 9 hours, 1 minute
> 
> ---
> 
> No freeze yet since I entered nouveau.noaccel=1 in grub, so this solved the
> freeze problem for me. It is not a perfect solution as the card is a tad bit
> slow, but my graphics card is a gamer's card and I am not a gamer, so even
> without acceleration it performs adequately for my daily needs. I can live
> with this workaround until the Nvidia driver becomes available through RPM
> Fusion as it used to be.
> 
> ---
> 
> @Roy
> Now going (very) off topic: 
> I used Gnome 2 until Gnome 3 came out, at which time I decided to downgrade
> to a window manager. Neither bloat nor performance were my main concern, but
> rather stability and my wish for a slow changing environment when upgrading
> from a Fedora version to another.
> 
> I tried several desktop environments and experienced bugs with all of them.
> In decreasing order of number of bugs at the time I tested them they were:
> KDE, Gnome 2, XFCE, LXDE. Window managers, because they are simpler with a
> smaller number of lines of code, have (supposedly) fewer bugs. I evaluated
> about 20 window managers and chose Openbox, and I have been using it ever
> since (at home). It is reasonably stable, and certainly far more stable that
> KDE, Gnome 2 and XFCE (at the time I tested them). With the way I have
> Openbox configured, it looks a bit like a fancier version of LXDE (because
> of lxpanel, conky and dockaps).

DISCLAIMER: This whole message is going to be off-topic.

Piscium,

A little background about why I was trying to use the nouveau driver. Briefly, my motherboard has a onboard graphics adapter and I have a discrete nVidia PCIe graphics adapter. The UEFI BIOS does not allow me to disable the onboard graphics adapter, but I can select which one is primary. I have the PCIe graphics adapter selected as primary.

Nouveau has always been buggy and 3D acceleration has been questionable at best. VMware always complains about no 3D acceleration when the nouveau driver is used. I used to use the nVidia driver from RPM Fusion, but, they are inconsistent about updating the kmod packages. So I switched to the official package from nVidia. This was a bit problematic, since it leaves files all over the filesystem that RPM knows nothing about and overwrites when upgrading certain other required packages (mesa among others). While it was a lot of work to keep the X11/mesa rpm packages and the nVidia non-rpm packages synced, at least I didn't have to use nouveau.

The nvidia kernel module requires nouveau to be blacklisted. All was fine until a few months ago when either Fedora or somebody upstream made a change which I can't track down (see this kernel bug: https://bugzilla.redhat.com/show_bug.cgi?id=1292305). All of a sudden the kernel started hanging very early in the boot process. While waiting for somebody to help, I poked around a little, and recently discovered that if I also blacklisted the i915 module (the module for the onboard graphics adapter) in addition to the nouveau module, the kernel stopped hanging. I haven't determined why there should be a dependency between the i915 module and the nouveau module.

Anyway, now that I can blacklist the nouveau module without the kernel hanging, using the nVidia driver is again a possibility. I discovered that while RPM Fusion hasn't always been very good about updating the kmod packages to track the released kernels, they have been updating the akmod packages. The upside to using an akmod package is that the akmod package is updated more frequently than the kmod packages. The downside to using an akmod package is that you need to have a development environment installed, not something you normally want to do for most end-user systems. This was not a concern for me, since this is a development system anyway. If you can accept having a development environment installed, the akmod-nvidia package from rpmfusion-nonfree-updates seems to work well.

I have been using open source for over 20 years and mostly I've been happy with it. I prefer to use open source whenever possible, but I'm not a zealot. I know this is considered blasphemy by some, but, in my opinion, both VMware and the nVidia driver are cases where the proprietary closed source solution is vastly superior to the available open source solution.

Another out of topic post!

@Roy

Some people in the Fedora forum (and you in this issue) said that one of the reasons for the problems is/was incompatibilities between the Nvidia driver and X. Fedora 23 was released on 3/November while X v. 1.18 was released six days later. That leaves me wondering: what if Fedora 23 had shipped instead with X v. 1.17? We might have had no problems! Someone made the decision to rush X v. 1.18 in F23 for some reason that I don't know - which may be perfectly valid.

(In reply to Piscium from comment #17)
> Another out of topic post!
> 
> @Roy
> 
> Some people in the Fedora forum (and you in this issue) said that one of the
> reasons for the problems is/was incompatibilities between the Nvidia driver
> and X. Fedora 23 was released on 3/November while X v. 1.18 was released six
> days later. That leaves me wondering: what if Fedora 23 had shipped instead
> with X v. 1.17? We might have had no problems! Someone made the decision to
> rush X v. 1.18 in F23 for some reason that I don't know - which may be
> perfectly valid.

DISCLAIMER: This whole message is going to be off-topic (again).

Piscium,

I should have placed this in my last message, but, nVidia 358.16 (released on 2015.11.20) has added support for Xorg 1.18. I didn't try it for quite a while because I was also fighting the other more serious kernel hanging bug. But, the nVidia 358.16 proprietary driver should be compatible with F23.

The 1.17 vs. 1.18 issue is an ongoing software issue that affects other components as well. On the one hand, releasing a distribution with pre-release components can break third-party repositories/software. On the other hand, they do warn us to use third-party repositories/software at our own risk. It's an issue that I'm well aware of, and I still use third party repositories/software anyway, so I try not to complain too loudly when things break.

I imagine the decision to use 1.18 had to do with knowing that 1.18 was going to be released soon, and, it would be much easier to replace a pre-release version of software with the final release version, than to recompile all the software that depended on the older ABI.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.