[BUG] No audio on Dell XPS Plus 13 9320

[rhowe]

Describe the bug No audio devices detected on a Dell XPS Plus 13 9320

Linux 5.18.0, Debian unstable.

Tested with both Debian firmware-sof-signed package (2.1.1) and also using the sof 2.2 release installed manually (after removing the firmware-sof-signed package)

To Reproduce Install Debian unstable

Observe no audio devices were detected

Reproduction Rate All the time

Expected behavior Audio devices should be detected

Impact Showstopper

Environment 1) Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).

• Kernel: 5.18.0 from the Debian linux-image-5.18.0-2-amd64 package version 5.18.5-1
• SOF: 2.1.1 from the Debian firmware-sof-signed package version 2.1.1-1 and 2.2 from https://github.com/thesofproject/sof-bin/releases/download/v2.2/sof-bin-v2.2.tar.gz 2) Name of the topology file
• Topology: [not sure what to put here] 3) Name of the platform(s) on which the bug is observed.
• Platform: Dell 9320

Screenshots or console output I'm not sure what exactly is relevant, but this from dmesg was all I could really find

[    5.688031] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
[    5.688730] snd_hda_intel 0000:00:1f.3: SoundWire enabled on CannonLake+ platform, using SOF driver
...
[    5.784568] sof-audio-pci-intel-tgl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
[    5.784633] sof-audio-pci-intel-tgl 0000:00:1f.3: SoundWire enabled on CannonLake+ platform, using SOF driver
[    5.784645] sof-audio-pci-intel-tgl 0000:00:1f.3: enabling device (0000 -> 0002)
[    5.784758] sof-audio-pci-intel-tgl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
[    5.784824] sof-audio-pci-intel-tgl 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[    5.791593] sof-audio-pci-intel-tgl 0000:00:1f.3: use msi interrupt mode
[    5.847914] sof-audio-pci-intel-tgl 0000:00:1f.3: hda codecs found, mask 4
[    5.848787] sof-audio-pci-intel-tgl 0000:00:1f.3: firmware: direct-loading firmware intel/sof/sof-adl.ri
[    5.848796] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 2:1:1-3964a
[    5.848797] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:21:0 Kernel ABI 3:19:1
[    5.848799] sof-audio-pci-intel-tgl 0000:00:1f.3: warn: FW ABI is more recent than kernel
[    5.848801] sof-audio-pci-intel-tgl 0000:00:1f.3: unknown sof_ext_man header type 3 size 0x30
...
[    7.961634] soundwire sdw:2:025d:1316:01: Probe not complete, timed out
[    7.961647] soundwire sdw:2:025d:1316:01: Update Slave status failed:-110
[    7.961683] soundwire sdw:1:025d:1316:01: Probe not complete, timed out
[    7.961686] soundwire sdw:1:025d:1316:01: Update Slave status failed:-110
[    7.961715] soundwire sdw:0:025d:0714:01: Probe not complete, timed out
[    7.961717] soundwire sdw:0:025d:0714:01: Update Slave status failed:-110

dmesg and alsa-info with sof 2.1.1 debian package: dmesg-2.1.1.log alsa-info-2.1.1.txt

dmesg and alsa-info with sof 2.2: alsa-info-2.2.txt dmesg-2.2.log

[plbossart]

We added support for this sku 0AF3

    {
        .callback = sof_sdw_quirk_cb,
        .matches = {
            DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"),
            DMI_EXACT_MATCH(DMI_PRODUCT_SKU, "0AF3"),
        },
        /* No Jack */
        .driver_data = (void *)(SOF_SDW_TGL_HDMI |
                    SOF_SDW_FOUR_SPK),
    },

This was added in commit 8f4fa45982b3f2daf5b3626ca0f12bde735f31ff ("ASoC: Intel: sof_sdw: Add support for SKU 0AF3 product") and should be present in 5.18

You probably have an invalid kernel configuration or something.

if you want to debug, add this file sof-dyndbg.conf.txt as /etc/modprobe.d/sof-dyndbg.conf, reboot and attach the full dmesg log.

[rhowe]

Nothing in the dmesg with debugging enabled looks too alarming except for the final message relating to sof

[   10.749445] sof_sdw sof_sdw: snd_soc_register_card failed -517

dmesg-2.1.1-debug.txt

[heftig]

Same issue here, same SKU but on Arch Linux.

