Black screen when waking up from suspend in ubuntu 20.04 with Iris Xe graphics

• Link existing bug

Make sure that you have the latest BIOS. It may help

Thanks a lot for your suggestion!

My laptop is running bios version 2.21 (from July 2021) and the latest one is 2.23. I have been fighting quite a bit now to update the bios, but I am close to giving up. I get a boot failure if I try to boot with a FreeDOS iso usb stick. I can get the laptop to boot with a WinPE iso usb stick, but if I then execute the bios in WinPE it does not flash it (I just get the prompt back). Very annoying. I'm out of ideas.

But in any case, I am not totally convinced that the bios is the problem. It seems like quite a few people are having this problem with a black screen after suspend. I found for instance this page:

https://askubuntu.com/questions/1367188/black-screen-after-wake-from-suspend-on-ubuntu-21-04

where it seems the person got the wake up worked with kernel version 5.4.100 for instance. I tried to install this one, but when I boot with it I get a kernel panic (I had to sign it myself for secure boot so maybe something went wrong).

In the meantime I updated to 21.10, but still the same problem. :-(

Cheers,

Sara

This problem was documented and solved at the FreeDesktop site, where Linux driver for Intel graphics is developed. It was first reported in Nov 2022, identified in Nov 2022 by developer Ville Syrjälä @vsyrjala, and a solution was documented in July 2024. See gitlab.freedesktop.org/drm/i915/kernel/-/issues/7402#note_2508780 It is titled Broken Fujitsu BIOS pokes at eDP VDD from ACPI AML code.

In summary, this bug is caused by a workaround for misbehaving windows graphics driver inside Fujitsu bios for Tiger Lake and Alder Lake platforms, e.g. Fujitsu U9311, U9312, E5411 and their variants. Fujitsu refused to fix the BIOS bug on their side, since Linux is not a supported platform.

I will repost the problem description and solution from vsyrjala et.al. for posterity here. My laptop now have perfectly working s2idle suspend now. Previously I was using intel_idle.max_cstate=2 as a stopgap solution, but limiting cstate has the side effect of consuming too much battery power during suspend.

Title: Broken Fujitsu BIOS pokes at eDP VDD from ACPI AML code

Problem description:

Ville Syrjälä @vsyrjala Nov 25, 2022
Please attach acpidump output (run as root) from the affected machine(s).

acpidump-U9312X.txt

        OperationRegion (GTTM, SystemMemory, ((GTTA << 0x18) + 0x000C7200), 0x08)
        Field (GTTM, AnyAcc, NoLock, Preserve)
        {
            Offset (0x04),
                , 3,
            VDDE, 1,
            Offset (0x08)
        }
        Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices
        {
            If ((PDRD () == Zero))
            {
                If ((VDDE == One))
                {
                    VDDE = Zero
                    Sleep (0x01F4)
                }
            }
...

--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -1183,7 +1183,7 @@ void intel_opregion_resume(struct drm_i915_private *i915)
                 * module. We don't actually need to do anything with them.
                 */
                opregion->acpi->csts = 0;
- opregion->acpi->drdy = 1;
+ opregion->acpi->drdy = 0;
        }

        if (opregion->asle) {

Szilard Fabian @szfabian Apr 4, 2024

I can confirm that the Lifebook E5411 has that same VDD poke in it's ACPI AML code (at least with UEFI version 2.36). Attached below is the relevant SSDT file.

ssdt1.dsl

With the poke in place there is always a stack trace at boot: e5411_boot_stack_trace

And here is the stack trace when resuming from S3: e5411_resume_stack_trace

In my case working suspend was kind of necessary so I tried to remove the poke in question and override SSDT1 at boot time as a temporary solution. I don't want to suggest that this is a good workaround (so if you want to try it and accidentally break your computer no warranties whatsoever!) but with that change the computer can successfully awake from S3 and there are no stack traces at boot/when waking from S3. And HDMI output seems to work perfectly too!

I don't know if this information is useful or not but if there is something I can help with related to this bug don't hesitate to contact me.

Florian Wagner @wagnerflo Jul 31, 2024

I've had the same issue with my Lifebook U9311/FJNB2E2, BIOS Version 2.52 (the latest). So I decompiled the SSDT and checked for the VDDE code mentioned by @vsyrjala in #7402 (comment 1663381). Following @szfabian suggestion and a bit of help from him here's what I did to apply a patch to the SSDT on my notebook. This fixes the suspend issues reliably:

    Extract and decompile the SSTD table. In my case I found the code in SSDT4. cat /sys/firmware/acpi/tables/SSDT4 > SSDT4.aml; iasl -d SSDT4.aml

    Apply the required changes. See SSDT4.patch.

    Recompile: iasl -sa SSDT4.dsl.

    Load the file by one of the methods described for example in the Arch Wiki: DSDT#Using_modified_code.

Contents of SSDT4.patch:

--- SSDT4.dsl.orig 2024-07-29 18:33:14.782373152 +0200
+++ SSDT4.dsl 2024-07-29 18:38:33.021477685 +0200
@@ -18,7 +18,7 @@
  * Compiler ID "INTL"
  * Compiler Version 0x20160422 (538313762)
  */
-DefinitionBlock ("", "SSDT", 2, "INTEL ", "IgfxSsdt", 0x00003000)
+DefinitionBlock ("", "SSDT", 2, "INTEL ", "IgfxSsdt", 0x00003001)
 {
     External (_SB_.PC00, DeviceObj)
     External (_SB_.PC00.GFX0, DeviceObj)
@@ -115,11 +115,6 @@
         {
             If ((PDRD () == Zero))
             {
- If ((VDDE == One))
- {
- VDDE = Zero
- Sleep (0x01F4)
- }
             }

             NDID = 0x02
@@ -2479,11 +2474,6 @@
             {
                 If ((PDRD () == Zero))
                 {
- If ((VDDE == One))
- {
- VDDE = Zero
- Sleep (0x01F4)
- }
                 }
             }

Ville Syrjälä @vsyrjala Nov 25, 2022

... continued

Looks like an intentionally broken BIOS. Fujitsu need to fix this by just taking out all this VDDE nonsense.
I have no good idea why anyone would put it there in the first place. Even weirder is that they only start to mess about with the hardware once the graphics driver has loaded (as indicated by the opregion drdy bit) . Maybe some kind of hack for a broken Windows driver that forgets to turn off the VDD? But the correct solution for that would be to fix the driver, and not hack around it via some AML code.
Frankly this could even be bad for the panel because there is no explicit synchronization with the VDD frobbing from the driver vs. the AML code. So the AML code could turn off VDD, and the driver might immediately re-enable it without waiting for the panel power cycle delay.
There are several places where this VDD frobbing happens:

opregion/DSM adapter power state notification
_DOD
perhaps entirely asynchronously via some LID events/etc.

The first one I think is safe enough since i915 only triggers that during suspend/resume handling and so the VDD should already be off anyway, the _DOD case is the one that triggers the warn if acpi_video loads after i915 and could cause some real problems too, and the last one (if it can happen, not sure) could cause problems at any time.
I had a quick look at my Thinkpad T14 gen3 AML and that has no crazy VDD stuff in it. So fortunately it does looks like this could be limited to just Fujitsu machines.
In the meantime the best we could do perhaps is to not set the drdy bit in opregion. Looks like that should make the AML code do nothing. But it could perhaps break some actually useful AML based functionality (ACPI notify stuff and whatnot). Not sure there is anything really useful in there though. This I think should eliminate the WARN?