You are not logged in.
uname -sr:
Linux 6.6.54-1-lts
inxi -G:
Graphics:
Device-1: Intel RocketLake-S GT1 [UHD Graphics 730] driver: i915 v: kernel
Display: x11 server: X.org v: 1.21.1.13 driver: X: loaded: modesetting
dri: iris gpu: i915 s-res: 1920x1080
API: OpenGL Message: Unable to show GL data. glxinfo is missing.
On boot, everything is fine. Running xrandr gives the expected output:
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
1920x1080 60.00*+ 100.00 74.97 50.00 59.94
1680x1050 59.88
1600x900 60.00
1280x1024 75.02 60.02
1280x800 59.91
1152x864 75.00
1280x720 100.00 60.00 50.00 59.94
1024x768 99.81 75.03 60.00
832x624 74.55
800x600 75.00 60.32
720x576 50.00
720x480 60.00 59.94
640x480 75.00 60.00 59.94
720x400 70.08
DP-1 disconnected (normal left inverted right x axis y axis)
After I suspend the system and wake it up, seemingly everything is okay, the image looks the same, the mode seems unchanged. But running xrandr now shows all outputs as disconnected:
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
HDMI-1 disconnected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
DP-1 disconnected (normal left inverted right x axis y axis)
1920x1080 (0x44) 148.500MHz +HSync +VSync
h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.50KHz
v: height 1080 start 1084 end 1089 total 1125 clock 60.00Hz
The issue now is, various programs (that, I presume, get screen info from xrandr) like lightdm-gtk-greeter, xwallpaper, mpv, aren't working as expected. If I end the display manager session, the screen turns black. If I try to change the mode with xrandr, be it by adding a new mode or with xrandr --auto, the screen also turn black. Same thing happens if I switch to a different tty. The system still works though, I can blindly type in and run commands, but the monitor says there's no input.
journalctl -b output after suspend:
https://0x0.st/X6A2.txt
Xorg log after suspend:
http://0x0.st/X6A_.txt
Things I've tried so far:
- Several monitors and cables - I have tried three different monitors (one brand new) with four different cables (two HDMI, two VGA, two brand new), tried various different combinations between them, both single and dual screen setups
- Different kernels - tried linux-lts-6.6.54-1, linux-lts-6.6.36-1 and linux-6.11.2.arch1-1
- Uninstalling lightdm and starting X myself
- Uninstalling picom
- Manually adding i195 module to mkinitcpio.conf
- Turning the screen off before suspending with:
sleep 2; xset dpms force off; sleep 2; systemctl suspend
The problem still persisted.
Where do I continue troubleshooting from here?
P.S.
Another issue I have with a monitor with built-in speakers that might be related is, after the system has been suspend for a prolonged time, pulsemixer would show the HDMI audio output as off. But this might be unrelated and suitable for another topic.
Last edited by amth (2024-10-24 20:05:44)
Offline
oct 11 13:10:35 pc kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
oct 11 13:10:35 pc kernel: mei_pxp 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: bound 0000:00:02.0 (ops i915_pxp_tee_component_ops [i915])
systool -vm i915
modinfo i915 | grep parm
Do you still have an edid after the suspend?
for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done
You'll need https://aur.archlinux.org/packages/edid-decode-git
Offline
Do you still have an edid after the suspend?
I don't.
Output of
for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done
after boot:
http://0x0.st/X6SD.txt
And after suspend:
/sys/class/drm/card1
/sys/class/drm/card1/edid: No such file or directory
=================
/sys/class/drm/card1-DP-1
EDID of '/sys/class/drm/card1-DP-1/edid' was empty.
=================
/sys/class/drm/card1-HDMI-A-1
EDID of '/sys/class/drm/card1-HDMI-A-1/edid' was empty.
=================
Output of systool -vm i915:
Module = "i915"
Attributes:
coresize = "4157440"
initsize = "0"
initstate = "live"
refcnt = "8"
srcversion = "75812AE410FBFB9B267F396"
taint = ""
uevent = <store method only>
Parameters:
Sections:
The value of refcnt seems to change between 7 and 8.
Output of modinfo i915 | grep parm:
Offline
Does it help if you inject the edid into the system?
https://wiki.archlinux.org/title/Kernel … s_and_EDID
You can simply
cp /sys/class/drm/card1-HDMI-A-1/edid /usr/lib/firmware/edid/wtf.bin
Unfortunately, that doesn't explain why you're losing it itfp (nothing here does)
Are there any adpaters involved (I understand that you checked different monitors and cables, so the question is whether anything but the IGP remained static across your tests)
Offline
I tried to enforce the EDID file that I can get before suspending, as described in the Arch Wiki, with and without various combinations for output labels, but it didn't do anything.
I tried enforcing it with a Xorg configuration file too, still to no avail:
Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
Option "ConnectedMonitor" "HDMI-1"
Option "CustomEDID" "HDMI-1:/usr/lib/firmware/edid/edid.bin"
Option "IgnoreEDID" "false"
Option "UseEDID" "true"
EndSection
I haven't used any adapters, just plain male-to-male cables.
Meanwhile, to make sure there's nothing wrong with the current monitor, I tested it on a different machine with Arch system, albeit an older kernel (linux 6.1.46-1-lts), and there were no issues.
Offline
but it didn't do anything
The EDID should™ remain available now (as long as you added it via the kernel parameters)?
The xorg options you tried are afaict all nvidia specific
a different machine with Arch system, albeit an older kernel (linux 6.1.46-1-lts)
You can try some older live distro on the relevant system, but at least pxp has been introduced during the 5.x kernels, so I'd not hold my breath unless some regression was backported into the LTS kernel.
That being said, what happens if you simply blacklist mei_pxp and mei_hdcp (module_blacklist= on the commandline, make sure to only add or be able to revert that at the bootloader or get ready for having to fix this via ssh…)
Offline
The EDID file fails to load on boot.
journalctl - b | grep -i edid:
oct 13 19:59:30 pc kernel: Command line: BOOT_IMAGE=/vmlinuz-linux-lts root=UUID=ed8d4308-6635-466c-91e2-40c547606561 rw loglevel=3 quiet drm.edid_firmware=edid/edid.bin
oct 13 19:59:30 pc kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-linux-lts root=UUID=ed8d4308-6635-466c-91e2-40c547606561 rw loglevel=3 quiet drm.edid_firmware=edid/edid.bin
oct 13 19:59:30 pc kernel: i915 0000:00:02.0: Direct firmware load for edid/edid.bin failed with error -2
oct 13 19:59:30 pc kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:185:HDMI-A-1] Requesting EDID firmware "edid/edid.bin" failed (err=-2)
oct 13 19:59:30 pc kernel: i915 0000:00:02.0: Direct firmware load for edid/edid.bin failed with error -2
oct 13 19:59:30 pc kernel: i915 0000:00:02.0: [drm] *ERROR* [CONNECTOR:185:HDMI-A-1] Requesting EDID firmware "edid/edid.bin" failed (err=-2)
I can confirm the file is identical to /sys/class/drm/card1-HDMI-A-1/edid and /sys/devices/pci0000:00/0000:00:02.0/drm/card1/card1-HDMI-A-1/edid, which disappear after suspend.
At first I thought I have to specify the connector too in the parameter (drm.edid_firmware=HDMI-1:edid/edid.bin), as I found several examples doing that, which didn't give me any error, but it seems it had no effect at all. In fact, I can add gibberish as a connector name and nothing would happen.
Blacklisting mei_pxp and mei_hdcp had no effect either (I did confirm the blacklisting in the journal).
Offline
-2 is ENOENT, the file isn't there.
stat /usr/lib/firmware/edid/edid.bin
From the timestamps, you might also have to add it to the initramfs (because i915 is probably there)
Offline
The file is definitely there.
stat /usr/lib/firmware/edid/edid.bin:
File: /usr/lib/firmware/edid/edid.bin
Size: 256 Blocks: 8 IO Block: 4096 regular file
Device: 259,3 Inode: 8265572 Links: 1
Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-10-13 17:13:53.533356671 +0200
Modify: 2024-10-12 18:50:04.536740747 +0200
Change: 2024-10-13 02:04:25.163342731 +0200
Birth: 2024-10-12 18:50:04.536740747 +0200
And it's definitely the same as the pre-suspend edid. The following shows no differences:
diff <(xxd /sys/class/drm/card1-HDMI-A-1/edid) <(xxd /usr/lib/firmware/edid/edid.bin)
After adding /usr/lib/firmware/edid/edid.bin as a file in /etc/mkinitcpio.conf, I see no error in the journal. Can we presume it's available now?
But I don't see any changes with the issue. Adding i915 as a module in mkinitcpio.conf didn't do anything before nor after adding the edid file.
Offline
Can we presume it's available now?
Yup.
But I don't see any changes with the issue.
The edid should though remain available?
for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done
The i915 module most likely was in the initramfs, in doubt via the kms hook.
Another issue I have with a monitor with built-in speakers that might be related is, after the system has been suspend for a prolonged time, pulsemixer would show the HDMI audio output as off. But this might be unrelated and suitable for another topic.
Let's pretend that's rather cause than symptom.
oct 11 13:08:20 pc dbus-broker-launch[486]: Invalid user-name in /usr/share/dbus-1/system.d/pulseaudio-system.conf +27: user="pulse"
I cannot see any traces of either PA or PW in your journal, please post the output of
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
The try to blacklist snd_hda_intel…
module_blacklist=snd_hda_intel
Offline
The edid should though remain available?
Unfortunately, it doesn't where it matters.
As soon as I suspend the system and - pouf - it's gone. Or, to be more precise, /sys/class/drm/card1-HDMI-A-1/edid is empty and /sys/class/drm/card1-HDMI-A-1/status says "disconnected".
As for the secondary issue, I managed to replicate it. I noticed it happens after 1) the system has been suspended once (and all outputs say "disconnected") and then 2) the screen has been turned off again, be it manually with `xset dpms force off`, automatically from inactivity or from another system suspend. So I assume it's just a consequence of the main issue.
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f:
dbus-org.freedesktop.nm-dispatcher.service | system
display-manager.service | system
getty@tty1.service | getty.target.wants
NetworkManager.service | multi-user.target.wants
NetworkManager-wait-online.service | network-online.target.wants
p11-kit-server.socket | sockets.target.wants
pulseaudio.socket | sockets.target.wants
remote-fs.target | multi-user.target.wants
systemd-userdbd.socket | sockets.target.wants
This output remains the same for all the three states (pre-suspend, post-suspend and post-suspend-no-audio). There's nothing in the journal.
The try to blacklist snd_hda_intel…
Blacklisting this module didn't change anything either.
Offline
Consider replacing pulseaudio w/ pipewire and pipewire-pulse, but it would be almost freakish if the sound would driver the main issue, esp. wrt the snd_hda_blacklisting result.
What happens if you suspend the system, resume and then inject back the missing edid via the override and/or trigger the hotplug?
https://wiki.archlinux.org/title/Kernel … s_and_EDID (bottom of the paragraph)
Offline
Consider replacing pulseaudio w/ pipewire and pipewire-pulse, but it would be almost freakish if the sound would driver the main issue, esp. wrt the snd_hda_blacklisting result.
I don't think pulseaudio has anything to do with it, as the main issue persists with VGA connection too. In this case, as there's no audio signal to the monitor to be begin with, no matter how many times I suspend, the sink remains the same.
$ pactl info | grep -i sink
Default Sink: alsa_output.pci-0000_00_1f.3.analog-stereo
With HDMI, the sink changes from
alsa_output.pci-0000_00_1f.3.hdmi-stereo
to
alsa_output.pci-0000_00_1f.3.iec958-stereo
after the second time the screen turns off (including the initial suspend). I guess PA detects the HDMI connection as disconnected and automatically changes the sink, but I don't know at what point is this check made, since it doesn't happen with the first system wake-up.
What happens if you suspend the system, resume and then inject back the missing edid via the override and/or trigger the hotplug?
https://wiki.archlinux.org/title/Kernel … s_and_EDID (bottom of the paragraph)
Nothing.
I made sure the kernel is not in lockdown mode with
cat /sys/kernel/security/lockdown
then copied my edid with
cat /usr/lib/firmware/edid/edid.bin > /sys/kernel/debug/dri/1/HDMI-A-1/edid_override
then replugged the monitor, but the problems persisted.
I had to replug it manually as I couldn't manage to trigger a hotplug, got "permission denied". Maybe this monitor doesn't allow hotplugging?
Offline
echo 1 | sudo tee /sys/kernel/debug/dri/0/HDMI-A-2/trigger_hotplug
but that'll likely not help either.
I have tried three different monitors (one brand new) with four different cables (two HDMI, two VGA, two brand new)
So, the hdcp handshake is a notoriously fragile diva, but VGA is actually just copper - were those connections VGA-VGA w/ no adapter involved or was there a HDMI plug on one side?
Can you use displayport for the connection?
You can try some older live distro on the relevant system,
If you get https://grml.org and suspend the system there, do you get the same behavior?
Offline
So, the hdcp handshake is a notoriously fragile diva, but VGA is actually just copper - were those connections VGA-VGA w/ no adapter involved or was there a HDMI plug on one side?
Yes, I've only used VGA-VGA connections, without any adapters. The primary issue is the same as with the HDMI connection, HDMI only adds the additional audio issue.
Can you use displayport for the connection?
The motherboard has no DP connector. The DP-1 output xrandr shows is a stand in for the VGA port.
You can try some older live distro on the relevant system,
If you get https://grml.org and suspend the system there, do you get the same behavior?
I tried several live distros...
- Debian 12.7.0
$ uname -a
Linux debian 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64 GNU/Linux
$ inxi -G
Graphics:
Device-1: Intel RocketLake-S GT1 [UHD Graphics 730] driver: i915 v: kernel
Display: x11 server: X.org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X: loaded: modesetting
unloaded: fbdev,vesa dri: iris gpu: i915 tty: 159x45
API: OpenGL Message: GL data unavailable in console. Try -G --display
With this distro, the screen stayed black after waking up. It happens with both VGA and HDMI. I got some logs via ssh.
# journalctl -b (VGA):
http://0x0.st/XIbb.txt
# journalctl -b (HDMI):
http://0x0.st/XIb3.txt
$ cat /var/log/Xorg.0.log (VGA):
http://0x0.st/XIbA.txt
$ cat /var/log/Xorg.0.log (HDMI):
http://0x0.st/XIbg.txt
$ edid-decode /sys/class/drm/card0-DP-1/edid:
EDID of '/sys/class/drm/card0-DP-1/edid' was empty.
$ edid-decode /sys/class/drm/card0-HDMI-1/edid:
EDID of '/sys/class/drm/card0-HDMI-1/edid' was empty.
$ systool -vm i915:
Module = "i915"
Attributes:
coresize = "3055616"
initsize = "0"
initstate = "live"
refcnt = "14"
taint = ""
uevent = <store method only>
Parameters:
Sections:
# modinfo i915 | grep parm:
http://0x0.st/XIb1.txt
Values in both /sys/class/drm/card0-DP-1/ and /sys/class/drm/card0-HDMI-1/:
dpms - off
edid -
enabled - disabled
modes -
status - disconnected
uevent - DEVTYPE=drm_connector
- Grml
The behavior was the same as with my original Arch installation.
$ uname -a
Linux grml 6.6.15-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.15-2 (2024-02-04) x86_64 GNU/Linux
# journalctl -b:
http://0x0.st/XIcF.txt
$ systool -vm i915:
Module = "i915"
Attributes:
coresize = "3956736"
initsize = "0"
initstate = "live"
refcnt = "4"
taint = ""
uevent = <store method only>
Parameters:
Sections:
Values in both /sys/class/drm/card0-DP-1/ and /sys/class/drm/card0-HDMI-1/:
dpms - on
edid -
enabled - enabled
modes -
status - disconnected
uevent - DEVTYPE=drm_connector
- Manjaro 20.0.3 (XFCE)
Got stuck on boot, hanged on a blinking pointer before X could start, there was no response.
- Manjaro 24.0.5 (i3)
$ uname -a
Linux manjaro-i3 6.9.10-1-MANJARO #1 SMP PREEMPT_DYNAMIC Fri Jul 19 15:08:51 UTC 2024 x86_64 GNU/Linux
The behavior was the same as with my original Arch installation.
$ journalctl -b:
http://0x0.st/XIa2.bin
I saw no point in fetching any other logs, as they're the same.
- Arch (installed on a flesh drive)
uname - a
Linux arch-kingston 6.6.13-1-lts #1 SMP PREEMPT_DYNAMIC Sat, 20 Jan 2024 14:48:01 +0000 x86_64 GNU/Linux
The behavior was the same as with my original Arch installation. I saw no point in fetching any other logs, as they're the same.
This is an install without a display manager, and I noticed that if I suspend the system before manually starting X, the screen stays black after wake-up, like it did with Debian.
$ journalctl -b:
http://0x0.st/XIBM.txt
------------------------------
At this point I suspect it's a hardware issue. Maybe damaged motherboard or CPU? Is there a way to determine this? And, more importantly, to find a workaround?
EDIT:
The issue is gone if I change the suspend method from deep to s2idle with
# echo s2idle > /sys/power/mem_sleep
However, I would really prefer the deep suspend, as s2idle keeps CPU and PSU fans running.
Last edited by amth (2024-10-17 00:02:53)
Offline
At this point I suspect it's a hardware issue. Maybe damaged motherboard or CPU?
If it wa damaged, I'd not expect this to be related to the S3 but from the get-go.
Is there a way to determine this?
Windows behavior.
And, more importantly, to find a workaround?
then replugged the monitor, but the problems persisted
This suggests the problem is w/ the IGP, not the output.
Try passing
i915.enable_dc=0 i915.enable_fbc=0 i915.disable_power_well=0
Offline
The issue still persisted with the following combination of options:
i915.enable_dc=0 i915.enable_fbc=0 i915.disable_power_well=0
I realized I haven't properly posted all the default options for i915. Not sure which are worth (and safe) trying to mess with:
# systool -m i915 -av
Module = "i915"
Attributes:
coresize = "4157440"
initsize = "0"
initstate = "live"
refcnt = "8"
srcversion = "75812AE410FBFB9B267F396"
taint = ""
uevent = <store method only>
Parameters:
disable_display = "N"
disable_power_well = "-1"
dmc_firmware_path = "(null)"
edp_vswing = "0"
enable_dc = "-1"
enable_dp_mst = "Y"
enable_dpcd_backlight= "-1"
enable_dpt = "Y"
enable_fbc = "-1"
enable_guc = "-1"
enable_gvt = "N"
enable_hangcheck = "Y"
enable_ips = "1"
enable_psr2_sel_fetch= "Y"
enable_psr = "-1"
enable_sagv = "Y"
error_capture = "Y"
fastboot = "-1"
force_probe = "*"
force_reset_modeset_test= "N"
gsc_firmware_path = "(null)"
guc_firmware_path = "(null)"
guc_log_level = "-1"
huc_firmware_path = "(null)"
invert_brightness = "0"
lmem_bar_size = "0"
lmem_size = "0"
load_detect_test = "N"
lvds_channel_mode = "0"
memtest = "N"
mitigations = "auto"
mmio_debug = "0"
modeset = "-1"
nuclear_pageflip = "N"
panel_use_ssc = "-1"
psr_safest_params = "N"
request_timeout_ms = "20000"
reset = "3"
vbt_firmware = "(null)"
vbt_sdvo_panel_type = "-1"
verbose_state_checks= "Y"
Sections:
.altinstr_aux = "0xffffffffc057c688"
.altinstr_replacement= "0xffffffffc057c43a"
.altinstructions = "0xffffffffc06591f8"
.bss = "0xffffffffc059ae00"
.call_sites = "0xffffffffc06ffd0a"
.data..read_mostly = "0xffffffffc0595ec0"
.data.once = "0xffffffffc0595e50"
.data = "0xffffffffc058cb00"
.exit.data = "0xffffffffc0595f90"
.exit.text = "0xffffffffc057c3d0"
.gnu.linkonce.this_module= "0xffffffffc059a8c0"
.ibt_endbr_seal = "0xffffffffc071dd2e"
.init.data = "0xffffffffc07a7000"
.init.text = "0xffffffffc0215000"
.note.Linux = "0xffffffffc07a4db4"
.note.gnu.build-id = "0xffffffffc07a4d90"
.note.gnu.property = "0xffffffffc07a4d50"
.orc_header = "0xffffffffc07a52c0"
.orc_unwind = "0xffffffffc071fe52"
.orc_unwind_ip = "0xffffffffc076fa84"
.parainstructions = "0xffffffffc06f3cc8"
.printk_index = "0xffffffffc0594030"
.ref.data = "0xffffffffc05966c0"
.retpoline_sites = "0xffffffffc06f45f2"
.return_sites = "0xffffffffc06fa682"
.rodata = "0xffffffffc0659be0"
.rodata.cst2 = "0xffffffffc06f3fa8"
.rodata.str1.1 = "0xffffffffc06e4f6c"
.rodata.str1.8 = "0xffffffffc06a7c10"
.smp_locks = "0xffffffffc06e39dc"
.static_call.text = "0xffffffffc057c6c0"
.static_call_sites = "0xffffffffc05985d0"
.strtab = "0xffffffffc080e3b8"
.symtab = "0xffffffffc07a7008"
.text = "0xffffffffc03af000"
__bpf_raw_tp_map = "0xffffffffc0595fe0"
__bug_table = "0xffffffffc057e000"
__dyndbg_classes = "0xffffffffc0595f98"
__ex_table = "0xffffffffc06f3fb4"
__jump_table = "0xffffffffc0212000"
__ksymtab_gpl = "0xffffffffc0659000"
__ksymtab_strings = "0xffffffffc07a4de4"
__mcount_loc = "0xffffffffc069dbec"
__param = "0xffffffffc06f3660"
__patchable_function_entries= "0xffffffffc0582588"
__tracepoints_ptrs = "0xffffffffc06f405c"
__tracepoints_strings= "0xffffffffc06f4120"
__tracepoints = "0xffffffffc0597560"
_ftrace_events = "0xffffffffc0596560"
$ modinfo -p i915
modeset:Use kernel modesetting [KMS] (0=disable, 1=on, -1=force vga console preference [default]) (int)
enable_dc:Enable power-saving display C-states. (-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6; 3=up to DC5 with DC3CO; 4=up to DC6 with DC3CO) (int)
enable_fbc:Enable frame buffer compression for power savings (default: -1 (use per-chip default)) (int)
lvds_channel_mode:Specify LVDS channel mode (0=probe BIOS [default], 1=single-channel, 2=dual-channel) (int)
panel_use_ssc:Use Spread Spectrum Clock with panels [LVDS/eDP] (default: auto from VBT) (int)
vbt_sdvo_panel_type:Override/Ignore selection of SDVO panel mode in the VBT (-2=ignore, -1=auto [default], index in VBT BIOS table) (int)
reset:Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset [default]) (uint)
vbt_firmware:Load VBT from specified file under /lib/firmware (charp)
error_capture:Record the GPU state following a hang. This information in /sys/class/drm/card<N>/error is vital for triaging and debugging hangs. (bool)
enable_hangcheck:Periodically check GPU activity for detecting hangs. WARNING: Disabling this can cause system wide hangs. (default: true) (bool)
enable_psr:Enable PSR (0=disabled, 1=enable up to PSR1, 2=enable up to PSR2) Default: -1 (use per-chip default) (int)
psr_safest_params:Replace PSR VBT parameters by the safest and not optimal ones. This is helpful to detect if PSR issues are related to bad values set in VBT. (0=use VBT parameters, 1=use safest parameters) (bool)
enable_psr2_sel_fetch:Enable PSR2 selective fetch (0=disabled, 1=enabled) Default: 0 (bool)
enable_sagv:Enable system agent voltage/frequency scaling (SAGV) (default: true) (bool)
force_probe:Force probe options for specified supported devices. See CONFIG_DRM_I915_FORCE_PROBE for details. (charp)
disable_power_well:Disable display power wells when possible (-1=auto [default], 0=power wells always on, 1=power wells disabled when possible) (int)
enable_ips:Enable IPS (default: true) (int)
enable_dpt:Enable display page table (DPT) (default: true) (bool)
fastboot:Try to skip unnecessary mode sets at boot time (0=disabled, 1=enabled) Default: -1 (use per-chip default) (int)
load_detect_test:Force-enable the VGA load detect code for testing (default:false). For developers only. (bool)
force_reset_modeset_test:Force a modeset during gpu reset for testing (default:false). For developers only. (bool)
invert_brightness:Invert backlight brightness (-1 force normal, 0 machine defaults, 1 force inversion), please report PCI device ID, subsystem vendor and subsystem device ID to dri-devel@lists.freedesktop.org, if your machine needs it. It
will then be included in an upcoming module version. (int)
disable_display:Disable display (default: false) (bool)
memtest:Perform a read/write test of all device memory on module load (default: off) (bool)
mmio_debug:Enable the MMIO debug code for the first N failures (default: off). This may negatively affect performance. (int)
verbose_state_checks:Enable verbose logs (ie. WARN_ON()) in case of unexpected hw state conditions. (bool)
nuclear_pageflip:Force enable atomic functionality on platforms that don't have full support yet. (bool)
edp_vswing:Ignore/Override vswing pre-emph table selection from VBT (0=use value from vbt [default], 1=low power swing(200mV),2=default swing(400mV)) (int)
enable_guc:Enable GuC load for GuC submission and/or HuC load. Required functionality can be selected using bitmask values. (-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load) (int)
guc_log_level:GuC firmware logging level. Requires GuC to be loaded. (-1=auto [default], 0=disable, 1..4=enable with verbosity min..max) (int)
guc_firmware_path:GuC firmware path to use instead of the default one (charp)
huc_firmware_path:HuC firmware path to use instead of the default one (charp)
dmc_firmware_path:DMC firmware path to use instead of the default one (charp)
gsc_firmware_path:GSC firmware path to use instead of the default one (charp)
enable_dp_mst:Enable multi-stream transport (MST) for new DisplayPort sinks. (default: true) (bool)
enable_dpcd_backlight:Enable support for DPCD backlight control(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 1=enable, 2=force VESA interface, 3=force Intel interface) (int)
enable_gvt:Enable support for Intel GVT-g graphics virtualization host support(default:false) (bool)
request_timeout_ms:Default request/fence/batch buffer expiration timeout. (uint)
lmem_size:Set the lmem size(in MiB) for each region. (default: 0, all memory) (uint)
lmem_bar_size:Set the lmem bar size(in MiB). (uint)
mitigations:Selectively enable security mitigations for all Intel® GPUs in the system.
auto -- enables all mitigations required for the platform [default]
off -- disables all mitigations
Individual mitigations can be enabled by passing a comma-separated string,
e.g. mitigations=residuals to enable only clearing residuals or
mitigations=auto,noresiduals to disable only the clear residual mitigation.
Either '!' or 'no' may be used to switch from enabling the mitigation to
disabling it.
Active mitigations for Ivybridge, Baytrail, Haswell:
residuals -- clear all thread-local registers between contexts
Offline
Those options aren't applied in the posted systool output?
Offline
No, that's just the default systool output without any i915 module options passed as kernel parameters.
Once I applied the power related options, their values were changed as expected.
$ journalctl -b | grep i915
oct 19 20:58:49 pc kernel: Command line: BOOT_IMAGE=/vmlinuz-linux-lts root=UUID=ed8d4308-6635-466c-91e2-40c547606561 rw loglevel=3 quiet drm.edid_firmware=edid/edid.bin i915.enable_dc=0 i915.enable_fbc=0 i915.disable_power_well=0
oct 19 20:58:49 pc kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-linux-lts root=UUID=ed8d4308-6635-466c-91e2-40c547606561 rw loglevel=3 quiet drm.edid_firmware=edid/edid.bin i915.enable_dc=0 i915.enable_fbc=0 i915.disable_power_well=0
oct 19 20:58:49 pc kernel: i915 0000:00:02.0: vgaarb: deactivate vga console
oct 19 20:58:49 pc kernel: i915 0000:00:02.0: [drm] Using Transparent Hugepages
oct 19 20:58:49 pc kernel: i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem
oct 19 20:58:49 pc kernel: i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/rkl_dmc_ver2_03.bin (v2.3)
oct 19 20:58:49 pc kernel: i915 0000:00:02.0: [drm] Protected Xe Path (PXP) protected content support initialized
oct 19 20:58:49 pc kernel: [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 1
oct 19 20:58:49 pc kernel: fbcon: i915drmfb (fb0) is primary device
oct 19 20:58:49 pc kernel: i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
oct 19 20:58:49 pc kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
oct 19 20:58:49 pc kernel: mei_pxp 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: bound 0000:00:02.0 (ops i915_pxp_tee_component_ops [i915])
oct 19 20:58:49 pc kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
# systool -m i915 -av
Module = "i915"
Attributes:
coresize = "4157440"
initsize = "0"
initstate = "live"
refcnt = "8"
srcversion = "75812AE410FBFB9B267F396"
taint = ""
uevent = <store method only>
Parameters:
disable_display = "N"
disable_power_well = "0"
dmc_firmware_path = "(null)"
edp_vswing = "0"
enable_dc = "0"
enable_dp_mst = "Y"
enable_dpcd_backlight= "-1"
enable_dpt = "Y"
enable_fbc = "0"
enable_guc = "-1"
enable_gvt = "N"
enable_hangcheck = "Y"
enable_ips = "1"
enable_psr2_sel_fetch= "Y"
enable_psr = "-1"
enable_sagv = "Y"
error_capture = "Y"
fastboot = "-1"
force_probe = "*"
force_reset_modeset_test= "N"
gsc_firmware_path = "(null)"
guc_firmware_path = "(null)"
guc_log_level = "-1"
huc_firmware_path = "(null)"
invert_brightness = "0"
lmem_bar_size = "0"
lmem_size = "0"
load_detect_test = "N"
lvds_channel_mode = "0"
memtest = "N"
mitigations = "auto"
mmio_debug = "0"
modeset = "-1"
nuclear_pageflip = "N"
panel_use_ssc = "-1"
psr_safest_params = "N"
request_timeout_ms = "20000"
reset = "3"
vbt_firmware = "(null)"
vbt_sdvo_panel_type = "-1"
verbose_state_checks= "Y"
Sections:
.altinstr_aux = "0xffffffffc056d688"
.altinstr_replacement= "0xffffffffc056d43a"
.altinstructions = "0xffffffffc064a1f8"
.bss = "0xffffffffc058be00"
.call_sites = "0xffffffffc06f0d0a"
.data..read_mostly = "0xffffffffc0586ec0"
.data.once = "0xffffffffc0586e50"
.data = "0xffffffffc057db00"
.exit.data = "0xffffffffc0586f90"
.exit.text = "0xffffffffc056d3d0"
.gnu.linkonce.this_module= "0xffffffffc058b8c0"
.ibt_endbr_seal = "0xffffffffc070ed2e"
.init.data = "0xffffffffc0798000"
.init.text = "0xffffffffc025f000"
.note.Linux = "0xffffffffc0795db4"
.note.gnu.build-id = "0xffffffffc0795d90"
.note.gnu.property = "0xffffffffc0795d50"
.orc_header = "0xffffffffc07962c0"
.orc_unwind = "0xffffffffc0710e52"
.orc_unwind_ip = "0xffffffffc0760a84"
.parainstructions = "0xffffffffc06e4cc8"
.printk_index = "0xffffffffc0585030"
.ref.data = "0xffffffffc05876c0"
.retpoline_sites = "0xffffffffc06e55f2"
.return_sites = "0xffffffffc06eb682"
.rodata = "0xffffffffc064abe0"
.rodata.cst2 = "0xffffffffc06e4fa8"
.rodata.str1.1 = "0xffffffffc06d5f6c"
.rodata.str1.8 = "0xffffffffc0698c10"
.smp_locks = "0xffffffffc06d49dc"
.static_call.text = "0xffffffffc056d6c0"
.static_call_sites = "0xffffffffc05895d0"
.strtab = "0xffffffffc07ff3b8"
.symtab = "0xffffffffc0798008"
.text = "0xffffffffc03a0000"
__bpf_raw_tp_map = "0xffffffffc0586fe0"
__bug_table = "0xffffffffc056f000"
__dyndbg_classes = "0xffffffffc0586f98"
__ex_table = "0xffffffffc06e4fb4"
__jump_table = "0xffffffffc025c000"
__ksymtab_gpl = "0xffffffffc064a000"
__ksymtab_strings = "0xffffffffc0795de4"
__mcount_loc = "0xffffffffc068ebec"
__param = "0xffffffffc06e4660"
__patchable_function_entries= "0xffffffffc0573588"
__tracepoints_ptrs = "0xffffffffc06e505c"
__tracepoints_strings= "0xffffffffc06e5120"
__tracepoints = "0xffffffffc0588560"
_ftrace_events = "0xffffffffc0587560"
Offline
What if you cut out the firmware: "i915.enable_guc=0"?
https://wiki.archlinux.org/title/Intel_ … re_loading
Do you have the opportunity to test the HW on windows to rule out HW issues?
Oct 16 11:45:31 localhost.localdomain kernel: DMI: ASUS System Product Name/PRIME H510M-K R2.0, BIOS 0806 08/07/2023
And are there BIOS updates available for the system?
Offline
What if you cut out the firmware: "i915.enable_guc=0"?
https://wiki.archlinux.org/title/Intel_ … re_loading
Trying out all the different values for enable_guc didn't change anything.
Oct 16 11:45:31 localhost.localdomain kernel: DMI: ASUS System Product Name/PRIME H510M-K R2.0, BIOS 0806 08/07/2023
And are there BIOS updates available for the system?
Updated BIOS to the latest version, the problem persisted.
$ journalctl -b | grep -i bios
...
Oct 21 20:18:32 pc kernel: DMI: ASUS System Product Name/PRIME H510M-K R2.0, BIOS 1001 12/14/2023
...
Do you have the opportunity to test the HW on windows to rule out HW issues?
I installed a HDD from another machine I have which dual-boots Arch and Windows 10, however it turns out UEFI bootloader doesn't recognize Windows if it's been installed in legacy BIOS mode.
The Arch system with kernel 6.1.46-1-lts did boot and the problem persists there, but I have already tested that same kernel before.
Now my next step would be to install Windows on the current disk and dual boot, but I'm not sure if it's worth the risk, what could I found out and where would I go next with that information?
Offline
Okay, I think the issue is gone now.
It turns out all I had to do was force HDMI to be enabled and use the digital output with `video=HDMI-A-1:D` as kernel parameter and value.
From https://docs.kernel.org/fb/modedb.html:
...‘D’ will force the display to be enabled and use digital output. This is useful for outputs that have both analog and digital signals (e.g. HDMI and DVI-I). For other outputs it behaves like ‘e’...
$ journalctl -b | grep -i hdmi
oct 22 16:10:41 pc kernel: Command line: BOOT_IMAGE=/vmlinuz-linux-lts root=UUID=ed8d4308-6635-466c-91e2-40c547606561 rw loglevel=3 quiet video=HDMI-A-1:D
oct 22 16:10:41 pc kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-linux-lts root=UUID=ed8d4308-6635-466c-91e2-40c547606561 rw loglevel=3 quiet video=HDMI-A-1:D
oct 22 16:10:41 pc kernel: [drm] forcing HDMI-A-1 connector on
oct 22 16:10:41 pc kernel: input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input15
oct 22 16:10:41 pc kernel: input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input16
oct 22 16:10:41 pc kernel: input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input17
oct 22 16:10:41 pc kernel: input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input18
Xrandr gives the expected output now, and all programs seem to work as intended. Obviously, the secondary issue with audio over HDMI is gone too.
I still don't understand why the connection was getting lost in the first place and whether this has to be done on kernel boot.
If everything works well and I notice no other issues for the next couple of days, I'm gonna mark this thread as solved. Thank you @seth for helping.
Last edited by amth (2024-10-22 15:38:51)
Offline
\o/
The output will unregister w/ the sleep and either not return or get into a race condition during the wakeup.
You're essentially telling the system to consider it there regardless of the detection - it'll be "available" even if you physically detach it.
Offline