I had an aggressive power-saving udev config which set power/control to auto for almost all PCI devices. After removing this config, dmesg still shows registration errors but speakers and microphones work.

[plbossart]

@rhowe it seems we have some sort of race condition here, you can see from the logs below that all devices fails to probe, but then are found

[    8.277907] soundwire sdw:2:025d:1316:01: Probe not complete, timed out
[    8.277916] soundwire sdw:2:025d:1316:01: Update Slave status failed:-110
[    8.277922] soundwire_bus:sdw_handle_slave_status: soundwire sdw:2:025d:1316:01: sdw_handle_slave_status: signaling initialization completion for Slave 1
[    8.277955] soundwire sdw:0:025d:0714:01: Probe not complete, timed out
[    8.277957] soundwire sdw:0:025d:0714:01: Update Slave status failed:-110
[    8.277960] soundwire_bus:sdw_handle_slave_status: soundwire sdw:0:025d:0714:01: sdw_handle_slave_status: signaling initialization completion for Slave 1
[    8.277988] soundwire sdw:1:025d:1316:01: Probe not complete, timed out
[    8.277990] soundwire sdw:1:025d:1316:01: Update Slave status failed:-110
[    8.277992] soundwire_bus:sdw_handle_slave_status: soundwire sdw:1:025d:1316:01: sdw_handle_slave_status: signaling initialization completion for Slave 1

We're completely removed this 'probe not complete' in the last bleeding edge kernel, it was a really bad idea in the first place.

See https://lore.kernel.org/alsa-devel/20220621225641.221170-1-pierre-louis.bossart@linux.intel.com/, the patches will appear in 5.20 upstream in about 9 weeks.

In the mean time, you can either a) apply these patches and try yourself b) manually increase the probe timeout in drivers/soundwire/bus.h bus.h:#define DEFAULT_PROBE_TIMEOUT 2000

if you increase this to 10000 (10s) that should fix the issue.

[rhowe]

It's about 20 years since I built a custom kernel, this should be fun

[heftig]

I had an aggressive power-saving udev config which set power/control to auto for almost all PCI devices. After removing this config, dmesg still shows registration errors but speakers and microphones work.

I was mistaken about the trigger, as the issue reappeared on my next boot and then disappeared again a few reboots after I restored the config.

a) apply these patches and try yourself

I tried applying these patches to v5.18.13, but ran into an error:

sound/soc/codecs/rt715-sdca-sdw.c: In function ‘rt715_sdca_sdw_probe’:
sound/soc/codecs/rt715-sdca-sdw.c:185:14: error: ‘struct sdw_slave’ has no member named ‘ops’
  185 |         slave->ops = &rt715_sdca_slave_ops;
      |              ^~

b) manually increase the probe timeout in drivers/soundwire/bus.h

I'll try this now. I'll report back if I get another boot with missing audio (and udev stuck, which seems to coincide).

[rhowe]

I just came to post about that build failure - I just deleted that line in the assumption that whatever rt715 is, I don't need it.

However, I'm currently fighting Debian's undocumented process for building a signed kernel package so whilst I have a build, I haven't been able to try it out yet.

[madsl]

I just went straight for the sof-dev kernel from here, and that worked the first time I tried on my XPS 9320 some weeks ago. But, even with a kernel updated and built today, if I play anything on my speakers, the sound output will stop after one minute of playback (the media player is also unable to continue playing, the whole stream stops). And I can't get it back without rebooting. It's only when it's speakers, the DisplayPort output ports works.

Anyone else experience this?

[madsl]

I just went straight for the sof-dev kernel from here, and that worked the first time I tried on my XPS 9320 some weeks ago. But, even with a kernel updated and built today, if I play anything on my speakers, the sound output will stop after one minute of playback (the media player is also unable to continue playing, the whole stream stops). And I can't get it back without rebooting. It's only when it's speakers, the DisplayPort output ports works.

Anyone else experience this?

It seems to be because of running powertop --auto-tune. If I don't do that during boot, it stays on.

Shouldn't that work..?

(The sound still works if I make powertop not enable Runtime PM on" PCI Device Intel Corporation Alder Lake PCH eSPI Controller" (/sys/bus/pci/devices/0000:00:1f.0/power/control))

[plbossart]

a) apply these patches and try yourself

I tried applying these patches to v5.18.13, but ran into an error:

