This bug was fixed in the package nvidia-graphics-drivers-470 -
470.86-0ubuntu1
---------------
nvidia-graphics-drivers-470 (470.86-0ubuntu1) jammy; urgency=medium
* New upstream release (LP: #1950665):
- Fixed a regression which prevented DisplayPort and HDMI 2.1
variable refresh rate (VRR) G-SYNC Compatible monitors from
functioning correctly in variable refresh rate mode, resulting
in issues such as flickering.
-- Alberto Milone <alberto.mil...@canonical.com> Thu, 11 Nov 2021
16:47:27 +0100
** Changed in: nvidia-graphics-drivers-470 (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to nvidia-graphics-drivers-470 in Ubuntu.
https://bugs.launchpad.net/bugs/1949026
Title:
System hangs on purple screen
Status in OEM Priority Project:
Fix Released
Status in nvidia-graphics-drivers-470 package in Ubuntu:
Fix Released
Status in nvidia-graphics-drivers-470 source package in Bionic:
Fix Released
Status in nvidia-graphics-drivers-470 source package in Focal:
Fix Released
Status in nvidia-graphics-drivers-470 source package in Hirsute:
Fix Released
Status in nvidia-graphics-drivers-470 source package in Impish:
Fix Released
Bug description:
[Impact]
* In some race condition, the GDM starts before gdm-udev rule be applied.
* That's because somehow the nvidia driver takes more times to do the
runtime resume. Thus, apply the workaround to postpone to enable RTD3.
[Test Plan]
1. In problematic machine, warn/cold boot the system.
2.1 System hangs on GDM login shell
2.2 After apply this patch, the system can enter the login screen.
[Where problems could occur]
* Postpone to enable RTD3 when binding driver should not impact the
functionality since the power consumption usually not be consider in
booting stage.
---
We are facing an issue that GDM starts with Wayland instead of Xorg,
despite of 61-gdm.rules' gdm-disable-wayland for NVIDIA graphics.
The issue happens because gdm-disable-wayland is executed after GDM has
started. The reason why the udev rules takes so long is because the the
runtime suspended NVIDIA GFX takes more than 1 second to runtime resume,
hence the driver starts the probing routine rather late.
The proper solution is to impose a barrier like
systemd-udev-settle.service before GDM, but limits to the GFX device
only to avoid waiting for all udev rules are finished.
Since such mechanism isn't available right now, workaround the issue by
enabling runtime PM after driver is bound to avoid the runtime resume
delay, and hope GDM always starts after the probing is done.
Please backport below patch to supported nvidia-drivers:
https://github.com/tseliot/nvidia-graphics-drivers/pull/41/commits/7e9e4d4a827dc9da0e27058871034245ae4b7508
To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1949026/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
