I have been running nvidia 440.100 since ~6 Jul 2020 with no issues. This week an issue started where the display hangs completely, mouse does not move, and no elements update.
top shows nv_queue running at 100% before or just after display freeze.
While in the problem state, the system runs normal for about ~30-40 secs, the freeze occurs ~10 secs, unfreezes for 1 sec or 2, freeze for another 10 secs, and cycle repeats.
On 11 Aug 2020, I upgraded to 450.57, and have had the problem happen again twice. The long freeze has reduced to ~8 secs instead of 10 while in the problem state. I logged out to start a new X session, but the nvidia X session is still active and will not exit.
reboot does not work and I have to power off and reboot to login again.
Once on 440.100 and once on 450.57 the problem stopped occurring on its own.
I suspect some user operation is causing an issue in the driver.
I will try to associate a specific action with the start of the issue.
Reviewing the logs I did not find an NVRM messages from the time of the issue, or any other time. The only kernel messages are from the mouse complaining about lost mouse events during the issue.
In an attempt to capture more information, I will stop gdm and use startx to capture more logs.
This issue is caused by playing a video from youtube in a web browser. It’s not yet clear if other locations other than youtube affect this. The problem starts once video has started playing and occurs whether the video is paused or is playing.
The system hasn’t stopped pausing since closing the web page.
I know this is an old thread, but hope this helps someone else.
I was having the same issue with a HP Zbook 15 w/ Quadro P1000 running Fedora 31 and Nvidia 450.66. System would experience 8-10 second freeze and I would see nv_queue shoot to the top of the process list for a very short time. It all started with a 5.7.x kernel update from Fedora. I tried multiple 5.7 kernels and 450.xx nvidia driver versions and all behaved the same way.
FWIW - Only two workarounds I found that worked for me:
go back to a 5.5 kernel
With 5.7 kernel: limiting CPU from dropping into idle states:
adding kernel parameter in /etc/sysconfig/grub: "GRUB_CMDLINE_LINUX_DEFAULT=“intel_idle.max_cstate=1”
I’m having this issue on Fedora 32 (5.8.15-201.fc32.x86_64) on a Lenovo X1 Extreme laptop. It’s only been happening a few days since a DNF update, which included a new NVIDIA driver on October 16. No issue when using the laptop display, but when plugged in to my Lenovo dock with 2 x 27’’ monitors, I have regular freezes with 100% CPU on both the Xorg and nvidia_queue processes.
Would be great if anyone else has any ideas on workarounds…
I have a similar setup, different laptop, also with dual external monitors. I thought I had found the answer that I had posted earlier in this thread, but it’s started happening again. I will get a 7-15 second freeze and while watching top output I will get a glimpse of nv_queue having gone 100% CPU for that period of time. It cycles back and forth to the top of the list.
The closest I can isolate to in my case is that Firefox causes this interaction to start happening. I had one day where it kept happening repeatedly once I rebooted and got around to starting Firefox and navigating news sites.
I got so fed up I imported all my settings and switched completely to Chrome and so far have not had a single occurrence. Coincidence? It’s working for me so far…
I tried your workaround in the Grub config. It seemed to work for like half a day and then the 100% CPU and freezing started again. I’m using Chrome with 455.28 NVIDIA drivers, monitors connected via the docking station and DisplayPort.
I wonder if there is a trigger, as it’s working fine at the moment. I think watching video in the browser could well be the trigger, as I do a fair bit of that.
The other thing I’ve noticed is pulling the dock (power and thunderbolt) connector out of the laptop to change rooms causes the CPU to hit 100% and black screen. In fact, any major change to the displays like pulling one DP out of the back of the dock causes the same issue. Has to be some kind of driver issue.