sound/soc/codecs/rt715-sdca-sdw.c: In function ‘rt715_sdca_sdw_probe’:
sound/soc/codecs/rt715-sdca-sdw.c:185:14: error: ‘struct sdw_slave’ has no member named ‘ops’
  185 |         slave->ops = &rt715_sdca_slave_ops;
      |              ^~

Sorry, you also need the patch 5118da41c759 ("ASoC: codecs: rt715-sdca: remove useless assignment of ops")

[plbossart]

(The sound still works if I make powertop not enable Runtime PM on" PCI Device Intel Corporation Alder Lake PCH eSPI Controller" (/sys/bus/pci/devices/0000:00:1f.0/power/control))

Separate issue @madsl, let's track this problem in https://github.com/thesofproject/linux/issues/3783

[plbossart]

It's about 20 years since I built a custom kernel, this should be fun

it's like riding a bike, when you screw up it hurts just the same after 20 years.

[madsl]

I just went straight for the sof-dev kernel from here, and that worked the first time I tried on my XPS 9320 some weeks ago. But, even with a kernel updated and built today, if I play anything on my speakers, the sound output will stop after one minute of playback (the media player is also unable to continue playing, the whole stream stops). And I can't get it back without rebooting. It's only when it's speakers, the DisplayPort output ports works. Anyone else experience this?

It seems to be because of running powertop --auto-tune. If I don't do that during boot, it stays on.

Shouldn't that work..?

(The sound still works if I make powertop not enable Runtime PM on" PCI Device Intel Corporation Alder Lake PCH eSPI Controller" (/sys/bus/pci/devices/0000:00:1f.0/power/control))

Just to update this thread, I think the link to powertop here was a false positive. Testing in issue #3783 as we speak, and I can reproduce it both with or without powertop.

[plbossart]

I had an aggressive power-saving udev config which set power/control to auto for almost all PCI devices. After removing this config, dmesg still shows registration errors but speakers and microphones work.

@heftig that seems similar to what @madsl was suggesting, any chance you could find the configuration that didn't work for you?

Edit: although there's no physical link between all these PCI devices, it's possible that by enabling pm_runtime for one device (eSPI?), we end-up changing the timing for the probe of the audio devices.

[libinyang]

I have one tributo and I tested 5.18.0-2 kernel. Playback works well although there are some error logs. BTW: I didn't use the sof-bin-v2.2 FW as my tributo uses different keys. Instead, I used the latest SOF FW. The kernel is downloaded from: https://packages.debian.org/bookworm/linux-image-5.18.0-2-amd64

Please see the attachment for details. alsa-info.txt aplay.log

[libinyang]

And I tried the latest sof-dev kernel, there is no "Probe not complete, timed out" message. playback works well. Please see the attachment for dmesg and other logs.

alsa-info.5.19.0-rc2.txt

[plbossart]

@libinyang thanks for testing. In the case of the 5.18 kernel, I wouldn't characterize the results as "Playback works well although there are some error logs." The SoundWire bus is not functional at all, and there are timeouts left and right. This is really bad. Can we check if this happens with the Dell OEM image provided by Canonical.

I am glad the changes made for 5.20 help, but we will need to provide patches to linux-stable for 5.18 and 5.19, this is not a working setup.

[libinyang]

@libinyang thanks for testing. In the case of the 5.18 kernel, I wouldn't characterize the results as "Playback works well although there are some error logs." The SoundWire bus is not functional at all, and there are timeouts left and right. This is really bad. Can we check if this happens with the Dell OEM image provided by Canonical.

@plbossart Sure. I will test Dell OEM image. On 5.18 kernel, I can hear the sound when playback and aplay seems to work properly.

[bardliao]

@plbossart @libinyang I checked the dmesg and it seems the main issue is that codecs are probed AFTER machine driver is created.

[plbossart]

@plbossart @libinyang I checked the dmesg and it seems the main issue is that codecs are probed AFTER machine driver is created.

Right, this is exactly why I fixed the SoundWire probe. When I did my experiments, I 'blacklisted' the codec drivers, and then did a modprobe by hand on the terminal. That would give me a -EPROBE_DEFER (-517) error everytime except for the last driver where the machine driver finally had all the resources available.

Before I did the changes, we would get a probe timed-out and it was game over.

[libinyang]

