dmesg: [ +0.000118] i915 0000:00:02.0: GEM idle failed, suspend/resume might fail [ +0.000004] device_prepare(): 0xffffffff91261160 returns -512 [ +0.000002] PM: Device 0000:00:02.0 not prepared for power transition: code -512 [ +0.000001] PM: Some devices failed to suspend, or early wake event detected kernel parameters: initrd=\intel-ucode.img initrd=\initramfs-linux-clear.img root=LABEL=ROOT acpi_osi=Linux acpi_enforce_resources=lax elevator=bfq add_efi_memmap i915 module parameters: alpha_support = "Y" disable_display = "N" disable_power_well = "1" dmc_firmware_path = "(null)" edp_vswing = "0" enable_dc = "-1" enable_dp_mst = "Y" enable_dpcd_backlight= "N" enable_fbc = "1" enable_guc = "3" enable_gvt = "N" enable_hangcheck = "Y" enable_ips = "1" enable_ppgtt = "3" enable_psr = "1" fastboot = "Y" force_reset_modeset_test= "N" guc_firmware_path = "(null)" guc_log_level = "1" huc_firmware_path = "(null)" invert_brightness = "0" load_detect_test = "N" lvds_channel_mode = "0" mmio_debug = "0" modeset = "1" nuclear_pageflip = "N" panel_use_ssc = "-1" prefault_disable = "N" reset = "2" vbt_firmware = "(null)" vbt_sdvo_panel_type = "-1" verbose_state_checks= "Y"
-512 == you sent a signal to stop suspend.
I see. It should be because that i killed systemd-sleep. The real problem is that systemd-sleep hangs so i kill it. What flag can i use for more verbose of i915 logs during suspend?
Reporter, what kernel version and system this was and have you seen issue with latest drm-tip? If not please try to reproduce the error using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.
Created attachment 142821 [details] dmesg log when unable to suspend. It is really hard to repo. Hope this log helps.
(In reply to nanericwang from comment #0) > dmesg: > > [ +0.000118] i915 0000:00:02.0: GEM idle failed, suspend/resume might fail > [ +0.000004] device_prepare(): 0xffffffff91261160 returns -512 > [ +0.000002] PM: Device 0000:00:02.0 not prepared for power transition: > code -512 > [ +0.000001] PM: Some devices failed to suspend, or early wake event > detected > You get this message as you killed the systemd-sleep. Logs when systemd-sleep hangs are needed for investigation. Also, try to verify with Kernel 4.20.
Lakshmi, Logs when systemd-sleep hangs have been attached per request already.
Side note, the dmesg is a PITA to read when you have CONFIG_KALLSYMS=n and use dmesg --no-time option.
Why do you have acpi_osi=Linux acpi_enforce_resources=lax elevator=bfq add_efi_memmap in kernel parameters? Can you try without?
I tried with no these parameters at beginning, it did not resolve the issue. I don't think they are the root cause.
(In reply to nanericwang from comment #9) > I tried with no these parameters at beginning, it did not resolve the issue. > I don't think they are the root cause. That doesn't really answer the question why you have them to begin with! ;)
Reporter, any specific reason why you have acpi_osi=Linux acpi_enforce_resources=lax elevator=bfq add_efi_memmap in kernel parameters?
For 'elevator=bfq', I need BFQ low-latency to reduce application boot time. Forget about the rest of the kernel parameters, i copied them from somewhere and i don't know them, and they did not help either.
Reporter, can you verify this issue with drmtip https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.
Any results from drmtip? If it appears on dmrtip, what is the impact of this issue? Is it just the log messages or any other other impact you see?
(In reply to Lakshmi from comment #14) > Any results from drmtip? > If it appears on dmrtip, what is the impact of this issue? Is it just the > log messages or any other other impact you see? No feedback with drmtip for more than a month. Closing this bug as WORKSFORME. If the issue occurs again with drmtip, please provide all the above mentioned information.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.