Does not wake up from sleep at Intel i5 11th Gen

[Junenosuke]

Hello. I am currently using a PC with the following specs

• Fujitsu LIFEBOOK u9311/F
• 11th Gen Intel Core i5-1145G7 [Iris XE Graphics]
• Bruch 128 Stable
• I used 'dedede ' (beetley) recovery with kernel 5.15 in settings brunch .

Under these conditions, ChromeOS boots and runs without any problems, but unfortunately it cannot come back from sleep, it either reboots or freezes and the screen goes black. It reboots more often than not, I have tried multiple recoveries including rammus and volteer with the same result. Please let me know if there are any Branch settings or other areas that need to be adjusted.

Thanks a lot.

[Junenosuke]

I have tried the following...

• Another recovery images (rammus, volteer)
• Disabled TPM on BIOS settings
• Kernel of all versions (6.6, 6.1...or others)
• kernel parameter iommu=off
• Tried older BIOS versions... BIOS downgrades were not allowed on this PC

However, nothing has improved the situation and the battery life is not as good as with the S3 option applied, although it is currently being addressed by turning off the screen light to avoid going to sleep.

Any ideas ?

[Junenosuke]

I am not ready to give up and am working on this problem, but today I found a hint for a certain setup. I have several PCs for dual booting Windows/ChromeOS and I also found a distinct difference between PCs that can come back from sleep and those that can't.

I run the following command in PowerShell on Windows,

powercfg /availablesleepstates

The following sleep states are available on this system you will see that you can get the status “The following sleep states are available on this system. PC-a) We can see that “Standby (S3)” and “Hibernate” are available for PCs that can return from sleep. PC-b) For PCs that cannot return from sleep, “Standby (S0 Low Power Idle)” and “Hibernate” are available.

In b), it is considered to mean that even if “suspend_s3” is set in Kernel Options, it is not possible to recover from sleep. Now I will investigate how to solve this problem (or is it unsolvable). Ubuntu OS seems to have an effective solution.

If anyone (or @sebanc ) has any tips, please feel free to let me know.

[gritikverma]

Hi @Junenosuke , I am having similar issues, whenever I put my laptop on sleep (with brunch chrome os), the battery finishes very fast, it is never going to sleep but running in background and goes to 0% in few hours, I'm afraid this would damage the battery, I'm not sure what version I'm using, I'll have to check, I'll edit and let you know, please let me know if you found any fixes, I'm trying to find the solution as well and will let you know if anything works...

Thanks

[tie-ling]

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)
                }
            }
...

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?

--- 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)
- }
                 }
             }

[github-actions[bot]]

Unfortunately, this issue could not be resolved and is closed due to inactivity.