| 2021-11-08 15:21:54 |
Jean-Baptiste Lallement |
bug |
|
|
added bug |
| 2021-11-08 15:22:03 |
Jean-Baptiste Lallement |
nominated for series |
|
Ubuntu Focal |
|
| 2021-11-08 15:22:03 |
Jean-Baptiste Lallement |
bug task added |
|
mesa (Ubuntu Focal) |
|
| 2021-11-08 15:22:20 |
Jean-Baptiste Lallement |
description |
[Description]
This is a request to backport this fix to focal-updates which is affecting users of WSL:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ff30a0499bd872d77b0f377414bbc03463b9f87
This cached stale pointer is causing various chromium applications (Edge, Chrome, Visual Studio Code, etc…) to hang on resize when vGPU is enabled in WSLg. We’re getting incredibly unlucky because a glx drawable is being freed and reallocated with exactly the same heap pointers during a resize, which is causing Mesa to think the new drawable is already fully initialized when binded to the context, but it is not true and only because the new drawable is matching the old stale pointer for the previously freed drawable… and as a result the context remain invalid and the app is unable to present.
With the push of WDDMv3 drivers which expose vGPU in WSL, the number of users hitting this issue is increasing. |
[Description]
This is a request to backport this fix from mesa 21.1 to focal-updates which is affecting users of WSL:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ff30a0499bd872d77b0f377414bbc03463b9f87
This cached stale pointer is causing various chromium applications (Edge, Chrome, Visual Studio Code, etc…) to hang on resize when vGPU is enabled in WSLg. We’re getting incredibly unlucky because a glx drawable is being freed and reallocated with exactly the same heap pointers during a resize, which is causing Mesa to think the new drawable is already fully initialized when binded to the context, but it is not true and only because the new drawable is matching the old stale pointer for the previously freed drawable… and as a result the context remain invalid and the app is unable to present.
With the push of WDDMv3 drivers which expose vGPU in WSL, the number of users hitting this issue is increasing. |
|
| 2021-11-08 15:22:27 |
Jean-Baptiste Lallement |
mesa (Ubuntu): status |
New |
Fix Released |
|
| 2021-11-08 15:22:32 |
Jean-Baptiste Lallement |
mesa (Ubuntu Focal): status |
New |
Triaged |
|
| 2021-11-08 15:22:35 |
Jean-Baptiste Lallement |
mesa (Ubuntu Focal): importance |
Undecided |
High |
|
| 2021-11-09 15:18:10 |
Sebastien Bacher |
mesa (Ubuntu Focal): assignee |
|
Timo Aaltonen (tjaalton) |
|
| 2021-11-09 15:37:36 |
Jean-Baptiste Lallement |
description |
[Description]
This is a request to backport this fix from mesa 21.1 to focal-updates which is affecting users of WSL:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ff30a0499bd872d77b0f377414bbc03463b9f87
This cached stale pointer is causing various chromium applications (Edge, Chrome, Visual Studio Code, etc…) to hang on resize when vGPU is enabled in WSLg. We’re getting incredibly unlucky because a glx drawable is being freed and reallocated with exactly the same heap pointers during a resize, which is causing Mesa to think the new drawable is already fully initialized when binded to the context, but it is not true and only because the new drawable is matching the old stale pointer for the previously freed drawable… and as a result the context remain invalid and the app is unable to present.
With the push of WDDMv3 drivers which expose vGPU in WSL, the number of users hitting this issue is increasing. |
[Description]
This is a request to backport this fix from mesa 21.1 to focal-updates which is affecting users of WSL:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ff30a0499bd872d77b0f377414bbc03463b9f87
This cached stale pointer is causing various chromium applications (Edge, Chrome, Visual Studio Code, etc…) to hang on resize when vGPU is enabled in WSLg. We’re getting incredibly unlucky because a glx drawable is being freed and reallocated with exactly the same heap pointers during a resize, which is causing Mesa to think the new drawable is already fully initialized when binded to the context, but it is not true and only because the new drawable is matching the old stale pointer for the previously freed drawable… and as a result the context remain invalid and the app is unable to present.
With the push of WDDMv3 drivers which expose vGPU in WSL, the number of users hitting this issue is increasing.
[Test Case] |
|
| 2021-11-10 08:29:24 |
Jean-Baptiste Lallement |
description |
[Description]
This is a request to backport this fix from mesa 21.1 to focal-updates which is affecting users of WSL:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ff30a0499bd872d77b0f377414bbc03463b9f87
This cached stale pointer is causing various chromium applications (Edge, Chrome, Visual Studio Code, etc…) to hang on resize when vGPU is enabled in WSLg. We’re getting incredibly unlucky because a glx drawable is being freed and reallocated with exactly the same heap pointers during a resize, which is causing Mesa to think the new drawable is already fully initialized when binded to the context, but it is not true and only because the new drawable is matching the old stale pointer for the previously freed drawable… and as a result the context remain invalid and the app is unable to present.
With the push of WDDMv3 drivers which expose vGPU in WSL, the number of users hitting this issue is increasing.
[Test Case] |
[Description]
This is a request to backport this fix from mesa 21.1 to focal-updates which is affecting users of WSL:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ff30a0499bd872d77b0f377414bbc03463b9f87
This cached stale pointer is causing various chromium applications (Edge, Chrome, Visual Studio Code, etc…) to hang on resize when vGPU is enabled in WSLg. We’re getting incredibly unlucky because a glx drawable is being freed and reallocated with exactly the same heap pointers during a resize, which is causing Mesa to think the new drawable is already fully initialized when binded to the context, but it is not true and only because the new drawable is matching the old stale pointer for the previously freed drawable… and as a result the context remain invalid and the app is unable to present.
With the push of WDDMv3 drivers which expose vGPU in WSL, the number of users hitting this issue is increasing.
[Test Case]
1. Verify that hardware acceleration is enable either with glxinfo -B or in edge with edge://gpu
2. Install and launch chrome, edge or vscode
3. Resize the windows repeatedly
Verification:
The app must not crash or hang. |
|
| 2021-11-10 08:46:31 |
Jean-Baptiste Lallement |
description |
[Description]
This is a request to backport this fix from mesa 21.1 to focal-updates which is affecting users of WSL:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ff30a0499bd872d77b0f377414bbc03463b9f87
This cached stale pointer is causing various chromium applications (Edge, Chrome, Visual Studio Code, etc…) to hang on resize when vGPU is enabled in WSLg. We’re getting incredibly unlucky because a glx drawable is being freed and reallocated with exactly the same heap pointers during a resize, which is causing Mesa to think the new drawable is already fully initialized when binded to the context, but it is not true and only because the new drawable is matching the old stale pointer for the previously freed drawable… and as a result the context remain invalid and the app is unable to present.
With the push of WDDMv3 drivers which expose vGPU in WSL, the number of users hitting this issue is increasing.
[Test Case]
1. Verify that hardware acceleration is enable either with glxinfo -B or in edge with edge://gpu
2. Install and launch chrome, edge or vscode
3. Resize the windows repeatedly
Verification:
The app must not crash or hang. |
[Description]
This is a request to backport this fix from mesa 21.1 to focal-updates which is affecting users of WSL:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ff30a0499bd872d77b0f377414bbc03463b9f87
This cached stale pointer is causing various chromium applications (Edge, Chrome, Visual Studio Code, etc…) to hang on resize when vGPU is enabled in WSLg. We’re getting incredibly unlucky because a glx drawable is being freed and reallocated with exactly the same heap pointers during a resize, which is causing Mesa to think the new drawable is already fully initialized when binded to the context, but it is not true and only because the new drawable is matching the old stale pointer for the previously freed drawable… and as a result the context remain invalid and the app is unable to present.
With the push of WDDMv3 drivers which expose vGPU in WSL, the number of users hitting this issue is increasing.
[Test Case]
On Windows 11 with WSLg and Ubuntu 20.04
1. Verify that hardware acceleration is enable either with glxinfo -B or in edge with edge://gpu
2. Install and launch chrome, edge or vscode
3. Resize the windows repeatedly
Verification:
The app must not crash or hang. |
|
| 2021-11-10 12:15:06 |
Robie Basak |
mesa (Ubuntu Focal): status |
Triaged |
Incomplete |
|
| 2021-11-10 12:32:29 |
Jean-Baptiste Lallement |
description |
[Description]
This is a request to backport this fix from mesa 21.1 to focal-updates which is affecting users of WSL:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ff30a0499bd872d77b0f377414bbc03463b9f87
This cached stale pointer is causing various chromium applications (Edge, Chrome, Visual Studio Code, etc…) to hang on resize when vGPU is enabled in WSLg. We’re getting incredibly unlucky because a glx drawable is being freed and reallocated with exactly the same heap pointers during a resize, which is causing Mesa to think the new drawable is already fully initialized when binded to the context, but it is not true and only because the new drawable is matching the old stale pointer for the previously freed drawable… and as a result the context remain invalid and the app is unable to present.
With the push of WDDMv3 drivers which expose vGPU in WSL, the number of users hitting this issue is increasing.
[Test Case]
On Windows 11 with WSLg and Ubuntu 20.04
1. Verify that hardware acceleration is enable either with glxinfo -B or in edge with edge://gpu
2. Install and launch chrome, edge or vscode
3. Resize the windows repeatedly
Verification:
The app must not crash or hang. |
[Description]
This is a request to backport this fix from mesa 21.1 to focal-updates which is affecting users of WSL:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ff30a0499bd872d77b0f377414bbc03463b9f87
This cached stale pointer is causing various chromium applications (Edge, Chrome, Visual Studio Code, etc…) to hang on resize when vGPU is enabled in WSLg. We’re getting incredibly unlucky because a glx drawable is being freed and reallocated with exactly the same heap pointers during a resize, which is causing Mesa to think the new drawable is already fully initialized when binded to the context, but it is not true and only because the new drawable is matching the old stale pointer for the previously freed drawable… and as a result the context remain invalid and the app is unable to present.
With the push of WDDMv3 drivers which expose vGPU in WSL, the number of users hitting this issue is increasing.
[Test Case]
On Windows 11 with WSLg and Ubuntu 20.04
1. Verify that hardware acceleration is enable either with glxinfo -B or in edge with edge://gpu
2. Install and launch chrome, edge or vscode
3. Resize the windows repeatedly
Verification:
The app must not crash or hang.
[What could go wrong] |
|
| 2021-11-10 14:18:07 |
Timo Aaltonen |
description |
[Description]
This is a request to backport this fix from mesa 21.1 to focal-updates which is affecting users of WSL:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ff30a0499bd872d77b0f377414bbc03463b9f87
This cached stale pointer is causing various chromium applications (Edge, Chrome, Visual Studio Code, etc…) to hang on resize when vGPU is enabled in WSLg. We’re getting incredibly unlucky because a glx drawable is being freed and reallocated with exactly the same heap pointers during a resize, which is causing Mesa to think the new drawable is already fully initialized when binded to the context, but it is not true and only because the new drawable is matching the old stale pointer for the previously freed drawable… and as a result the context remain invalid and the app is unable to present.
With the push of WDDMv3 drivers which expose vGPU in WSL, the number of users hitting this issue is increasing.
[Test Case]
On Windows 11 with WSLg and Ubuntu 20.04
1. Verify that hardware acceleration is enable either with glxinfo -B or in edge with edge://gpu
2. Install and launch chrome, edge or vscode
3. Resize the windows repeatedly
Verification:
The app must not crash or hang.
[What could go wrong] |
[Description]
This is a request to backport this fix from mesa 21.1 to focal-updates which is affecting users of WSL:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/7ff30a0499bd872d77b0f377414bbc03463b9f87
This cached stale pointer is causing various chromium applications (Edge, Chrome, Visual Studio Code, etc…) to hang on resize when vGPU is enabled in WSLg. We’re getting incredibly unlucky because a glx drawable is being freed and reallocated with exactly the same heap pointers during a resize, which is causing Mesa to think the new drawable is already fully initialized when binded to the context, but it is not true and only because the new drawable is matching the old stale pointer for the previously freed drawable… and as a result the context remain invalid and the app is unable to present.
With the push of WDDMv3 drivers which expose vGPU in WSL, the number of users hitting this issue is increasing.
[Test Case]
On Windows 11 with WSLg and Ubuntu 20.04
1. Verify that hardware acceleration is enable either with glxinfo -B or in edge with edge://gpu
2. Install and launch chrome, edge or vscode
3. Resize the windows repeatedly
Verification:
The app must not crash or hang.
[What could go wrong]
The patch resets two pointers to NULL in dri_unbind_context(), which is correct for that function and can't regress anything else. |
|
| 2021-11-10 14:28:35 |
Jean-Baptiste Lallement |
mesa (Ubuntu Focal): status |
Incomplete |
Triaged |
|
| 2021-11-10 15:13:58 |
Robie Basak |
mesa (Ubuntu Focal): status |
Triaged |
Fix Committed |
|
| 2021-11-10 15:13:59 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-11-10 15:14:01 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2021-11-10 15:14:03 |
Robie Basak |
tags |
|
verification-needed verification-needed-focal |
|
| 2021-11-16 08:18:27 |
Jean-Baptiste Lallement |
tags |
verification-needed verification-needed-focal |
verification-done verification-done-focal |
|
| 2021-11-18 12:58:17 |
Timo Aaltonen |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-11-18 12:58:15 |
Launchpad Janitor |
mesa (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
