[SOLVED] Improper screen blanking behavior with recent kernels

mz · 2022-12-17 19:41:38

Screen blanking does not behave properly when using kernel 6.0.12.arch1-1. I see the same behavior either in a VT using setterm --blank or in sway using swayidle. Here are the symptoms:

1. The screen goes blank on schedule and the monitor light switches to amber.
2. After 10 seconds, the monitor turns back on, the power light turns white, and the monitor generates a 'No Signal' message on the screen.
3. After 10 more seconds, the screen goes blank again and the power light turns amber.

This goes on forever, 10 seconds off and 10 seconds on.

If I use the LTS kernel, screen blanking behaves correctly. This is a new installation so I can't narrow down which kernel introduced the problem. Logs do not indicate any errors.

Last edited by mz (2023-03-12 15:37:10)

cfr · 2022-12-17 20:02:28

mz wrote:

Logs do not indicate any errors.

Post the journal. The problem will not necessarily manifest as an error.

mz · 2022-12-17 20:24:51

Here is a minimum journal in which I boot, observe the problem in a VT with setterm, and gather the journal:

http://0x0.st/onFr.txt

Last edited by mz (2022-12-17 20:57:58)

seth · 2022-12-17 21:14:56

Dec 17 13:47:44 lupin login[537]: LOGIN ON tty1 BY mark
Dec 17 13:50:54 lupin kernel: logitech-hidpp-device 0003:046D:4013.0006: HID++ 2.0 device connected.
Dec 17 13:51:41 lupin sudo[681]:     mark : TTY=tty1 ; PWD=/home/mark ; USER=root ; COMMAND=/usr/bin/journalctl -b

How and where is the mouse connected? Monitor hub?

mz · 2022-12-17 21:40:22

Via a wireless dongle plugged into the keyboard.

mz · 2022-12-18 01:56:01

I think that my symptoms correspond to this bug:

https://bugzilla.kernel.org/show_bug.cgi?id=215203

except for the fact that they are focusing on an AMD gpu issue and I have Intel.

cfr · 2022-12-18 02:08:26

Does the problem still occur if you remove the dongle beforehand?

mz · 2022-12-18 02:43:30

Yes. Booted mouseless; problem persists.

seth · 2022-12-18 08:27:39

Via a wireless dongle plugged into the keyboard.

How and where is the keyboard connected?

mz · 2022-12-18 12:19:26

Wired USB connection directly to the back of the computer.

seth · 2022-12-18 14:45:27

The theory because of

Dec 17 13:47:44 lupin login[537]: LOGIN ON tty1 BY mark
Dec 17 13:50:54 lupin kernel: logitech-hidpp-device 0003:046D:4013.0006: HID++ 2.0 device connected.
Dec 17 13:51:41 lupin sudo[681]:     mark : TTY=tty1 ; PWD=/home/mark ; USER=root ; COMMAND=/usr/bin/journalctl -b

would have been that the output gets suspended and that triggers an input event (because of an input device attached to it)

Apparently that's not the case, so my next best explanation would be a general USB autosuspend issue.
I suspect the trigger to be the mouse, so try the behavior w/ it detached.
If you can test the system via ssh, removing all input devices would be even better.

A less input-restricting solution would be to disable https://wiki.archlinux.org/title/Power_ … utosuspend

mz · 2022-12-18 16:14:40

I've tried booting with no mouse (see above). No help.

Since everything works properly with the LTS kernel I think it's time to start a git bisect and see where that leads.

mz · 2023-03-05 18:34:40

Git bisect results:

