You are not logged in.
Pages: 1
Hello,
I have a Problem with my new PC, a Fujitsu U9311X (Intel Core i7-1185G7 with 16GB RAM). The installation is up-to-date, Kernel 5.16.4-arch1-1, with Gnome as DM (with wayland).
The Problem:
If the Laptop goes in Hibernate or Suspend, afterwards it does not properly resume, e.g. the display stays black for about 60 sec and then the display flickers from time to time. The PC does not freeze, I am able to login to GUI or via SSH.
So i have to hard reset the PC to work with it again.
What the Problem to me seems to be:
the i915 Module is not able to write to OUI after the resume.
What I have already tried:
Different Kernel Versions from (5.14.x till now) and also the LTS-Kernel and the Mainline-Kernel
Changed Boot parameters e.g. nomodeset
Preload the i915 Module Early KMS and also Disable it
Searching several hours in the Internet brought to me, that perhaps the Hardware is not properly supported
Some Log-Files:
journalctl -b
dmsgb
Perhaps there is somebody out there who is able to help me, thanks for your thoughts.
Greetings
Minnten
PS: Perhaps this Topic is not suited well here.
Last edited by minnten (2022-01-31 13:04:04)
Offline
Jan 31 13:48:50 archlinux systemd[1]: Reached target Sleep.
Jan 31 13:48:50 archlinux systemd[1]: Starting System Suspend...
Jan 31 13:48:50 archlinux systemd-sleep[1618]: Entering sleep state 'suspend'...
Jan 31 13:48:50 archlinux kernel: PM: suspend entry (s2idle)
…
Jan 31 13:48:55 archlinux kernel: ------------[ cut here ]------------
Jan 31 13:48:55 archlinux kernel: i915 0000:00:02.0: i915 raw-wakerefs=1 wakelocks=1 on cleanup
Jan 31 13:48:55 archlinux kernel: WARNING: CPU: 2 PID: 1629 at drivers/gpu/drm/i915/intel_runtime_pm.c:625 intel_runtime_pm_driver_release+0x57/0x70 [i915]
Jan 31 13:48:55 archlinux kernel: Modules linked in: rfcomm ccm cmac algif_hash algif_skcipher af_alg hid_multitouch snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_soc_dmic snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence hid_sensor_custom_intel_hinge snd_sof_intel_hda snd_sof_pci hid_sensor_accel_3d hid_sensor_incl_3d hid_sensor_gyro_3d hid_sensor_magn_3d snd_sof_xtensa_dsp hid_sensor_rotation hid_sensor_trigger snd_sof industrialio_triggered_buffer kfifo_buf snd_soc_hdac_hda hid_sensor_iio_common industrialio hid_sensor_custom snd_hda_ext_core snd_soc_acpi_intel_match hid_sensor_hub snd_soc_acpi soundwire_bus intel_tcc_cooling ledtrig_audio x86_pkg_temp_thermal intel_powerclamp intel_ishtp_hid snd_soc_core bnep iTCO_wdt snd_compress coretemp intel_pmc_bxt ac97_bus iTCO_vendor_support mei_pxp mei_wdt mei_hdcp snd_pcm_dmaengine kvm_intel iwlmvm intel_rapl_msr pmt_telemetry snd_hda_intel pmt_class wmi_bmof kvm snd_intel_dspcfg
Jan 31 13:48:55 archlinux kernel: snd_intel_sdw_acpi mac80211 irqbypass snd_hda_codec intel_cstate libarc4 vfat snd_hda_core fat intel_uncore snd_hwdep snd_pcm intel_spi_pci pcspkr iwlwifi e1000e snd_timer intel_spi i2c_i801 snd spi_nor intel_lpss_pci mtd i2c_smbus soundcore uvcvideo mei_me intel_lpss mei cfg80211 videobuf2_vmalloc btusb idma64 videobuf2_memops btrtl videobuf2_v4l2 cdc_mbim joydev btbcm videobuf2_common processor_thermal_device_pci_legacy processor_thermal_device mousedev btintel cdc_wdm processor_thermal_rfim videodev cdc_ncm processor_thermal_mbox mc cdc_ether bluetooth processor_thermal_rapl usbnet ecdh_generic ucsi_acpi intel_ish_ipc wacom intel_rapl_common mii rfkill intel_ishtp thunderbolt typec_ucsi intel_soc_dts_iosf intel_pmt typec igen6_edac roles i2c_hid_acpi wmi i2c_hid mac_hid intel_hid fujitsu_laptop int3403_thermal int340x_thermal_zone sparse_keymap int3400_thermal acpi_pad acpi_thermal_rel acpi_tad usbip_host usbip_core sg crypto_user fuse bpf_preload ip_tables x_tables ext4
Jan 31 13:48:55 archlinux kernel: crc32c_generic crc16 mbcache jbd2 usbhid dm_crypt cbc encrypted_keys dm_mod trusted asn1_encoder tee tpm rng_core serio_raw atkbd libps2 crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel sdhci_pci cqhci crypto_simd sdhci cryptd xhci_pci mmc_core xhci_pci_renesas i8042 serio i915 video ttm intel_agp intel_gtt
Jan 31 13:48:55 archlinux kernel: CPU: 2 PID: 1629 Comm: kworker/u16:17 Tainted: G U W 5.16.4-arch1-1 #1 87a61058ca8b29d5969d8366cd8a741aaacec6d2
Jan 31 13:48:55 archlinux kernel: Hardware name: FUJITSU CLIENT COMPUTING LIMITED LIFEBOOK U9311X/FJNB2E4, BIOS Version 2.19 07/15/2021
Jan 31 13:48:55 archlinux kernel: Workqueue: events_unbound async_run_entry_fn
Jan 31 13:48:55 archlinux kernel: RIP: 0010:intel_runtime_pm_driver_release+0x57/0x70 [i915]
Jan 31 13:48:55 archlinux kernel: Code: 10 4c 8b 6f 50 4d 85 ed 75 03 4c 8b 2f e8 e1 30 0a da 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 00 ae 4b c0 e8 6a 4b 48 da <0f> 0b 5b 41 5c 41 5d 31 c0 89 c2 89 c1 89 c6 89 c7 41 89 c0 c3 0f
Jan 31 13:48:55 archlinux kernel: RSP: 0018:ffffc114c1073db0 EFLAGS: 00010246
Jan 31 13:48:55 archlinux kernel: RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
Jan 31 13:48:55 archlinux kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
Jan 31 13:48:55 archlinux kernel: RBP: ffff9f8782100000 R08: 0000000000000000 R09: 0000000000000000
Jan 31 13:48:55 archlinux kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
Jan 31 13:48:55 archlinux kernel: R13: ffff9f87820cf020 R14: 0000000000000002 R15: ffff9f8780121805
Jan 31 13:48:55 archlinux kernel: FS: 0000000000000000(0000) GS:ffff9f8b20480000(0000) knlGS:0000000000000000
Jan 31 13:48:55 archlinux kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 31 13:48:55 archlinux kernel: CR2: 000055b7f011d528 CR3: 0000000445610004 CR4: 0000000000770ee0
Jan 31 13:48:55 archlinux kernel: PKRU: 55555554
Jan 31 13:48:55 archlinux kernel: Call Trace:
Jan 31 13:48:55 archlinux kernel: <TASK>
Jan 31 13:48:55 archlinux kernel: i915_drm_suspend_late+0xf1/0x110 [i915 343adb3190d8a05d4d13be5d6595535f26ddcc89]
Jan 31 13:48:55 archlinux kernel: ? pci_pm_poweroff_late+0x40/0x40
Jan 31 13:48:55 archlinux kernel: dpm_run_callback+0x47/0x160
Jan 31 13:48:55 archlinux kernel: __device_suspend_late+0xc6/0x250
Jan 31 13:48:55 archlinux kernel: async_suspend_late+0x1b/0x90
Jan 31 13:48:55 archlinux kernel: async_run_entry_fn+0x2d/0x130
Jan 31 13:48:55 archlinux kernel: process_one_work+0x1e5/0x3c0
Jan 31 13:48:55 archlinux kernel: worker_thread+0x50/0x3c0
Jan 31 13:48:55 archlinux kernel: ? rescuer_thread+0x380/0x380
Jan 31 13:48:55 archlinux kernel: kthread+0x15a/0x180
Jan 31 13:48:55 archlinux kernel: ? set_kthread_struct+0x50/0x50
Jan 31 13:48:55 archlinux kernel: ret_from_fork+0x1f/0x30
Jan 31 13:48:55 archlinux kernel: </TASK>
Jan 31 13:48:55 archlinux kernel: ---[ end trace 260e696d4b164a09 ]---
…
Jan 31 13:48:55 archlinux systemd-sleep[1618]: System returned from sleep state.
Jan 31 13:48:55 archlinux systemd[1]: systemd-suspend.service: Deactivated successfully.
Jan 31 13:48:55 archlinux systemd[1]: Finished System Suspend.
Jan 31 13:48:55 archlinux systemd[1]: Stopped target Sleep.
Jan 31 13:48:55 archlinux systemd[1]: Reached target Suspend.
Jan 31 13:48:55 archlinux systemd[1]: Stopped target Suspend.
Jan 31 13:48:55 archlinux systemd-logind[593]: Operation 'sleep' finished.
…
Jan 31 13:49:04 archlinux kernel: i915 0000:00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] Failed to enable link training
Jan 31 13:49:07 archlinux gnome-shell[1092]: Removing a network device that was not added
Jan 31 13:49:08 archlinux kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to read DPCD register 0x60
Jan 31 13:49:09 archlinux kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92
Jan 31 13:49:11 archlinux kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to read DPCD register 0x60
Jan 31 13:49:12 archlinux kernel: i915 0000:00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92
https://gitlab.freedesktop.org/drm/intel/-/issues/4950
https://gitlab.freedesktop.org/drm/inte … te_1224963
Offline
Hello,
I tried the this kernel and had some issues, I could not resolv.
The biggest problem is, that I use a full encrypted SSD which I was not able to decrypt with this kernel.
So for me it means, that I am waiting till this problem is solved and into the standard kernel included.
Thanks for your help.
Greetings Minnten
Offline
I have the same issue with my friends LG Gram 17Z95P CPU i7-1195G7 Intel Iris Xe rev 03, but I don't get anything in the logs
The system crashes with a blinking screen on resume with both linux and linux-lts
however suspend and resume works with a ubuntu 21-10 live cd so I copied over that kernel to the arch install and it works with that kernel ( 5.13.0-19-generic )
Offline
I know it's a topic on the bit older side, but that was the first I found so I thought I give a short workaround/solution after I tried a couple things.
I also have the U9311x and what works for me:
BIOS:
On-battery: "low power" (not long battery life, this will not resume, at least I didn't find any setting which worked)
PreSleep: rmmod intel-lpss-pci
Resume/PostSleep: modprobe intel-lpss-pci (in theory you could also load it manually, because only the touchpad, not touchscreen, are affected)
With this setting I get around 5% power draw per hour in suspend. I still want to try if disabling Intel ME (I actually guess they mean only AMT) has any affect on this since I read in a framework post, that disabling Intel ME highers the power draw in S0Idle
Offline
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)
- }
}
}
Offline
Pages: 1