[BUG] sof-firmware prevents suspension [hda_dsp_dais_suspend] #7094
Comments
|
@davix3f can you provide the dmesg of the sound driver loading after boot. This will provide FW version, topology used and any details from the audio device initialization. This looks like the sound server is trying to open the PCM on iDisp3 which may not exist ? |
|
@davix3f, it might be a complicated thing with NVIDIA binary drivers, but can you try to revert to an older kernel version? I only have one machine with NVIDIA gfx, running Artix (Arch based w/o systemd): I'm yet to get the 6.1.11 kernel update... |
|
Fetched, compiled and installed stable-6.1.11, everything looks normal on my device (I'm also using KDE Plasma X11) @davix3f, you were saying that this issue started after the latest update, right? Can you pin-point what else got updated in between? pipewire, wireplumber, alsa-lib, alsa-utils, alsa-ucm-conf, alsa-card-profiles, NVIDIA binary (or are you using nouveau?) comes to mind. |
Sure. I think it's this line? I will also attach a dmesg.log file right after boot, I think it's better than of copypasting it, if you might need any more info from it.
Pipewire, alsa-stuff, and nvidia-dkms have been upgraded, since january 2023, but not from one major version to the other. Wireplumber does not appear in the pacman logs in the period when I discovered this issue, which is from Jan 23rd to Feb 10th (I did not upgrade my system in between those two dates because I did not use my arch partition - I had to do a 3gb upgrade from pacman on Feb 10th). |
I will try, I'm using nvidia-dkms instead of nvidia binary, should be fine. I will report back. UPDATE EDIT:I installed linux-lts (which is at 5.15.93-1). Issue persists, dmesg logs below. |
|
@davix3f, you are using pipewire-media-session as session manager for pipewire? I suppose you have pipewire-pulse and the others installed and no PA around, right? |
No, I don't have pipewire-media-session. pacman -Q | grep -E .*wire pacman -Q | grep alsa pacman -Q | grep pulse |
|
@davix3f Looks like the same issue as thesofproject/linux#4151 to me. PipeWire is trying to use HDMI/DP devices that are not functional and there's a DMA stream_tag leak in the SOF driver, fixed with thesofproject/linux#4155 @ujfalusi probably something to send upstream and CC: stable? |
Is there anything I can do on my system to patch this, or I simply wait for the next release? |
|
@davix3f if you have the ability to recompile your kernel, sure you can apply the commit in thesofproject/linux#4155. it's just moving one block of code around. |
That does not apply at all on upstream it is depending on the HDA DAI abstraction (and might be introduced by it?), not going to send it within 5 minutes... |
|
@ujfalusi it's always been there, the issue is that PipeWire started using devices that are not functional, so that impacts all kernels since probably 5.7 |
Right, for me PW is not doing that for some reason, but I did saw it on other device where it did. |
I'm using the linux package provided by arch, kernel compiling really is not for me. I will wait for an update. Thank you all for your time and assistance, keep up the great work 🆒 |
|
First baby step towards 6.1 stable: https://lore.kernel.org/alsa-devel/20230216144054.26203-1-peter.ujfalusi@linux.intel.com/ It will take some time, but it will show up soon. |
|
@davix3f, meanwhile can you try to roll back pipewire to an older version? This started to happen for you after an update, there must be something which can mitigate it while the fix is on it's way. |
I tried to rollback pipewire, but a bunch of libraries and programs require the last version, and trying to roll those back will yield other libraries and utilities and so on. I will just bear with it until this gets patched with some update in arch packages, ssd+linux means a boot fast enought that it's not really an issue |
|
@davix3f, interesting, I don't think anything would have hard dependency on the PW version, but I have not tried to downgrade, so, who knows? anyhow, the fix from @plbossart landed in mainline and I just sent a backport patch to stable: https://lore.kernel.org/stable/20230220111658.32256-1-peter.ujfalusi@linux.intel.com/ I really hope it is going to land in Arch soon and it is going to fix the issue for you! (Along with packports to LTS versions) |
|
Updated from linux version 6.1.14 to 6.2.1 today, and the problem seems to be fixed. But as I said, the issue with the suspension seems to be fixed. |
|
Also got this problem but on This solution described here (in russian). |
Describe the bug
A clear and concise description of what the bug is.
What have you tried to diagnose or workaround this issue?
I'm running Arch Linux on a HP Omen gaming laptop. Everything's been fine until I updated a couple of days ago and noticed that the laptop won't suspend anymore [Did I try rolling back the sof-firmware package? Yes I did, the issue persisted]. Looking at dmesg, the cause of this seems to be sof-firmware / snd_hda_intel / sof-audio-pci-intel-cnl. The issue does not happen when I remove the package sof-firmware, but then I have no working audio.
DMESG output right after boot:
I have no idea what these errors are about, but my audio works fine. But maybe they're related to the issue? I don't know, really.
When I issue the suspend command, this is the output from DMESG:
Workarounds I tried:
I tried:
downgrade: no effect on the issueTo Reproduce
Suspend using
systemctl suspendor from the graphical interface dedicated command.Reproduction Rate
Always
Expected behavior
The laptop should suspend just fine, without being resumed immediately because of soundcard failing to suspend
Impact
I can't suspend my laptop in any way. It's not terrible, but it's pretty annoying.
Environment
Arch Linux with systemd
KDE Plasma X11
Kernel: 6.1.11-arch1-1
Platform: x86_64
Output of
inxi -A:LMK if I missed some informations that can help to fix this
The text was updated successfully, but these errors were encountered: