thesofproject
Dell XPS 13 9315 Sound Freezes with "UNATTACHED" and "clock stop" messages
Hello, I'm running Arch Linux on a Dell XPS 13 9315. After reloading the snd_sof_pci_intel_tgl module per #3777 , sound works until a sound application is paused or exits. When this occurs, my logs show the following:
Oct 18 08:33:02 xps kernel: rt715-sdca sdw:3:025d:0714:01: Slave 1 state check1: UNATTACHED, status was 1
Oct 18 08:33:02 xps kernel: rt715-sdca sdw:3:025d:0714:01: clock stop deprepare failed:-61
Oct 18 08:33:02 xps kernel: soundwire sdw-master-1: clock stop deprepare wait failed:-61
Until recently, merely reloading the snd_sof_pci_intel_tgl module would ensure proper audio until reboot. Now, reloading the module is required every time a sound application is used. I suspect a recent pipewire/wireplumber update may be triggering this issue.
sof_alsa_info.txt sof_dmesg.txt
SKU 0B14 is not know to the kernel, this is a new one we haven't seen before. Yay Dell for letting us know. It looks like you don't have a jack?
The log "UNATTACHED" essentially tells us that the device dealing with microphones went off the rails. That's not supposed to happen.
There were quite a few changes in the last kernel cycle, but they are only in 6.1-rc1. I don't have an explanation for the change you are describing. My take is that this device was never properly managed and hence the past results should be taken with a grain of salt.
Can you please copy this file sof-dyndbg.conf.txt as /etc/modprobe.d/sof-dyndbg.conf, reboot and attach the dmesg log. Thanks.
Ah, I did purchase this 9315 with Ubuntu pre-installed, so it might be slightly different model than the Windows 9315. Dell may have forgotten about us penguins ;)
Assuming you meant hardware jack, correct, I don't have a traditional physical hardware jack. At purchase time, it was hard to see what changes when I selected Linux as the OS for the 9315, but I recall "vPro" being disabled.
I can't seem to extricate myself from a meeting, but once able I'd be happy to copy your config file and attach the results.
It's also possible that Ubuntu have patches that are not upstream yet for some reason, or that things happen to work by accident. The other 'non-jack' device still have 2 amplifiers and you report one to UCM, so something isn't quite right still.
Part of being an Arch Linux user is accepting the fact that we're often a factor in the QA of other distributions :)
Please see the attached dmesg, gathered after rebooting with your config.
Humm, the log doesn't contain the parts I need. Can you put PipeWire and PulseAudio on ice and just give the start of the SOF probe, I need to check the SoundWire IDs reported as attached on the system.
I usually do this the brute-force way: sudo mv /usr/bin/pipewire /usr/bin/_pipewire but there are more elegant ways to do so :-)
Thanks @davekrh. The logs are interesting
[ 20.134391] soundwire_bus:sdw_extract_slave_id: soundwire sdw-master-0: SDW Slave Addr: 30025d131601
[ 20.135996] soundwire_bus:sdw_extract_slave_id: soundwire sdw-master-1: SDW Slave Addr: 30025d071401
[ 20.145063] soundwire_bus:sdw_modify_slave_status: soundwire sdw:2:025d:1316:01: sdw_modify_slave_status: signaling enumeration completion for Slave 1
[ 20.148677] soundwire_bus:sdw_handle_slave_status: soundwire sdw:2:025d:1316:01: sdw_handle_slave_status: signaling initialization completion for Slave 1
That means you only one one amplifier (RT1316) on link 2 and a microphone codec (RT714) on link3. That probably works without any quirks then. One of those "one cannot always be unlucky" type of thing :-)
That means we need to root-cause the issue you're having by trying with a newer kernel and possibly bisect.
If you are not familiar with installing your own kernel, please see https://thesofproject.github.io/latest/getting_started/setup_linux/install_locally.html
If you can try with our development kernel (branch topic/sof-dev), that would really help. I'd really be curious to see what happens here.
Willing to give it a shot. To be clear, you're suggesting I try a sof kernel and not a newer normal kernel, correct? I don't suppose you've had users build sof kernels with Arch's Build System?
I think @changedsoul tried and showed the Arch Build system added some issues
I was suggesting the topic/sof-dev branch since it contains all the fixes, but it's still based on v6.0-rcX. It wouldn't be quite right to ask you to try with 6.1-rc1 which we haven't even tried ourselves.
I did try the sof kernel with configs applied against Arch's kernel config. I was able to build modules but make bzImage failed. Arch of course updates kernels quite rapidly, so I'd be happy to report my findings as time goes on.
One tidbit, Arch had installed both pipewire and pulseaudio, and I can't replicate the issue after cold booting with pulseaudio removed. I didn't even have to remove the -tgl module. If I survive more reboots without issues I'll update this and 3777. I'm mindful of your comment that certain behaviors aren't supposed to happen.
Your first comment mentions SKU 0B14. Would you like me to try anything (a patch, etc) against Arch's kernel to recognize that SKU?
Humm, can you share what happens with the compilation and attach the logs? that's very odd that compilation fails.
I don't see any clear explanation as to why removing PulseAudio would change the results. The 'clock stop' mode is used when the audio device is not in use, and the suspend to D3 happens with a delay when all references are released.
Don't worry about 0B14, we could duplicate the quirk that exists for 0B13 but that wouldn't change the results.
After a few more reboots and testing, I can confirm that I can't replicate the issue if I remove pulseaudio. I understand your point that "clock stop" shouldn't happen, however I do wonder if this issue is worth your time.
The kernel compile could well be my fault. I hadn't compiled a kernel outside of a package manager in more than a decade.
@davekrh there's been a number of fixes added to the Arch kernel, can I ask you if your still have this problem when PulseAudio is enabled?
Apologies for the tardy reply. On Arch, I can no longer install pulseaudio as it conflicts with pipewire-pulse. pipewire-pulse in turn is needed by gnome-bluetooth-3.0. I was only able to trigger the bug by having both pulse and pipewire concurrently installed, which on Arch seems no longer possible.
On Mon, Dec 12, 2022 at 6:44 PM Pierre-Louis Bossart < @.***> wrote:
@davekrh https://github.com/davekrh there's been a number of fixes added to the Arch kernel, can I ask you if your still have this problem when PulseAudio is enabled?
— Reply to this email directly, view it on GitHub https://github.com/thesofproject/linux/issues/3937#issuecomment-1347584705, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKCMT6AEW2YVMFDZJAVFQA3WM7BGXANCNFSM6AAAAAARIDZKGY . You are receiving this because you were mentioned.Message ID: @.***>
I'll close this bug @davekrh since we can't trigger it. If you find something problematic please open a new issue, thanks!