X Server freezes when Switch User and DPMS on GeForce 1650

I renamed the nvidia-bug-report.log.gz file adding .log to end because upload said I wasn’t authorized for .gz extension.
nvidia-bug-report.log.gz.log (324.1 KB)

This is a fairly fresh install of Ubuntu Studio 20.04 with stock lightdm/xfce. I also have the same issue on fresh installs of Ubuntu Studio 19.04 + 19.10, Ubuntu 19.10, Kubuntu 19.10 + 20.04. I think I might have tried Ubuntu Studio 18.04 and did not have this issue. I can install it again if it is helpful.

Video card: EVGA GeForce GTX 1650 XC Ultra 04G-P4-1157-KR

Sequence of events to consistently replicate issue:

Login User1, click Switch User, login User2, let PC go to sleep due to inactivity (approx 17:20), move mouse at 17:52 to wakeup PC, entered password for User2, clicked Switch User, changed to User1 and entered password, PC freezed for 28 seconds (freezing ended at 17:53), LightDM greeter asked for password again (this window is in different location than first time I entered password) and clicked unlock, ran nvidia-bug-report.sh after desktop finished loading.

Note that if I keep moving mouse so the PC never goes to sleep, then I would have never had the 28 second freeze. Also, the amount of time the PC freezes is directly proportional to how long the PC was asleep (not blank screen, but asleep/DPMS). I know because a month ago I timed it and it was very consistent in Excel. Also, the second window where lightdm greeter asked for password of User2 (right after freeze) only started getting in the last week or two. Before I just got the desktop after the freezing stopped. Also right now the mouse pointer is frozen when the PC freezes, but before recently the mouse pointer was just very laggy during the freezing issue. I know the PC isn’t actually frozen since I sometimes see messages in the logs during the freezes, but during freezes only numlock works on keyboard (can’t even ctrl-alt-F1 thru F8, the TTY doesn’t show until after the freezing times out).

Last time I checked I can also cause the freeze by signing into User1, click Switch User and the freeze when logging back in will again be directly proportional to how long the PC is asleep/DPMS. There will NOT be a freeze if I clicked “lock” instead of “switch user”.

Today I tried swapping my Nvidia card for a very old Radeon 6450 card and did not have any freezing issues, so I’m pretty sure the issue is with the nvidia drivers, which I’m using v440 now, but on Ubuntu Studio 19.10 I also tried 430 and 435 with no difference. Please help me resolve this issue as the performance of this GeForce 1650 should be better than the 10 year old Radeon card. I do have an extra partition that I can install any version of Linux to use for testing. I would prefer lightdm/xfce because I am more familiar with it. I have been having this problem since I got this GeForce 1650 in January.

$ inxi -G
Graphics: Device-1: NVIDIA TU117 [GeForce GTX 1650] driver: nvidia v: 440.64
Display: x11 server: X.Org 1.20.8 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa
resolution: 1920x1080~60Hz
OpenGL: renderer: GeForce GTX 1650/PCIe/SSE2 v: 4.6.0 NVIDIA 440.64

$ xrandr
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
DP-0 disconnected primary (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
HDMI-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm
1920x1080 60.00*+ 59.94 50.00
1680x1050 59.95
1440x900 59.89
1440x576 50.00
1440x480 59.94
1280x1024 75.02 60.02
1280x960 60.00
1280x800 59.81
1280x720 60.00 59.94 50.00
1152x864 75.00
1024x768 75.03 70.07 60.00
800x600 75.00 72.19 60.32 56.25
720x576 50.00
720x480 59.94
640x480 75.00 59.94 59.93

I’m wondering if the problem is that xrandr shows the video is using HDMI-0, but the Xorg.0.log has these lines mentioning DFP-4 repeating over 800 times:
[ 3991.836] (–) NVIDIA(GPU-0): Ancor Communications Inc ASUS VS247 (DFP-4): connected
[ 3991.836] (–) NVIDIA(GPU-0): Ancor Communications Inc ASUS VS247 (DFP-4): Internal TMDS
[ 3991.836] (–) NVIDIA(GPU-0): Ancor Communications Inc ASUS VS247 (DFP-4): 600.0 MHz maximum pixel clock

I just tested and doing “switch user” with DPMS/sleep is still enough to cause the freeze/delay (log attached). Here is what I did to get this log:

  1. At 20:10 clicked “switch user”
  2. At 20:20 DPMS kicked in and monitor entered sleep modesetting
  3. At 20:40:32 I moved mouse to wakup PC, then entered password and clicked unlock
  4. PC froze for approx 20 seconds
  5. At 20:40:55 lightdm greeter asked for password again, I entered password, clicked unlock and desktop displayed immediately

Let me know if you want the log for when I do the same thing except move the mouse so that monitor doesn’t go to sleep (I do NOT get the freeze/delay then).
nvidia-bug-report2.log.gz.log (378.2 KB)

Unfortunately, there’s nothing really noticeable in the log except for something is always requerying the monitor when the freeze happens.
Maybe something to test:

  • use kernel parameter nvidia-drm.modeset=1
  • disable compositing on xfwm

Thanks for getting back to me so quickly! I tried both of those today and they didn’t help. I also tried nomodeset without success.

I did find that adding:
Option “DPMS” “false”
To the Monitor section of xorg.conf made the problem go away on Ubuntu Studio (lightdm/xfce), but didn’t help on kubuntu (sddm/plasma). I will keep this setting on xfce as the monitor still goes blank, but just not going into power saving mode.

Is there any way to determine what the nvidia driver doesn’t like about dpms? If the issue is with Ubuntu then why isn’t the Radeon card having the same issue?

You could try to play with the option
Option "HardDPMS" "boolean"
Maybe the driver doesn’t like how the monitor reacts to dpms actions. Not really debuggable, though. Try-and-error.

That sounds interesting, but neither true nor false made any difference. I’m not sure what else to try.