[Desktop-packages] [Bug 1973604] Re: [nvidia340] display hangs 10s on boot with nvidia-340
Hi jeremyszu, your update proposal works like a charm ! Boot time is back to normal (no more 10s delay stuck with gpu-manager.service/plymouth-quit-wait.service) /var/log/gpu-manager.log exhibits Has the system changed? No can't access /run/u-d-c-nvidia-drm-was-loaded file Takes 0ms to wait for nvidia udev rules completed. instead of many "can't access /run/u-d-c-nvidia-drm-was-loaded file" lines and Takes 1ms to wait for nvidia udev rules completed. Sounds VALID for me ! -- 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/1973604 Title: [nvidia340] display hangs 10s on boot with nvidia-340 Status in nvidia-graphics-drivers-340 package in Ubuntu: New Status in ubuntu-drivers-common package in Ubuntu: New Bug description: Since ubuntu-drivers-common 1:0.9.0~0.20.04.6, system running kernel 5.4 & nvidia-340 will experience 10s useless delay on boot because gpu-manager is waiting for nvidia-drm to load & nvidia-drm is not built in with nvidia-340. Several legacy nvidia cards are stuck to nvidia-340 & Kernel 5.4 as detailled in: https://nvidia.custhelp.com/app/answers/detail/a_id/3142/%7E/support-timeframes-for-unix-legacy-gpu-releases See prior investigation in comments of https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1958488 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-340/+bug/1973604/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1973604] Re: [nvidia340] display hangs 10s on boot with nvidia-340
** Package changed: gdm3 (Ubuntu) => ubuntu-drivers-common (Ubuntu) -- 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/1973604 Title: [nvidia340] display hangs 10s on boot with nvidia-340 Status in ubuntu-drivers-common package in Ubuntu: New Bug description: Since ubuntu-drivers-common 1:0.9.0~0.20.04.6, system running kernel 5.4 & nvidia-340 will experience 10s useless delay on boot because gpu-manager is waiting for nvidia-drm to load & nvidia-drm is not built in with nvidia-340. Several legacy nvidia cards are stuck to nvidia-340 & Kernel 5.4 as detailled in: https://nvidia.custhelp.com/app/answers/detail/a_id/3142/%7E/support-timeframes-for-unix-legacy-gpu-releases See prior investigation in comments of https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1958488 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1973604/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1958488] Re: [nvidia][xorg] display hangs on boot LOGO due to race of gdm and nvidia driver probe
Thanks, just opened a separate bug:
[nvidia340] display hangs 10s on boot with nvidia-340
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1973604
--
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:
Fix Released
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:
Triaged
Status in ubuntu-drivers-common source package in Focal:
Fix Released
Status in gdm3 source package in Impish:
Triaged
Status in ubuntu-drivers-common source package in Impish:
Fix Released
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.freedes
[Desktop-packages] [Bug 1973604] [NEW] [nvidia340] display hangs 10s on boot with nvidia-340
Public bug reported: Since ubuntu-drivers-common 1:0.9.0~0.20.04.6, system running kernel 5.4 & nvidia-340 will experience 10s useless delay on boot because gpu-manager is waiting for nvidia-drm to load & nvidia-drm is not built in with nvidia-340. Several legacy nvidia cards are stuck to nvidia-340 & Kernel 5.4 as detailled in: https://nvidia.custhelp.com/app/answers/detail/a_id/3142/%7E/support-timeframes-for-unix-legacy-gpu-releases See prior investigation in comments of https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1958488 ** Affects: gdm3 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gdm3 in Ubuntu. https://bugs.launchpad.net/bugs/1973604 Title: [nvidia340] display hangs 10s on boot with nvidia-340 Status in gdm3 package in Ubuntu: New Bug description: Since ubuntu-drivers-common 1:0.9.0~0.20.04.6, system running kernel 5.4 & nvidia-340 will experience 10s useless delay on boot because gpu-manager is waiting for nvidia-drm to load & nvidia-drm is not built in with nvidia-340. Several legacy nvidia cards are stuck to nvidia-340 & Kernel 5.4 as detailled in: https://nvidia.custhelp.com/app/answers/detail/a_id/3142/%7E/support-timeframes-for-unix-legacy-gpu-releases See prior investigation in comments of https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1958488 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1973604/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1958488] Re: [nvidia][xorg] display hangs on boot LOGO due to race of gdm and nvidia driver probe
Thanks for investigating !
below is what you requested ...
1.dkms status
nvidia-340, 340.108, 5.4.0-109-generic, x86_64: installed
nvidia-340, 340.108, 5.4.0-110-generic, x86_64: installed
virtualbox, 6.1.32, 5.4.0-109-generic, x86_64: installed
virtualbox, 6.1.32, 5.4.0-110-generic, x86_64: installed
2.find /lib/modules/$(uname -r) -name 'nvidia*'
/lib/modules/5.4.0-110-generic/kernel/drivers/char/drm/nvidia.ko
/lib/modules/5.4.0-110-generic/kernel/drivers/net/ethernet/nvidia
/lib/modules/5.4.0-110-generic/kernel/drivers/video/fbdev/nvidia
/lib/modules/5.4.0-110-generic/kernel/drivers/video/fbdev/nvidia/nvidiafb.ko
/lib/modules/5.4.0-110-generic/kernel/drivers/video/nvidia_uvm.ko
3.Found /var/lib/dkms/nvidia-340/340.108/5.4.0-110-generic/x86_64/log/make.log
(also reachable from symlink
/var/lib/dkms/nvidia-340/kernel-5.4.0-110-generic-x86_64)
> see attachement
** Attachment added: "dkms nvidia make log"
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1958488/+attachment/5589640/+files/make.log
--
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:
Fix Released
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:
Triaged
Status in ubuntu-drivers-common source package in Focal:
Fix Released
Status in gdm3 source package in Impish:
Triaged
Status in ubuntu-drivers-common source package in Impish:
Fix Released
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
[Desktop-packages] [Bug 1958488] Re: [nvidia][xorg] display hangs on boot LOGO due to race of gdm and nvidia driver probe
modinfo nvidia-drm modinfo: ERROR: Module nvidia-drm not found. modinfo nvidia_drm modinfo: ERROR: Module nvidia_drm not found. modinfo nvidia filename: /lib/modules/5.4.0-110-generic/kernel/drivers/char/drm/nvidia.ko inxi -G Graphics: Device-1: NVIDIA GT218 [GeForce 210] driver: nvidia v: 340.108 Display: x11 server: X.Org 1.20.13 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa resolution: 1600x900~60Hz OpenGL: renderer: GeForce 210/PCIe/SSE2 v: 3.3.0 NVIDIA 340.108 https://www.nvidia.fr/Download/find.aspx?lang=fr shows Linux x64 (AMD64/EM64T) Display Driver Recommandé par NVIDIA340.108 23.12.2019 * Updated the nvidia-drm kernel module for compatibility with the removal of the DRIVER_PRIME flag in recent Linux kernel versions. lsmod | grep nvidia Module Size Used by nvidia_uvm 36864 0 nvidia 10588160 50 nvidia_uvm drm 491520 3 nvidia modinfo drm filename: /lib/modules/5.4.0-110-generic/kernel/drivers/gpu/drm/drm.ko author: Thierry Reding name: drm vermagic: 5.4.0-110-generic SMP mod_unload modversions Could that just mean that 'nvidia_drm' we are seeking was just named 'drm' in 3.40 ?? -- 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: Fix Released 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: Triaged Status in ubuntu-drivers-common source package in Focal: Fix Released Status in gdm3 source package in Impish: Triaged Status in ubuntu-drivers-common source package in Impish: Fix Released 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
[Desktop-packages] [Bug 1958488] Re: [nvidia][xorg] display hangs on boot LOGO due to race of gdm and nvidia driver probe
Hi,
I do not remember blacklisting nvidia-drm intentionally, but will check !
Anyway don't you think this line from journalctl:
kernel: [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on minor 0
indicates nvidia-drm is fine ?
Running Mint 20.3 still with kernel 5.4 if that matters ...
seems also Nvidia driver version 340 is the last to support my GeForce 210
based card ...
https://nvidia.custhelp.com/app/answers/detail/a_id/3142/%7E/support-timeframes-for-unix-legacy-gpu-releases
Yes it's old ... not only the GPU ..., but still fairly usable ;-)
--
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:
Fix Released
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:
Triaged
Status in ubuntu-drivers-common source package in Focal:
Fix Released
Status in gdm3 source package in Impish:
Triaged
Status in ubuntu-drivers-common source package in Impish:
Fix Released
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
[Desktop-packages] [Bug 1958488] Re: [nvidia][xorg] display hangs on boot LOGO due to race of gdm and nvidia driver probe
Hi, did it reverting to ubuntu-drivers-common 1:0.8.1 (focal) > XXX_before.txt logs in ZIP accountname@hostname:~$ systemd-analyze time Startup finished in 5.469s (kernel) + 5.395s (userspace) = 10.864s graphical.target reached after 4.814s in userspace accountname@hostname:~$ systemd-analyze blame 2.343s dev-sda3.device 2.285s man-db.service ... & updating to: ubuntu-drivers-common 1:0.9.0~0.20.04.7 (focal-updates) accountname@hostname:~$ systemd-analyze time Startup finished in 5.557s (kernel) + 14.014s (userspace) = 19.572s graphical.target reached after 13.983s in userspace accountname@hostname:~$ systemd-analyze blame 10.488s gpu-manager.service 10.142s plymouth-quit-wait.service 2.704s dev-sda3.device ... Hope it helps ! ** Attachment added: "requested log" https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1958488/+attachment/5588604/+files/logs.zip -- 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: Fix Released 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: Triaged Status in ubuntu-drivers-common source package in Focal: Fix Released Status in gdm3 source package in Impish: Triaged Status in ubuntu-drivers-common source package in Impish: Fix Released 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 Hi17
[Desktop-packages] [Bug 1958488] Re: [nvidia][xorg] display hangs on boot LOGO due to race of gdm and nvidia driver probe
Hi,
seems that the change from 1:0.9.0~0.20.04.5 to 1:0.9.0~0.20.04.6
did introduce for me a 10s extra delay at each startup,
despite the fact that it's a desktop with only one (pretty old) Nvidia discrete
graphic card.
systemd-analyze blame
10.403s gpu-manager.service
9.927s plymouth-quit-wait.service
2.641s dev-sda3.device
While investigating, I found in
/var/log/gpu-manager.log
can't access /run/u-d-c-nvidia-drm-was-loaded file
...
can't access /run/u-d-c-nvidia-drm-was-loaded file
Takes 1ms to wait for nvidia udev rules completed.
Single card detected
which lead me here ...
Has anyone an idea to workaround this ?
Thanks
--
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:
Fix Released
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:
Triaged
Status in ubuntu-drivers-common source package in Focal:
Fix Released
Status in gdm3 source package in Impish:
Triaged
Status in ubuntu-drivers-common source package in Impish:
Fix Released
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 gd
