This bug was fixed in the package gdm3 - 42.0-1ubuntu1

---------------
gdm3 (42.0-1ubuntu1) jammy; urgency=medium

  * Merge with debian, remaining changes:
    + readme.debian: update for correct paths in ubuntu
    + control.in:
      - don't recommend desktop-base
      - depend on bash for config_error_dialog.patch
      - update vcs field
    + rules:
      - don't override default user/group
      - -dgdm-xsession=true to install upstream xsession script
      - override dh_installinit with --no-start to avoid session being killed
    + rules, readme.debian, gdm3.8.pod:
      use upstream custom.conf instead of daemon.conf
    + gdm3.{postinst,postrm}: rename user and group back to gdm
    + gdm3.*.pam: make pam_env read ~/.pam_environment, as we use in g-c-c
      settings
    + gdm3.install:
      - don't install debian/xsession
    + add run_xsession.d.patch
    + add xresources_is_a_dir.patch
      - fix loading from /etc/x11/xresources/*
    + add nvidia_prime.patch:
      - add hook to run prime-offload (as root) and prime-switch if
        nvidia-prime is installed
    + add revert_override_lang_with_accountservices.patch:
      - on ubuntu accountservices only stores the language and not the
        full locale as needed by lang.
    + add dont_set_language_env.patch:
      - don't run the set_up_session_language() function, since it
        overrides variable values set by ~/.pam_environment
    + add config_error_dialog.patch:
      - show warning dialog in case of error in ~/.profile etc. and
        don't let a syntax error make the login fail
    + add debian/patches/revert_nvidia_wayland_blacklist.patch:
      - don't blacklist nvidia for wayland
    + add gdm3.service-wait-for-drm-device-before-trying-to-start-i.patch:
      - wait for the first valid gdm device on pre-start
    + add debian/default.pa
      - disable bluetooth audio devices in pulseaudio from gdm3.
    + debian/gdm3.install
      - added details of the default.pa file
    + debian/gdm3.postinst
      - added installation of default.pa and creation of dir if it doesn't
        exist.
    + debian/greeter.dconf-defaults: don't set debian settings in the
      greeter's dconf db

gdm3 (42.0-1) unstable; urgency=medium

  [ Jeremy Bicha ]
  * New upstream release
    - Fix hang caused by GDM starting sooner than nvidia_drm
      (Closes: #1004131, LP: #1958488)
    - Default to Wayland for nvidia 510 drivers (LP: #1962523)
  * debian/control.in: Build-Depend on libgudev-1.0-dev

  [ Simon McVittie ]
  * Add a NEWS.Debian entry for the removal of "System X11 Default"

 -- Jeremy Bicha <[email protected]>  Tue, 22 Mar 2022 16:59:12 -0400

** Changed in: gdm3 (Ubuntu)
       Status: Incomplete => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ubuntu-drivers-common in Ubuntu.
https://bugs.launchpad.net/bugs/1958488

Title:
  [nvidia][xorg] display hangs on boot LOGO due to race of gdm and
  nvidia driver probe

Status in OEM Priority Project:
  Confirmed
Status in gdm3 package in Ubuntu:
  Fix Released
Status in ubuntu-drivers-common package in Ubuntu:
  Fix Released
Status in gdm3 source package in Focal:
  Incomplete
Status in ubuntu-drivers-common source package in Focal:
  Fix Committed
Status in gdm3 source package in Impish:
  Incomplete
Status in ubuntu-drivers-common source package in Impish:
  Fix Committed

Bug description:
  [Impact]

   * In Ubuntu 20.04 (either impish, jammy, upstream gdm) (which using Xorg 
with proprietary nvidia driver), in some cases, the nvidia driver will probe 
later than launching gdm.
   * If above race condition happens in iGPU + nvidia cases and monitor 
connects to dGPU, which will cause gdm starts with wayland as opposed to Xorg. 
Which may lead the monitor stuck in black-screen or boot LOGO.

  [Test Plan]

   * The environment:
    1. A desktop or workstation which containing an iGPU.
    2. Plug a nvidia graphic card to the system and installing proprietary
    nvidia driver (470 in my case)
    3. Attach a monitor to dGPU and leave iGPU connect to nothing.
    (in my test environment, there is the other ethernet card and TBT4 cards)
   * Setup a cronjob,
     e.g. @reboot /home/u/test.sh
   * Have a test script in something like /home/u/test.sh as

  #!/bin/bash

  sleep 20
  count="$(cat /home/ubuntu/count)"
  count=$((count+1))
  echo $count | tee /home/ubuntu/count
  journalctl -b | grep -q -i wayland || sudo reboot

   * the system will probably stuck in black-screen or boot LOGO.
   * Before applying the fix, the fail rate is 6/24 (fail 6 time in 24 runs).
   * After applying the fix, it got pass within 1000+ reboot cycles.
   * Test PPA can be found here 
https://launchpad.net/~os369510/+archive/ubuntu/lp1958488

  [Fix]
   * The patch makes gpu-manager to probe nvidia (if needed) first and waiting 
for the /run/u-d-c-nvidia-drm-was-loaded be touched by 
71-u-d-c-gpu-detection.rules.
   * Also, the gdm is using 61-gdm.rules to configure the gdm mode by checking 
the nvidia driver presents or not.
   * gpu-manager is before display-manager. Thus, gpu-manager will wait for 
nvidia uevent be processed and then continue to work. When gdm be launched, the 
targeted nvidia uevent has been processed already. 
(71-u-d-c-gpu-detection.rules is later than 61-gdm.rules)

  [Where problems could occur]
   * there is not potential regression from my mind but it will lead the boot 
time be longer.
   * In my test cycles, it leads extra 0~1000ms in boot time. Usually, 0~200ms. 
Worst case, over 1 s in 8xx runs (of 1000).
   * I think the stability is important than performance in this case.

  [Other Info]
   * For non-ubuntu-desktop (which doesn't have gpu-manager), which using gdm 
will meet this issue still. The other potential fix (from either gdm or logind) 
is under discussion in 
https://gitlab.gnome.org/GNOME/gdm/-/issues/763#note_1385786.
   * u-d-c upstream fix: 
https://github.com/tseliot/ubuntu-drivers-common/pull/67

  ---

  Test environment/steps:
  1. A desktop or workstation which containing an iGPU.
  2. Plug a nvidia graphic card to the system and installing proprietary nvidia 
driver (470 in my case)
  3. Attach a monitor to dGPU and leave iGPU connect to nothing.
  (in my test environment, there is the other ethernet card and TBT4 cards)
  4. Reboot system.

  Based on:
  $ cat /lib/udev/rules.d/61-gdm.rules
  # disable Wayland on Hi1710 chipsets
  ATTR{vendor}=="0x19e5", ATTR{device}=="0x1711", 
RUN+="/usr/lib/gdm3/gdm-disable-wayland"
  # disable Wayland when using the proprietary nvidia driver
  DRIVER=="nvidia", RUN+="/usr/lib/gdm3/gdm-disable-wayland"

  It will disable wayland by default if proprietary nvidia driver load.
  But in some race condition cases, the nvidia probe is later than gnome 
launches. (The fail rate is 6/24.)
  Thus, ubuntu-gdm has a fix for Bug#1794280 to add 
"ExecStartPre=@libexecdir@/gdm-wait-for-drm".

  The gdm-wait-for-drm is intend to make sure all drm udev devices
  enumerated before launching gdm.

  It rely on at least one "master-of-seat" graphic card for gdm but it's not 
rigorous enough.
  Since most of graphic cards are own "master-of-seat"[1].

  In my case, it detects the iGPU is probed but dGPU.
  However, the display is attached to dGPU.

  We need to make sure the targeted gpu (connecting to monitor) is probe
  before launching gdm.

  debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004131
  upstream bug: https://gitlab.gnome.org/GNOME/gdm/-/issues/763

  [1] https://www.freedesktop.org/wiki/Software/systemd/multiseat/
  /lib/udev/rules.d/71-seat.rules
  /lib/udev/rules.d/71-nvidia.rules

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1958488/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to