You are not logged in.
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)
Offline
Logs do not indicate any errors.
Post the journal. The problem will not necessarily manifest as an error.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Here is a minimum journal in which I boot, observe the problem in a VT with setterm, and gather the journal:
Last edited by mz (2022-12-17 20:57:58)
Offline
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?
Offline
Via a wireless dongle plugged into the keyboard.
Offline
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.
Offline
Does the problem still occur if you remove the dongle beforehand?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Yes. Booted mouseless; problem persists.
Offline
Via a wireless dongle plugged into the keyboard.
How and where is the keyboard connected?
Offline
Wired USB connection directly to the back of the computer.
Offline
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
Offline
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.
Offline
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(+)
Offline
Have you tried the kernel parameters from intel_graphics#Crash/freeze_on_low_power_Intel_CPUs?
Offline
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)
Offline
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.
Offline
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.
Offline
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.
Offline
The point is that the commit was > 1 year old when you started the thread.
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?
Offline
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
Offline
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.
Offline