Dell XPS 14 DA14260 (Panther Lake, 1028:0db9): DSP error when unsuspending

[AndreasBackx]

Summary

Follow-up to the conversation from thesofproject/linux#5725 (comment)

A DSP boot error got triggered after coming back from suspension. I haven't been able trigger the same issue again, even after going in and out of suspense multiple times with the same configuration.

Hardware

• Laptop: Dell XPS 14 DA14260

➜ lspci -nnk | rg -A3 -i "audio|multimedia"
00:05.0 Multimedia controller [0480]: Intel Corporation Panther Lake IPU [8086:b05d] (rev 04)
        Subsystem: Dell Device [1028:0db9]
        Kernel driver in use: intel-ipu7
        Kernel modules: intel_ipu7
--
00:1f.3 Audio device [0403]: Intel Corporation Device [8086:e428] (rev 01)
        Subsystem: Dell Device [1028:0db9]
        Kernel driver in use: sof-audio-pci-intel-ptl
        Kernel modules: snd_sof_pci_intel_ptl, snd_hda_intel
00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:e422] (rev 01)
        Subsystem: Dell Device [1028:0db9]

Software

• Distro: Fedora 43
• Kernel: 7.0.0-0.rc7.260407.bfe62a45.254.vanilla.fc43.x86_64
• Firmware/BIOS:
  • current according to fwupdmgr

Last Known Trigger

• Closing the laptop and letting it enter suspense
• Opening it again to unsuspend
• DSP Boot Error

System logs: https://gist.github.com/AndreasBackx/037f185192bdb29571d9399f174da92f

I've included some context around, let me know if I missed anything.

[ujfalusi]

@AndreasBackx, thank you for the logs.
There seams to be a firmware crash happening:

Apr 08 16:29:16 fedora kernel: sof-audio-pci-intel-ptl 0000:00:1f.3: ------------[ DSP dump start ]------------
Apr 08 16:29:16 fedora kernel: sof-audio-pci-intel-ptl 0000:00:1f.3: DSP panic!
Apr 08 16:29:16 fedora kernel: sof-audio-pci-intel-ptl 0000:00:1f.3: fw_state: SOF_FW_BOOT_COMPLETE (7)
Apr 08 16:29:16 fedora kernel: sof-audio-pci-intel-ptl 0000:00:1f.3: 0x50000005: module: ROM_EXT, state: FW_ENTERED, running
Apr 08 16:29:16 fedora kernel: sof-audio-pci-intel-ptl 0000:00:1f.3: Firmware state: 0x5, status/error code: 0x0
Apr 08 16:29:16 fedora kernel: sof-audio-pci-intel-ptl 0000:00:1f.3: Core dump is not available due to invalid separator 0xc0de
Apr 08 16:29:16 fedora kernel: sof-audio-pci-intel-ptl 0000:00:1f.3: ------------[ DSP dump end ]------------
Apr 08 16:29:17 fedora kernel: sof-audio-pci-intel-ptl 0000:00:1f.3: ipc timed out for 0xe030500|0x300
Apr 08 16:29:17 fedora kernel: sof-audio-pci-intel-ptl 0000:00:1f.3: ------------[ IPC dump start ]------------
Apr 08 16:29:17 fedora pipewire[4638]: spa.alsa: hw:sofsoundwire,7p: snd_pcm_start: Connection timed out
Apr 08 16:29:17 fedora kernel: sof-audio-pci-intel-ptl 0000:00:1f.3: Host IPC initiator: 0x8e030500|0x300|0x0, target: 0x1b0a0000|0x0|0x0, ctl: 0x3
Apr 08 16:29:17 fedora pipewire[4638]: spa.alsa: hw:sofsoundwire,6p: snd_pcm_prepare error: No such device
Apr 08 16:29:17 fedora kernel: sof-audio-pci-intel-ptl 0000:00:1f.3: ------------[ IPC dump end ]------------

It happened in response to the 0xe030500|0x300 IPC message, which is a CHAIN_DMA start, with host DMA ID of 0, and Link DMA ID of 5.

I believe you have external display connected with audio capabilities?
This disparity between host and link DMA id is really suspicious and not expected at all, if you could add the dyndbg.conf file and reproduce the issue.
It might be that you need to close the lid while audio is playing to the HDMI or to speaker.
I will try to reproduce this, but something is not quite right here (installed the latest mainline at 7f87a5ea75f0, few commits ahead of bfe62a454542), so far I cannot.

Btw, if you stop all audio and let pipewire to close the card, will audio recover? I think it should eventually.

FYI, @kv2019i , @bardliao

[AndreasBackx]

I believe you have external display connected with audio capabilities?

No, but there was music playing via AirPlay which might be it instead? Or maybe Bluetooth, but pretty sure I had AirPlay playing.

Will try to reproduce this later today for you. Though I'm currently visiting family for a week so don't have the exact same environment, but I'll try my best.

Thanks again for the fantastically quick responses here!

[AndreasBackx]

can you open a new issue for the DSP boot error, it is really concerning and so far we have not seen similar issue.
From the logs it appears that enabling the DSP fails on your system and pipewire enters an endless loop of trying to use audio - which fails constantly.
For this please copy sof-dyndbg.conf.txt as /etc/modprobe.d/sof-dyndbg.conf reboot and attach the full kernel boot log and it would help to capture the log corresponding to the event itself (open terminal, make it unlimited history, run dmesg -w, close the lid, open the lid and if the error appears, save the captured kernel log).

