** Description changed: + [Impact] + + On a hybrid machine where NVIDIA is rendering the screen, if a display + attached to a dock is removed while on suspend mode, on resume X + crashes. + + [Test case] + + Test hot-unplug during suspend and resume, X shouldn't crash. + + + [Regression potential] + This replaces a patch we had with two commits that got merged upstream after a fairly extensive review process: + + https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/443/ + + And we ship it in groovy. If there were issues caused by it, they would + be around hot-unplugging a dock while on suspend and such. + + + -- + Expectation: on removal of external display during S3, after resume eDP rendering should still continue by Nvidia. Symptom description: Plug out DP cable when suspension, when resume, X will crash. 1. Before S3 entry, eDP and external panel(via dock) were driven by Intel but NV was rendering for eDP. 2. After S3 entry dock was removed. 3. On resume, Linux kernel tried to find dock but couldn’t find it, so fails resume of TB3 devices and logs confirm that. 4. X fails to enter VT due to Null meta mode. - - To address the explanation, X is not failing to enter the VT due to NVIDIA’s NULL MetaMode. It’s the Intel (modesetting) driver that is failing to enter the VT. It’s expected that NVIDIA would have a NULL MetaMode, since there are no displays connected to it. Our driver is pretty robust to head state changes – even if we have to fall back to a NULL MetaMode, we will still enter the VT successfully. + To address the explanation, X is not failing to enter the VT due to + NVIDIA’s NULL MetaMode. It’s the Intel (modesetting) driver that is + failing to enter the VT. It’s expected that NVIDIA would have a NULL + MetaMode, since there are no displays connected to it. Our driver is + pretty robust to head state changes – even if we have to fall back to a + NULL MetaMode, we will still enter the VT successfully. The logs clearly show that the failure is originating from the Intel (modesetting) driver, not the NVIDIA driver. The relevant path in X is driver.c:EnterVT() => drmmode_display.c:drmmode_set_desired_modes(). In this function, the Intel driver tries to set a mode on each of the previously connected/enabled displays, and it tries to find the closest possible mode using xf86OutputFindClosestMode(). This is similar to our driver’s functionality, but unlike us, they don’t support a NULL fallback. If there are no modes supported on one of the displays, it simply fails, which causes X to terminate: DisplayModePtr mode = xf86OutputFindClosestMode(output, pScrn->currentMode); if (!mode) - return FALSE; + return FALSE; Since we removed one of the displays via the dock, it fails. It doesn’t matter if the internal panel is still available, Intel will fail if it can’t re-enable ANY of the previously connected displays. Technically the modesetting driver isn’t specifically an Intel driver, it’s a generic driver that can be used by any DRM device – it’s just that Intel has chosen to use the modesetting driver as their standard Linux X driver going forward.
** Description changed: [Impact] On a hybrid machine where NVIDIA is rendering the screen, if a display attached to a dock is removed while on suspend mode, on resume X crashes. [Test case] Test hot-unplug during suspend and resume, X shouldn't crash. + [Regression potential] - [Regression potential] - This replaces a patch we had with two commits that got merged upstream after a fairly extensive review process: + This replaces a patch we had with two commits that got merged upstream + after a fairly extensive review process: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/443/ And we ship it in groovy. If there were issues caused by it, they would be around hot-unplugging a dock while on suspend and such. - -- Expectation: on removal of external display during S3, after resume eDP rendering should still continue by Nvidia. Symptom description: Plug out DP cable when suspension, when resume, X will crash. 1. Before S3 entry, eDP and external panel(via dock) were driven by Intel but NV was rendering for eDP. 2. After S3 entry dock was removed. 3. On resume, Linux kernel tried to find dock but couldn’t find it, so fails resume of TB3 devices and logs confirm that. 4. X fails to enter VT due to Null meta mode. To address the explanation, X is not failing to enter the VT due to NVIDIA’s NULL MetaMode. It’s the Intel (modesetting) driver that is failing to enter the VT. It’s expected that NVIDIA would have a NULL MetaMode, since there are no displays connected to it. Our driver is pretty robust to head state changes – even if we have to fall back to a NULL MetaMode, we will still enter the VT successfully. The logs clearly show that the failure is originating from the Intel (modesetting) driver, not the NVIDIA driver. The relevant path in X is driver.c:EnterVT() => drmmode_display.c:drmmode_set_desired_modes(). In this function, the Intel driver tries to set a mode on each of the previously connected/enabled displays, and it tries to find the closest possible mode using xf86OutputFindClosestMode(). This is similar to our driver’s functionality, but unlike us, they don’t support a NULL fallback. If there are no modes supported on one of the displays, it simply fails, which causes X to terminate: DisplayModePtr mode = xf86OutputFindClosestMode(output, pScrn->currentMode); if (!mode) return FALSE; Since we removed one of the displays via the dock, it fails. It doesn’t matter if the internal panel is still available, Intel will fail if it can’t re-enable ANY of the previously connected displays. Technically the modesetting driver isn’t specifically an Intel driver, it’s a generic driver that can be used by any DRM device – it’s just that Intel has chosen to use the modesetting driver as their standard Linux X driver going forward. -- You received this bug notification because you are a member of Ubuntu-X, which is subscribed to xorg-server-hwe-18.04 in Ubuntu. https://bugs.launchpad.net/bugs/1897530 Title: The modesetting driver does not gracefully handle missing connectors on EnterVT To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1897530/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
