** Description changed:

+ [Impact]
+ 
+  * In Ubuntu 20.04 (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/u/count)"
+ count=$((count+1))
+ echo $count | tee /home/u/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 90 reboot cycles.
+ 
+ [Where problems could occur]
+  * The patch checkes device/boot_vga with tag "master-of-seat". If a system 
without any GPU as boot_vga then it will fall in infinite loop.
+  * I tried to detach all monitors from the system and the boot_vga still 
exist (default to use iGPU, the first device found during initialization)
+  * I don't think they will a case which boot_vga doesn't exist in this moment 
because:
+ In drivers/gpu/vga/vgaarb.c (linux package)
+ vga_arb_select_default_device() has a fallback function to determine the 
boot_vga device to prevent firmware doesn't pass correct efifb to linux-kernel.
+ 
+ ---
+ 
  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.
+ 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.
  
  [1] https://www.freedesktop.org/wiki/Software/systemd/multiseat/
  /lib/udev/rules.d/71-seat.rules
  /lib/udev/rules.d/71-nvidia.rules

** Description changed:

  [Impact]
  
-  * In Ubuntu 20.04 (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.
+  * In Ubuntu 20.04 (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
+  * 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/u/count)"
  count=$((count+1))
  echo $count | tee /home/u/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 90 reboot cycles.
+  * 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 90 reboot cycles.
  
  [Where problems could occur]
-  * The patch checkes device/boot_vga with tag "master-of-seat". If a system 
without any GPU as boot_vga then it will fall in infinite loop.
-  * I tried to detach all monitors from the system and the boot_vga still 
exist (default to use iGPU, the first device found during initialization)
-  * I don't think they will a case which boot_vga doesn't exist in this moment 
because:
+  * The patch checkes device/boot_vga with tag "master-of-seat". If a system 
without any GPU as boot_vga then it will wait 10 seconds in the loop.
+  * I tried to detach all monitors from the system and the boot_vga still 
exist (default to use iGPU, the first device found during initialization)
+  * I don't think they will a case which boot_vga doesn't exist in this moment 
because:
  In drivers/gpu/vga/vgaarb.c (linux package)
  vga_arb_select_default_device() has a fallback function to determine the 
boot_vga device to prevent firmware doesn't pass correct efifb to linux-kernel.
  
  ---
  
  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.
  
  [1] https://www.freedesktop.org/wiki/Software/systemd/multiseat/
  /lib/udev/rules.d/71-seat.rules
  /lib/udev/rules.d/71-nvidia.rules

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1958488

Title:
  [nvidia][xorg] display hangs on boot LOGO

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


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to