Hey. I've had already asked for that previously[0] but there was no feedback. I got a new Fujitsu Lifebook U7512, which has an Intel i7-1270P and runs with 6.1.8. A previous error that I've described in [0] that occurred on resume (after suspending to RAM) and which had to do with i915 has now been fixed - not by the patches to i915 (which haven't made it into mainline or stables kernels yet), but by a BIOS update (which is now at the most recent on published) provided by Fujitsu. So the i915 related issues should be gone (I guess) - at least no i915 related errors show up anymore in the kernel log and also the other symptoms described in the i915 bugs linked at [0] are gone. However, another issue remains: When I go into suspend (to RAM) the system doesn't actually seem to fully suspend: - the fan keeps still running (though it sometimes slows down after a while) - while I see the typical (well at least for Fujitsu notebooks) LED blinking pattern which indicates suspend to RAM, ... resume is not triggered by pressing the power button (as it used to be in my previous Fujitsu notebooks - in addition to opening the lid), but by pressing any keyboard key, which also means that at least the keyboard is still powered on. # cat /sys/power/mem_sleep [s2idle] deep I manually set that to deep, and then tried suspend&resume again, but on resume the system just freezes: screen doesn't go on, neither would I hear any fan that indicates CPU utilisation,... the only thing what happens is that the power LED and the F-Lock[1] LED go on. Doesn't seem I could do anything than long-pressing the powerbutton to shut it off. With s2idle, a suspend/resume cycle gives the following output to the kernel log: Jan 15 05:55:43 heisenberg kernel: wlan0: deauthenticating from 50:e6:36:3c:99:36 by local choice (Reason: 3=DEAUTH_LEAVING) Jan 15 05:55:44 heisenberg kernel: PM: suspend entry (s2idle) Jan 15 05:55:44 heisenberg kernel: Filesystems sync: 0.016 seconds Jan 15 05:55:44 heisenberg kernel: (NULL device *): firmware: direct-loading firmware regulatory.db Jan 15 05:55:44 heisenberg kernel: (NULL device *): firmware: direct-loading firmware iwlwifi-so-a0-gf-a0.pnvm Jan 15 05:55:44 heisenberg kernel: (NULL device *): firmware: direct-loading firmware regulatory.db.p7s Jan 15 05:55:44 heisenberg kernel: (NULL device *): firmware: direct-loading firmware intel/sof-tplg/sof-hda-generic-2ch.tplg Jan 15 05:55:44 heisenberg kernel: (NULL device *): firmware: direct-loading firmware iwlwifi-so-a0-gf-a0-72.ucode Jan 15 05:55:44 heisenberg kernel: (NULL device *): firmware: direct-loading firmware i915/adlp_dmc_ver2_16.bin Jan 15 05:55:44 heisenberg kernel: (NULL device *): firmware: direct-loading firmware i915/adlp_guc_70.bin Jan 15 05:55:44 heisenberg kernel: (NULL device *): firmware: direct-loading firmware i915/tgl_huc.bin Jan 15 05:55:51 heisenberg kernel: Freezing user space processes ... (elapsed 0.039 seconds) done. Jan 15 05:55:51 heisenberg kernel: OOM killer disabled. Jan 15 05:55:51 heisenberg kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Jan 15 05:55:51 heisenberg kernel: printk: Suspending console(s) (use no_console_suspend to debug) Jan 15 05:55:51 heisenberg kernel: intel-hid INTC1070:00: failed to get button capability Jan 15 05:55:51 heisenberg kernel: e1000e: EEE TX LPI TIMER: 00000011 Jan 15 05:55:51 heisenberg kernel: ACPI: EC: interrupt blocked Jan 15 05:55:51 heisenberg kernel: ACPI: EC: interrupt unblocked Jan 15 05:55:51 heisenberg kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1 Jan 15 05:55:51 heisenberg kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3 Jan 15 05:55:51 heisenberg kernel: intel-hid INTC1070:00: failed to get button capability Jan 15 05:55:51 heisenberg kernel: nvme nvme0: Shutdown timeout set to 10 seconds Jan 15 05:55:51 heisenberg kernel: nvme nvme0: 16/0/0 default/read/poll queues Jan 15 05:55:51 heisenberg kernel: i915 0000:00:02.0: [drm] HuC authenticated Jan 15 05:55:51 heisenberg kernel: i915 0000:00:02.0: [drm] GuC submission enabled Jan 15 05:55:51 heisenberg kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled Jan 15 05:55:51 heisenberg kernel: i915 0000:00:02.0: [drm] GuC RC: enabled Jan 15 05:55:51 heisenberg kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915]) Jan 15 05:55:51 heisenberg kernel: OOM killer enabled. Jan 15 05:55:51 heisenberg kernel: Restarting tasks ... done. Jan 15 05:55:51 heisenberg kernel: random: crng reseeded on system resumption Jan 15 05:55:51 heisenberg kernel: PM: suspend exit Jan 15 05:55:51 heisenberg kernel: e1000e 0000:00:1f.6 eth0: NIC Link is Down Jan 15 05:55:53 heisenberg kernel: wlan0: authenticate with 50:e6:36:3c:99:36 Jan 15 05:55:53 heisenberg kernel: wlan0: send auth to 50:e6:36:3c:99:36 (try 1/3) Jan 15 05:55:54 heisenberg kernel: wlan0: authenticate with 50:e6:36:3c:99:36 Jan 15 05:55:54 heisenberg kernel: wlan0: send auth to 50:e6:36:3c:99:36 (try 1/3) Jan 15 05:55:54 heisenberg kernel: wlan0: authenticated Jan 15 05:55:54 heisenberg kernel: wlan0: associate with 50:e6:36:3c:99:36 (try 1/3) Jan 15 05:55:54 heisenberg kernel: wlan0: RX AssocResp from 50:e6:36:3c:99:36 (capab=0x1511 status=0 aid=2) Jan 15 05:55:54 heisenberg kernel: wlan0: associated Jan 15 05:55:54 heisenberg kernel: iwlwifi 0000:00:14.3: Unhandled alg: 0x707 Jan 15 05:55:54 heisenberg kernel: iwlwifi 0000:00:14.3: Unhandled alg: 0x707 Jan 15 05:55:54 heisenberg kernel: iwlwifi 0000:00:14.3: Unhandled alg: 0x707 Jan 15 05:55:54 heisenberg kernel: iwlwifi 0000:00:14.3: Unhandled alg: 0x707 Jan 15 05:55:54 heisenberg kernel: iwlwifi 0000:00:14.3: Unhandled alg: 0x707 Jan 15 05:55:54 heisenberg kernel: iwlwifi 0000:00:14.3: Unhandled alg: 0x707 Jan 15 05:55:54 heisenberg kernel: iwlwifi 0000:00:14.3: Unhandled alg: 0x707 Jan 15 05:55:54 heisenberg kernel: iwlwifi 0000:00:14.3: Unhandled alg: 0x707 Jan 15 05:55:54 heisenberg kernel: wlan0: Limiting TX power to 20 (23 - 3) dBm as advertised by 50:e6:36:3c:99:36 Jan 15 05:55:54 heisenberg kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready What else can I say... the system runs in native UEFI (no CSM)... if you need any other information, don't hesitate to ask :-) Any help in fixing this would be greatly appreciated. Thanks, Chris. PS: Please keep me CCed, as I'm not subscribed. [0] https://lore.kernel.org/linux-pm/07e4bb6502042ae103824de53c1c382b2be2f658.camel@scientia.org/ [1] That's just a permanent switch between the F*-keys and the "multimedia".keys.
Just for the records: still the case as of kernel 6.1.12 and with a newly released BIOS (2.25)
Still in 6.1.15. Also I've noticed the following in my kernel logs: # dmesg | grep -i suspend [ 1.295940] Low-power S0 idle used by default for system suspend [ 1.952309] nvme 0000:01:00.0: platform quirk: setting simple suspend Not sure if the nvme message is about some suspend *just* for the NVMe itself or whether it has to do with s2deep (especially as it comes after the information that the kernel chooses s2idle as default)... ... but I found: https://bugzilla.kernel.org/show_bug.cgi?id=215742 Where the same quirk seems to have caused a broken resume... just like in my case (when I force to use s2deep, the system just hangs at resume).
> [ 1.295940] Low-power S0 idle used by default for system suspend The kernel will by default prefer to use s2idle as that's what the firmware indicates in the FADT. In my experience unless the vendor has intentionally spent extra effort to make S3 work you're unlikely to get a functional "deep" mode on modern hardware like this. > Not sure if the nvme message is about some suspend *just* for the NVMe itself > or whether It's just for the NVME disk. > Where the same quirk seems to have caused a broken resume... just like in my > case (when I force to use s2deep, the system just hangs at resume). You're misinterpreting this issue. The problem was the lack of quirk led to problems during resume from s2idle. --- My suggestion for your issue is that you focus on identifying the problems with s2idle for your system and report those to the individual driver and subsystem owners to get fixed rather than work on S3.
In the meantime I disabled the NVMe in the BIOS and booted with that. Whil the 2nd message disappears, the kernel still defaults to s2idle and resuming from deep mode still freezes (the screen doesn't even go on). So that seems to confirm, as you've said, that the two have nothing to do with each other. > In my experience unless the vendor has intentionally spent extra > effort to make S3 work you're unlikely to get a functional "deep" > mode on modern hardware like this. Sounds unbelievable... I mean (real) suspend is like base technology and they don't make it work... sigh.