$ git bisect good
527bab0473f28236e4587c7870586275c1ef5516 is the first bad commit
commit 527bab0473f28236e4587c7870586275c1ef5516
Author: Tilak Tangudu <tilak.tangudu@intel.com>
Date:   Tue Nov 16 21:22:38 2021 +0530

    drm/i915/rpm: Enable runtime pm autosuspend by default

    Let's enable runtime pm autosuspend by default everywhere.
    So, we can allow D3hot and bigger power savings on idle scenarios.

    But at this time let's not touch the autosuspend_delay time,
    what caused some regression on our previous attempt.

    Also, the latest identified issue on GuC PM has been fixed by
    commit 1a52faed3131 ("drm/i915/guc: Take GT PM ref when deregistering
    context")

    v1: Enable runtime pm autosuspend by default for Gen12
    and later versions.

    v2: Enable runtime pm autosuspend by default for all
    platforms(Syrjala Ville)

    v3: Change commit message(Nikula Jani)

    Signed-off-by: Tilak Tangudu <tilak.tangudu@intel.com>
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211116155238.3226516-1-tilak.tangudu@intel.com

 drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++
 1 file changed, 3 insertions(+)

loqs · 2023-03-05 18:53:44

Have you tried the kernel parameters from intel_graphics#Crash/freeze_on_low_power_Intel_CPUs?

mz · 2023-03-05 19:59:05

loqs wrote:

Have you tried the kernel parameters from intel_graphics#Crash/freeze_on_low_power_Intel_CPUs?

No, I haven't, because I am not experiencing hangs, crashes, or freezes.

This is a Gen12 system, if that matters.

Do you think this needs a bug report? I verified that the issue still exists in 6.2.2-arch1-1. It would be great if a kernel parameter would suffice.

Last edited by mz (2023-03-06 00:22:22)

mz · 2023-03-06 00:23:18

loqs wrote:

Have you tried the kernel parameters from intel_graphics#Crash/freeze_on_low_power_Intel_CPUs?

I just tried all three of them, one at a time. None had any effect.

seth · 2023-03-06 08:26:18

Date: Tue Nov 16 21:22:38 2021 +0530

Are we sure that *this* is the offending patch? The specific code doesn't exist for more than a year now.

mz · 2023-03-06 15:23:40

seth wrote:

Date: Tue Nov 16 21:22:38 2021 +0530
Are we sure that *this* is the offending patch? The specific code doesn't exist for more than a year now.

I'm pretty sure, unless I misspelled 'good' or 'bad' at some point. The change boils down to one line:

+	/* Enable by default */
+	pm_runtime_allow(kdev);
+

What could be wrong with that, right? Unless it triggers the use of some firmware code that was not exercised before and which was never quite right for this chip. i915 loads multiple firmware files; maybe I need to go on a firmware hunt. I miss the days when a chip was a chip and not a platform for multiple firmwares.

seth · 2023-03-06 15:45:46

The point is that the commit was > 1 year old when you started the thread.

Your OP wrote:

Screen blanking does not behave properly when using kernel 6.0.12.arch1-1

Did you only test that kernel and the 5.15 lts one or also some kernel inbetween?

mz · 2023-03-07 02:24:09

seth wrote:

Did you only test that kernel and the 5.15 lts one or also some kernel inbetween?

Look here for the story of the git bisect: https://bbs.archlinux.org/viewtopic.php?id=283833

mz · 2023-03-12 15:36:02

Using 6.2.2-arch2-1 with this patch:

index 61c38fc734cf..4d4ab3e578c2 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -767,7 +767,7 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)

        intel_display_driver_register(dev_priv);

-       intel_power_domains_enable(dev_priv);
+       /* intel_power_domains_enable(dev_priv); */
        intel_runtime_pm_enable(&dev_priv->runtime_pm);

        intel_register_dsm_handler();

everything behaves properly. I'm going to call this solved since I have a solution that works for me.

Since this is new Dell hardware and since Dell supports Ubuntu they will encounter this issue soon enough and maybe get it fixed properly.

Arch Linux

#1 2022-12-17 19:41:38

[SOLVED] Improper screen blanking behavior with recent kernels

#2 2022-12-17 20:02:28

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#3 2022-12-17 20:24:51

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#4 2022-12-17 21:14:56

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#5 2022-12-17 21:40:22

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#6 2022-12-18 01:56:01

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#7 2022-12-18 02:08:26

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#8 2022-12-18 02:43:30

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#9 2022-12-18 08:27:39

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#10 2022-12-18 12:19:26

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#11 2022-12-18 14:45:27

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#12 2022-12-18 16:14:40

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#13 2023-03-05 18:34:40

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#14 2023-03-05 18:53:44

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#15 2023-03-05 19:59:05

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#16 2023-03-06 00:23:18

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#17 2023-03-06 08:26:18

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#18 2023-03-06 15:23:40

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#19 2023-03-06 15:45:46

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#20 2023-03-07 02:24:09

Re: [SOLVED] Improper screen blanking behavior with recent kernels

#21 2023-03-12 15:36:02

Re: [SOLVED] Improper screen blanking behavior with recent kernels

Board footer