@plbossart Sure. I will test Dell OEM image. On 5.18 kernel, I can hear the sound when playback and aplay seems to work properly.

I downloaded OEM image. But I didn't know the built-in passwd and I need passwd to change my fw with debug key. So the progress is pending. Hui from Canonical is helping on this. I will update the status as soon as I get the passwd.

[libinyang]

I downloaded OEM image. But I didn't know the built-in passwd and I need passwd to change my fw with debug key. So the progress is pending. Hui from Canonical is helping on this. I will update the status as soon as I get the passwd.

Tested on Ubuntu OEM focal image, audio works well and no error messages.

[plbossart]

closing, the timeout issue is fixed with recent upstream commits.

[paulmenzel]

For the record, it’s the three commits below in Linus’ master branch:

1. commit bd29c00edd0a5 (soundwire: revisit driver bind/unbind and callbacks)
2. commit 9a24bb35b0d81 (soundwire: peripheral: remove useless ops pointer)
3. commit 3e9c9f90573f4 (soundwire: intel: use pm_runtime_resume() on component probe)

[paulmenzel]

Only the first one has Fixes: tags, and none of them are tagged for the stable series. Are they going to be picked up automatically for the stable series?

[plbossart]

I am not sure if the patches will be picked for stable, it's not my decision. I am still not clear on what causes specific distributions such as ArchLinux or Debian to expose the issue while Ubuntu and Fedora seem just fine.

[changedsoul]

I am again having issues with no sound. Original Issue was posted here: https://github.com/thesofproject/linux/issues/3772 That post led me to this post where I tried both the patch listed in the original post as well as the time out change in this post. I had working sound then. I decided to go full disk encryption and nuked my install. Trying to get sound working again I began to recompile the kernel again this time using the Arch_Build_System. Currently its giving me kernel version 5.19.1-arch2 and when I look into the src files, I see the patches are already applied in this kernel version.

I still see: soundwire sdw:0:025d:0711:01: Probe not complete, timed out Aug 14 11:20:32 archlinux kernel: soundwire sdw:0:025d:0711:01: Update Slave status failed:-110 Aug 14 11:20:32 archlinux kernel: sof_sdw sof_sdw: snd_soc_register_card failed -517 Aug 14 11:20:32 archlinux kernel: sof_sdw sof_sdw: snd_soc_register_card failed -517

in my boot log.

Could my disk encryption be breaking the once working sound?

Edit: Looking at other boot errors I came across baloo_file crashing. Disabling baloo seemed to have resolved the sound issue. Edit 2: Nope, just a coincident. Seems the audio is found sometimes and sometimes not.

[plbossart]

@changedsoul the kernel modules are located on the file system, so certainly any slowdown on the file system side due to e.g. encryption would potentially increase the time needed to load/probe the modules, which might in the end trigger the timeout.

I wouldn't spend too much time on this, we know this timeout idea was a bad one and we've changed this upstream. Either increase the value of the timeout for a quick fix, or install the patches listed above:

commit https://github.com/thesofproject/linux/commit/bd29c00edd0a5dac8b6e7332bb470cd50f92e893 (soundwire: revisit driver bind/unbind and callbacks) commit https://github.com/thesofproject/linux/commit/9a24bb35b0d81edb826f174d7752c2a54bc00abd (soundwire: peripheral: remove useless ops pointer) commit https://github.com/thesofproject/linux/commit/3e9c9f90573f4633ec8270d0d02bcea4fad1e802 (soundwire: intel: use pm_runtime_resume() on component probe)

[paulmenzel]

Currently its giving me kernel version 5.19.1-arch2 and when I look into the src files, I see the patches are already applied in this kernel version.

The three commits have not been added to the 5.19.1 stable series release.

$ git log --grep bd29c00 v5.19.1
$

[plbossart]

Currently its giving me kernel version 5.19.1-arch2 and when I look into the src files, I see the patches are already applied in this kernel version.

The three commits have not been added to the 5.19.1 stable series release.

they were queued today

[heftig]

@plbossart Two of them were. https://github.com/thesofproject/linux/commit/3e9c9f90573f4633ec8270d0d02bcea4fad1e802 is still missing. Is it critical?

[plbossart]

@plbossart Two of them were. 3e9c9f9 is still missing. Is it critical?

Probably not, but never say never, eh?

[changedsoul]

