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

[AndreasBackx]

Summary

Follow-up to the conversation from #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 7f87a5e, few commits ahead of bfe62a4), 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 #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 #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 #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