• From Dell XPS 14 DA14260 (Panther Lake, 1028:0db9): speakers use default SoundWire machine driver and sound quality is tinny linux#5725 (comment)

Boot logs before closing/opening lid:

https://gist.github.com/AndreasBackx/d14f422f9f0b27574c51ec5ed843b5e1

So I managed to reproduce it the first try but I did not even need to have AirPlay output. I just had sound playing from a YouTube video as I closed the lid.

Here are the full logs from boot to after closing/opening the lid: https://gist.github.com/AndreasBackx/dcde02fbd8a4fdfa91a65e5e5bd5081a

I see that pipewire is 1.4.11, I wonder if you also hit by the xrun issue that can happen with pre 1.6.0 pipewire (which have SOF specific headroom configuration).
Can you try the workaround in thesofproject/linux#5284 (comment) and see if it can fix the DSP power issue?

Let me give this a try next.

[AndreasBackx]

Can you try the workaround in thesofproject/linux#5284 (comment) and see if it can fix the DSP power issue?

So I configured it, rebooted it, and it seems to resolve it, it might however also mean that I was very unlucky in triggering it last time because I've not been able to trigger it before (though not with exactly the same way of triggering).

Strangely though, the first time I closed the lid, it seemed to work and just continue playing back the YouTube video on resume, though it did not suspend the next few times I closed the lid. Waiting a minute or so and then trying to close the lid, did make it suspend as expected again. Not sure if this is expected behaviour or not so I thought to mention it.

Here are the logs: https://gist.github.com/AndreasBackx/a2bd737193aa344a4311288a5e2952fe

[ujfalusi]

@AndreasBackx, which fedora flavor you are using? GNOME or KDE or something else? I have been trying to reproduce the issue on Artix Linux for a week now running KDE, but so far no idea what is going wrong.

If you could keep the dyndbg enabled on your system and if the issue happens save and share the kernel log then it might contain some hints for me to start from.

Sorry for the delay.

[AndreasBackx]

@ujfalusi I'm using the Fedora Gnome flavour, though am using Hyprland.

If you could keep the dyndbg enabled on your system and if the issue happens save and share the kernel log then it might contain some hints for me to start from.

I think the issue is resolved with the mentioned workaround. I don't remember facing it since. Though I might also be forgetful. If I face it again, I'll definitely post more info here, dyndbg is still on.

Sorry for the delay.

Relax 😅, I am already very grateful for the great help here. Thank you. ❤️

[AndreasBackx]

Well... speaking of the devil. Just as I post the aforementioned thing, I do get the issue, or at least a similar issue. I closed my lid with music playing and when opening again, it started stuttering and my system logs were getting absolutely spammed. Here are the logs: https://gist.github.com/AndreasBackx/7e4c467235e8b4aefc70cf6a9d62143d

I think that might be truncated because wc -l says there were 311k lines though I bet that it contained a ton of duplicate lines as well. Let mw know if this is useful though. These logs were filtered on "sof".

[ujfalusi]

@AndreasBackx , this looks like to be the thesofproject/linux#5284, but things are odd:
Around Apr 24 23:18:23 something (pipewire?) starts audio on Speaker, Jack Out, HDMIA1/2/3 playback and Microphone capture
Around Apr 24 23:23:49 is the time when all 6 running audio stream receives the SUSPEND trigger, lid closed?
Right away I see (same timestamp Apr 24 23:23:49) that all 6 stream receives the start trigger and then one by one they are stopped, restarted, stopped, restarted in an endless loop, this is the signature of the xrun loop.

If you still have the unfiltered log that might give some hint of why the suspend seemingly failed and could provide addition detail.
The obviously curious thing is why PW opens every stream before system suspend - if it is connected to that event, why it opens HDMI audio when you said that you don't have external monitor connected - PW should ignore HDMI in this case).

The other curious thing is why the headroom does not help in your case. Can you run pw-dump | grep -C10 headroom while audio is playing to Speaker/Jack and see if any value is set to 1024, if not then can you try the LUA way of configuring it: thesofproject/linux#5284 (comment)

alsa-ucm-conf and ALSA stuff is the newest, the only old package is pipewire in your setup. I did installed F43 on my laptop, both GNOME and KDE edition and used it for few hours and saw no issues, but admittedly I should be using the machine for full time.

@kv2019i FYI

@AndreasBackx, thanks for the log! Btw, f44 will have pw-1.6.4, this does not help here... which edition of f43 should I install for testing?

[ujfalusi]

Interesting, installed f43 GNOME edition and after the install+update audio works fine.
I can also see this out of box when watching video to speaker:

pw-dump | grep headroom
            "name": "api.alsa.headroom",
              "api.alsa.headroom",
            "name": "api.alsa.headroom",
              "api.alsa.headroom",
            "name": "api.alsa.headroom",
              "api.alsa.headroom",
            "name": "api.alsa.headroom",
              "api.alsa.headroom",
        "api.alsa.headroom": 384,
            "name": "api.alsa.headroom",
              "api.alsa.headroom",
            "name": "api.alsa.headroom",
              "api.alsa.headroom",

The headroom is 384 which is 8ms in 48KHz and this is precisely what 1.6 version of PW would do, but we have 1.4.11.

No reproduction of the issue yet.