So I tried to build the current kernel with Arch_Build_System with the patches applied, but I am still missing sound. Still getting archlinux kernel: sof_sdw sof_sdw: snd_soc_register_card failed -517 archlinux kernel: sof_sdw sof_sdw: snd_soc_register_card failed -517

It is possible I have done something wrong, but I checked the src files mid compile after patches were applied and matched them against the changes on github so it seems the patches were applied correctly. What are the chances these patches dont fix the issue on arch? I can also wait until 5.20 comes out and see if I have sound or not by default. Should I wait, or is there something I can do to see if these patches do not solve the issue on arch?

Edit: Never mind, When I remove the driver with modprobe -r and load it again, I get audio. Ill just do this until the new kernel comes out to see if things work well then.

[plbossart]

@changedsoul the error -517 means -EPROBE_DEFER, in other words the resources needed by sof_es8336 are not available and the probe will be retried as new resources are added. I don't see any reason why the deferred probe would fail to detect a change, there's something weird about this build that adds delays on probe.

[danielcb]

Hi, afaik all 3 patches are already included in 5.19.2-arch1. I just tried adding them via arch build system and got

patching file ...
Reversed (or previously applied) patch detected!  Skipping patch.

... for all three of them. Should have looked beforehand.

Anyway, at least on my system there seems to be no change. Still the same errors and udev problems. Will try the timeout now.

[heftig]

I rebooted 5.19.2-arch1-1 a few times. I saw the error -517 once but sound still worked every time.

[Grandfather-Paradox]

I'm on Dell XPS 9720 and have the same issue. I'm using a temporary workaround until the kernel is fixed - haven't had any luck with either the bleeding edge kernel or LTS. I added the following line to /etc/modprobe.d/blacklist.conf to blacklist the module causing the hang at boot: blacklist snd_sof_pci_intel_tgl

I also created a systemd service and enabled it to then load the module after booting. The service file contains the following:

[Unit] After=multi-user.target

[Service] ExecStart=/usr/bin/modprobe snd_sof_pci_intel_tgl

[Install] After=multi-user.target

This is at least a workaround for the issue of hanging at boot and then not having working sound. Hopefully it helps others with the same issue while we wait for the updated kernel.

[changedsoul]

@Grandfather-Paradox I have the same Dell XPS 17 9720 running on Arch with kernel 5.19.2-arch1-1 My sound seems to work every boot now with this kernel so far. Whats strange is when I compile my own of the same version using the Arch Build system, it does not work. No idea why, dont really care anymore.

Current version 5.19.2-arch1-1 has solved my sound issues from what I can tell now. I tried to black list the module but it still kept getting loaded in the past. I gave up on that. Easiest thing to do for me was just remove the module and reload it when I was in kde. sudo modprobe -r snd_sof_pci_intel_tgl sudo modprobe snd_sof_pci_intel_tgl This detected my sound and stopped the hangs on shutdown. If you need any more info from me since we have similar laptops, dont hesitate to ask.

[Grandfather-Paradox]

