[BUG] No audio on Dell XPS Plus 13 9320

[rhowe]

trafficstars

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/[email protected]/, 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