| 2022-01-20 05:48:56 |
jeremyszu |
bug |
|
|
added bug |
| 2022-01-20 05:49:02 |
jeremyszu |
gdm3 (Ubuntu): assignee |
|
jeremyszu (os369510) |
|
| 2022-01-20 05:53:43 |
jeremyszu |
description |
Test 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)
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.
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 |
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 |
|
| 2022-01-20 06:07:59 |
jeremyszu |
attachment added |
|
lp1958488_gdm-wait-for-drm_wait_for_boot_vga.debdiff https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1958488/+attachment/5555742/+files/lp1958488_gdm-wait-for-drm_wait_for_boot_vga.debdiff |
|
| 2022-01-20 06:08:51 |
jeremyszu |
bug |
|
|
added subscriber OEM Solutions Group: Engineers |
| 2022-01-20 06:08:55 |
jeremyszu |
tags |
|
oem-priority originate-from-1956556 sutton |
|
| 2022-01-20 06:10:33 |
jeremyszu |
oem-priority: assignee |
|
jeremyszu (os369510) |
|
| 2022-01-20 06:10:35 |
jeremyszu |
oem-priority: importance |
Undecided |
Critical |
|
| 2022-01-20 06:10:37 |
jeremyszu |
oem-priority: status |
New |
In Progress |
|
| 2022-01-20 06:24:08 |
Daniel van Vugt |
bug |
|
|
added subscriber Daniel van Vugt |
| 2022-01-20 06:33:46 |
Kai-Heng Feng |
bug |
|
|
added subscriber Kai-Heng Feng |
| 2022-01-20 06:35:08 |
jeremyszu |
description |
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 |
[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.
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 |
|
| 2022-01-20 06:38:56 |
jeremyszu |
description |
[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.
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 |
[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 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 |
|
| 2022-01-20 08:22:58 |
Ubuntu Foundations Team Bug Bot |
tags |
oem-priority originate-from-1956556 sutton |
oem-priority originate-from-1956556 patch sutton |
|
| 2022-01-20 08:23:06 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2022-01-20 15:42:12 |
jeremyszu |
description |
[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 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 |
[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/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 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 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 |
|
| 2022-01-21 16:27:18 |
jeremyszu |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004131 |
|
| 2022-01-24 08:38:42 |
jeremyszu |
description |
[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/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 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 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 |
[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/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 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 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.
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 |
|
| 2022-01-28 04:57:58 |
jeremyszu |
oem-priority: status |
In Progress |
Confirmed |
|
| 2022-02-21 15:20:26 |
jeremyszu |
bug task added |
|
ubuntu-drivers-common (Ubuntu) |
|
| 2022-02-21 15:20:33 |
jeremyszu |
ubuntu-drivers-common (Ubuntu): assignee |
|
jeremyszu (os369510) |
|
| 2022-02-22 14:39:03 |
jeremyszu |
attachment added |
|
0001-Make-sure-nvidia-drm-rules-action-processed.jammy.patch https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1958488/+attachment/5562733/+files/0001-Make-sure-nvidia-drm-rules-action-processed.jammy.patch |
|
| 2022-02-22 14:47:05 |
jeremyszu |
attachment added |
|
0001-Make-sure-nvidia-drm-rules-action-processed.impish.patch https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1958488/+attachment/5562739/+files/0001-Make-sure-nvidia-drm-rules-action-processed.impish.patch |
|
| 2022-02-22 14:53:54 |
jeremyszu |
attachment added |
|
0001-Make-sure-nvidia-drm-rules-action-processed.focal.debdiff https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1958488/+attachment/5562740/+files/0001-Make-sure-nvidia-drm-rules-action-processed.focal.debdiff |
|
| 2022-02-22 15:11:15 |
jeremyszu |
description |
[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/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 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 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.
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 |
[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.
---
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 |
|
| 2022-02-22 15:11:59 |
jeremyszu |
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.
---
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 |
[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 |
|
| 2022-02-23 16:03:20 |
jeremyszu |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2022-02-24 12:08:51 |
Alberto Milone |
nominated for series |
|
Ubuntu Impish |
|
| 2022-02-24 12:08:51 |
Alberto Milone |
bug task added |
|
gdm3 (Ubuntu Impish) |
|
| 2022-02-24 12:08:51 |
Alberto Milone |
bug task added |
|
ubuntu-drivers-common (Ubuntu Impish) |
|
| 2022-02-24 12:08:51 |
Alberto Milone |
nominated for series |
|
Ubuntu Focal |
|
| 2022-02-24 12:08:51 |
Alberto Milone |
bug task added |
|
gdm3 (Ubuntu Focal) |
|
| 2022-02-24 12:08:51 |
Alberto Milone |
bug task added |
|
ubuntu-drivers-common (Ubuntu Focal) |
|
| 2022-02-24 12:09:04 |
Alberto Milone |
ubuntu-drivers-common (Ubuntu): status |
New |
In Progress |
|
| 2022-02-24 12:09:06 |
Alberto Milone |
ubuntu-drivers-common (Ubuntu Focal): status |
New |
In Progress |
|
| 2022-02-24 12:09:08 |
Alberto Milone |
ubuntu-drivers-common (Ubuntu Impish): status |
New |
In Progress |
|
| 2022-02-24 12:09:15 |
Alberto Milone |
ubuntu-drivers-common (Ubuntu Focal): assignee |
|
Alberto Milone (albertomilone) |
|
| 2022-02-24 12:09:17 |
Alberto Milone |
ubuntu-drivers-common (Ubuntu Impish): assignee |
|
Alberto Milone (albertomilone) |
|
| 2022-03-06 09:22:12 |
Mathew Hodson |
ubuntu-drivers-common (Ubuntu): importance |
Undecided |
High |
|
| 2022-03-06 09:22:15 |
Mathew Hodson |
ubuntu-drivers-common (Ubuntu Focal): importance |
Undecided |
High |
|
| 2022-03-06 09:22:17 |
Mathew Hodson |
ubuntu-drivers-common (Ubuntu Impish): importance |
Undecided |
High |
|
| 2022-03-07 07:55:48 |
Yuan-Chen Cheng |
summary |
[nvidia][xorg] display hangs on boot LOGO |
[nvidia][xorg] display hangs on boot LOGO due to race of gdm and nvidia driver probe |
|
| 2022-03-07 07:57:59 |
Yuan-Chen Cheng |
tags |
oem-priority originate-from-1956556 patch sutton |
gdm3 oem-priority originate-from-1956556 patch sutton |
|
| 2022-03-07 08:28:16 |
jeremyszu |
tags |
gdm3 oem-priority originate-from-1956556 patch sutton |
nvidia oem-priority originate-from-1956556 patch sutton |
|
| 2022-03-07 21:44:27 |
Launchpad Janitor |
ubuntu-drivers-common (Ubuntu): status |
In Progress |
Fix Released |
|
| 2022-03-08 15:26:28 |
Sebastien Bacher |
gdm3 (Ubuntu): status |
New |
Incomplete |
|
| 2022-03-08 15:26:30 |
Sebastien Bacher |
gdm3 (Ubuntu Focal): status |
New |
Incomplete |
|
| 2022-03-08 15:26:31 |
Sebastien Bacher |
gdm3 (Ubuntu Impish): status |
New |
Incomplete |
|
| 2022-03-16 00:45:51 |
Chris Halse Rogers |
ubuntu-drivers-common (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2022-03-16 00:45:55 |
Chris Halse Rogers |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-03-16 00:45:57 |
Chris Halse Rogers |
bug |
|
|
added subscriber SRU Verification |
| 2022-03-16 00:46:03 |
Chris Halse Rogers |
tags |
nvidia oem-priority originate-from-1956556 patch sutton |
nvidia oem-priority originate-from-1956556 patch sutton verification-needed verification-needed-focal |
|
| 2022-03-16 00:51:14 |
Chris Halse Rogers |
ubuntu-drivers-common (Ubuntu Impish): status |
In Progress |
Fix Committed |
|
| 2022-03-16 00:51:22 |
Chris Halse Rogers |
tags |
nvidia oem-priority originate-from-1956556 patch sutton verification-needed verification-needed-focal |
nvidia oem-priority originate-from-1956556 patch sutton verification-needed verification-needed-focal verification-needed-impish |
|
| 2022-03-16 16:34:51 |
jeremyszu |
tags |
nvidia oem-priority originate-from-1956556 patch sutton verification-needed verification-needed-focal verification-needed-impish |
nvidia oem-priority originate-from-1956556 patch sutton verification-done-focal verification-needed verification-needed-impish |
|
| 2022-03-16 16:36:35 |
jeremyszu |
tags |
nvidia oem-priority originate-from-1956556 patch sutton verification-done-focal verification-needed verification-needed-impish |
nvidia oem-priority originate-from-1956556 patch sutton verification-done verification-done-focal verification-done-impish |
|
| 2022-03-23 16:35:50 |
Launchpad Janitor |
gdm3 (Ubuntu): status |
Incomplete |
Fix Released |
|
| 2022-03-24 02:11:15 |
Daniel van Vugt |
bug watch added |
|
https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/103 |
|
| 2022-03-28 23:55:55 |
Launchpad Janitor |
ubuntu-drivers-common (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2022-03-28 23:55:59 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2022-03-28 23:56:18 |
Launchpad Janitor |
ubuntu-drivers-common (Ubuntu Impish): status |
Fix Committed |
Fix Released |
|
| 2022-03-29 01:12:02 |
jeremyszu |
oem-priority: status |
Confirmed |
Fix Released |
|
| 2022-04-03 00:52:01 |
Mathew Hodson |
gdm3 (Ubuntu Focal): status |
Incomplete |
Triaged |
|
| 2022-04-03 00:52:04 |
Mathew Hodson |
gdm3 (Ubuntu Impish): status |
Incomplete |
Triaged |
|
| 2022-04-03 00:52:13 |
Mathew Hodson |
gdm3 (Ubuntu): importance |
Undecided |
Medium |
|
| 2022-04-03 00:52:17 |
Mathew Hodson |
gdm3 (Ubuntu Focal): importance |
Undecided |
Medium |
|
| 2022-04-03 00:52:19 |
Mathew Hodson |
gdm3 (Ubuntu Impish): importance |
Undecided |
Medium |
|
| 2022-05-10 15:10:02 |
ysfr |
bug |
|
|
added subscriber ysfr |
| 2022-05-11 16:54:00 |
ysfr |
attachment added |
|
requested log https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1958488/+attachment/5588604/+files/logs.zip |
|
| 2022-05-13 19:59:50 |
ysfr |
attachment added |
|
dkms nvidia make log https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1958488/+attachment/5589640/+files/make.log |
|
| 2022-07-18 22:59:38 |
Brian Murray |
gdm3 (Ubuntu Impish): status |
Triaged |
Won't Fix |
|
| 2023-06-05 09:46:50 |
Julian Andres Klode |
removed subscriber Ubuntu Sponsors |
|
|
|
| 2023-06-05 09:46:55 |
Julian Andres Klode |
gdm3 (Ubuntu Focal): status |
Triaged |
Incomplete |
|