@changedsoul I'm actually having an even worse issue on 5.19.2-arch1-1 now. I took snd_sof_pci_intel_tgl off the blacklist to see if it would work like you said, and it hangs on udev for the full 3 minutes when booting and then never makes it anywhere. It gets stuck with a single dash on the screen and can't even be switched to console or anything. So strange. I did notice that it was getting that same -517 error when booting. I took some pictures of the console output (can't seem to get the actual text logs) but can't spot anything in particular that would be causing this. As another note, I earlier add an X11 config file to make it use Nvidia instead of integrated Intel (there were all sorts of graphics issues before this). Not sure if this is related but I'm wondering what's different about my setup from yours. Thanks for your help!

[changedsoul]

@Grandfather-Paradox Im away from home atm, but I suspect your issue is tied to the graphics. I also had some pretty bad issues. You have the rtx3050 right? When i get back I’ll get a list of my packages installed and post them for you. i also needed to add a kernel parameter to fix something else but I think it also fixed the graphics issue, ibt=off or something like that.

[Grandfather-Paradox]

@changedsoul I disabled the X11 config I made with no change on 5.19.2 - still won't boot. It seems like it's unable to load a kernel module, but I can't figure out which one it is yet. I have no problem booting the live system, but it's on 5.18.16, so it's not the latest kernel. My GPU is the RTX 3060. And thanks, I appreciate it!

[Grandfather-Paradox]

@changedsoul I got the full boot log and saw an error, which led me here, where I found that same "ibt=off" kernel parameter you have. Setting that parameter allows the system to boot but with the same sound card issue unless I enable my workaround. Additionally, the display has a yellowish hue on 5.19.2, similar to night light. Incidentally, night light hasn't been working at all under any configuration.

[changedsoul]

Well I just booted into default arch kernel and had no sound. Had to remove the module and reload it. Seems to work more times than not, but there is still a issue loading. @Grandfather-Paradox Sounds like you have other issues on top of this sound issue. this is what I have installed on my system if you want to match. I am using kde by the way, not sure what your using. xorg: https://pastebin.com/02kH23Ny nvidia: https://pastebin.com/YVvV3YUJ if your using kde, just delete or rename the whole kde config folder and let it login fresh.

[danielcb]

At the moment the only way that works for me (even with a patched 5.19.2-arch1 kernel) is still relloading the module after boot.

[Grandfather-Paradox]

Just tested 5.19.3-arch1-1. I had one boot where the sound worked properly and then two others where it failed, so it seems like the bug is still present. Reloading the module still works as a workaround. However, the night light issue I experienced seems to be fixed now. I'm using GNOME by the way - meant to mention that before. With 5.19.3-arch1-1, however, the display has a slightly yellowish tint even without night mode enabled. Not sure what to make of that, but it's definitely present.

[changedsoul]

Can we get this reopened? Im on 5.19.3 now too and seems patches are in place yet still no sound on boot up. When I try to remove the module for reload I get this:

soundwire_intel soundwire_intel.link.0: IO transfer timed out, cmd 2 device 15 addr 44 len 1
Aug 26 08:08:51 archlinux kernel: soundwire sdw-master-0: trf on Slave 15 failed:-110 read addr 44 count 0
Aug 26 08:08:51 archlinux kernel: soundwire sdw-master-0: SDW_SCP_STAT bread failed:-110
Aug 26 08:08:51 archlinux kernel: soundwire_intel soundwire_intel.link.0: prepare clock stop failed -110
Aug 26 08:08:51 archlinux kernel: soundwire_intel soundwire_intel.link.0: cannot enable clock stop on suspend
Aug 26 08:08:51 archlinux kernel: soundwire_intel soundwire_intel.link.3: IO transfer timed out, cmd 2 device 15 addr 44 len 1
Aug 26 08:08:51 archlinux kernel: soundwire sdw-master-3: trf on Slave 15 failed:-110 read addr 44 count 0
Aug 26 08:08:51 archlinux kernel: soundwire sdw-master-3: SDW_SCP_STAT bread failed:-110
Aug 26 08:08:51 archlinux kernel: soundwire_intel soundwire_intel.link.3: prepare clock stop failed -110
Aug 26 08:08:51 archlinux kernel: soundwire_intel soundwire_intel.link.3: cannot enable clock stop on suspend
Aug 26 08:08:51 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: runtime PM trying to activate child device sdw:0:025d:0711:01 but parent (sdw-master-0) is not active
Aug 26 08:08:51 archlinux systemd-udevd[663]: sdw:3:025d:0714:01: Worker [685] terminated by signal 9 (KILL).
Aug 26 08:08:52 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:52 archlinux kernel: soundwire sdw-master-0: trf on Slave 1 failed:-5 read addr 801a count 0
Aug 26 08:08:52 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:52 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: Failed to get private value: 200001a => 0000 ret=-5
Aug 26 08:08:53 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:53 archlinux kernel: soundwire sdw-master-0: trf on Slave 1 failed:-5 read addr 8008 count 0
Aug 26 08:08:53 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:53 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: Failed to get private value: 6100008 => 0000 ret=-5
Aug 26 08:08:54 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:54 archlinux kernel: soundwire sdw-master-0: trf on Slave 1 failed:-5 read addr 8000 count 0
Aug 26 08:08:54 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:54 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: Failed to get private value: 2000000 => 0000 ret=-5
Aug 26 08:08:55 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:55 archlinux kernel: soundwire sdw-master-0: trf on Slave 1 failed:-5 write addr a06d count 0
Aug 26 08:08:55 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:55 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: Failed to set private value: 200006d <= 0e00 ret=-5
Aug 26 08:08:56 archlinux kernel: soundwire_intel soundwire_intel.link.3: IO transfer timed out, cmd 3 device 15 addr 44 len 1
Aug 26 08:08:56 archlinux kernel: soundwire sdw-master-3: trf on Slave 15 failed:-110 write addr 44 count 0
Aug 26 08:08:56 archlinux kernel: soundwire sdw-master-3: ClockStopNow Broadcast msg failed -110
Aug 26 08:08:56 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:56 archlinux kernel: soundwire sdw-master-0: trf on Slave 1 failed:-5 write addr a00a count 0
Aug 26 08:08:56 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:56 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: Failed to set private value: 610000a <= 0008 ret=-5
Aug 26 08:08:57 archlinux kernel: soundwire_intel soundwire_intel.link.0: IO transfer timed out, cmd 3 device 1 addr 2f5a len 1
Aug 26 08:08:57 archlinux kernel: soundwire sdw-master-0: trf on Slave 1 failed:-110 write addr 2f5a count 0
Aug 26 08:08:57 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:57 archlinux kernel: soundwire sdw-master-0: trf on Slave 1 failed:-5 write addr a0b7 count 0
Aug 26 08:08:58 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:58 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: Failed to set private value: 20000b7 <= 8728 ret=-5
Aug 26 08:08:58 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:58 archlinux kernel: soundwire sdw-master-0: trf on Slave 1 failed:-5 write addr a047 count 0
Aug 26 08:08:59 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:08:59 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: Failed to set private value: 2000047 <= a472 ret=-5
Aug 26 08:08:59 archlinux kernel: soundwire_intel soundwire_intel.link.0: IO transfer timed out, cmd 3 device 1 addr 2f50 len 1
Aug 26 08:08:59 archlinux kernel: soundwire sdw-master-0: trf on Slave 1 failed:-110 write addr 2f50 count 0
Aug 26 08:09:00 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:09:00 archlinux kernel: soundwire sdw-master-0: trf on Slave 1 failed:-5 read addr 8005 count 0
Aug 26 08:09:00 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:09:00 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: Failed to get private value: 5f00005 => 0000 ret=-5
Aug 26 08:09:01 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:09:01 archlinux kernel: soundwire sdw-master-0: trf on Slave 1 failed:-5 write addr a047 count 0
Aug 26 08:09:01 archlinux wpa_supplicant[1401]: wlp0s20f3: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-65 noise=9999 txrate=26000
Aug 26 08:09:01 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:09:01 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: Failed to set private value: 2000047 <= a47e ret=-5
Aug 26 08:09:02 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:09:02 archlinux kernel: soundwire sdw-master-0: trf on Slave 1 failed:-5 write addr a006 count 0
Aug 26 08:09:02 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:09:02 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: Failed to set private value: 6100006 <= 0000 ret=-5
Aug 26 08:09:03 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out
Aug 26 08:09:03 archlinux kernel: soundwire_intel soundwire_intel.link.0: SCP Msg trf timed out

When I reload I get these warnings, but sound is working.

Aug 26 08:11:18 archlinux kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: warn: topology ABI is more recent than kernel
Aug 26 08:11:18 archlinux kernel: sof_sdw sof_sdw: ASoC: Parent card not yet available, widget card binding deferred
Aug 26 08:11:18 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: Bus clash detected before INT mask is enabled

[Grandfather-Paradox]

@changedsoul Agreed. This bug is most definitely still present.

[plbossart]

@changedsoul @Grandfather-Paradox can you try with v6.0-rc2 and see what happens? It's not clear to me why this problem is only reported with archlinux.

[plbossart]

Aug 26 08:11:18 archlinux kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: warn: topology ABI is more recent than kernel
Aug 26 08:11:18 archlinux kernel: sof_sdw sof_sdw: ASoC: Parent card not yet available, widget card binding deferred
Aug 26 08:11:18 archlinux kernel: rt711-sdca sdw:0:025d:0711:01: Bus clash detected before INT mask is enabled

you can safely ignore all of these.

[downeymj]

It's not clear to me why this problem is only reported with archlinux.

FWIW, I have the same problem with this hardware model on Debian Testing with its included kernel (5.18.16-1). Using the modprobe commands earlier from @Grandfather-Paradox after signing in as a successful workaround for now.

Adding the nomodeset kernel option in grub config is also a valid workaround on the same system.