On 8/31/2025 5:12 AM, Przemysław Kopa wrote:
Hello,
I'm running Radeon RX 9060 XT and since upgrading to the kernel 6.15 I'm
facing an issue with audio via DisplayPort. After waking from S3 suspend
(sometimes, but not always) audio doesn't work - pavucontrol shows that
the output is disconnected and I don't get sound from my display. If I
manually reselect the Digital/HDMI output in pavucontrol after resume,
sound starts working again. Besides my main screen, GPU is also
connected (via HDMI) to a TV set - I've found out that this issue occurs
more often if the TV is on (not displaying output from GPU) when I put
my PC to sleep and I turn the TV off before resuming PC.
The issue persists on the current mainline kernel (6.17-rc3).
I've bisected it and this is the commit that introduced the issue:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=50e0bae34fa6b8b18e13473ddf0bcdab6ab68310
I've also found a similar report on the alsa mailing list:
https://lore.kernel.org/alsa-devel/1855350181c58300-webhooks-...@alsa-project.org/
I'm running Arch Linux with pipewire and wireplumber. The following is
an excerpt from the WirePlumber log after bad resume:
D spa.alsa [alsa-util.c:1996:pa_alsa_get_hdmi_eld]: ELD info empty (for
device=7)
I spa.alsa [alsa-acp-device.c:893:card_props_changed]: card properties changed
D spa.alsa [acp.c:760:report_jack_state]: Jack 'HDMI/DP,pcm=7 Jack' is now
unplugged
I spa.alsa [alsa-acp-device.c:975:card_port_available]: card port hdmi-output-1
available yes -> no
I spa.alsa [acp.c:702:profile_set_available]: Profile output:hdmi-stereo-extra1
available yes -> no
I spa.alsa [alsa-acp-device.c:941:card_profile_available]: card profile
output:hdmi-stereo-extra1 available yes -> no
Please let me know what additional information I might provide to
pinpoint this issue.
Thanks,
Przemysław Kopa
Given it's not a 100% reproduce for you, how did you confirm this commit
is causing the issue? Some sort of sampling of X cycles at each bisect
point?
Could you capture a dmesg log where /sys/power/pm_debug_messages is set
both from a good case and from a bad case so we can compare?
The peculiar thing is this commit only changes the timing of some of the
suspend sequence, and as part of the suspend sequence the GPU is reset
anyway. So during the resume sequence it shouldn't have mattered what
happened the last time on suspend entry.
Thanks,
