No sound on Dell XPS 17 9700

[OleksiiR]

The sound from speakers randomly appears and disappears after laptop reboot or sleep/wake, with a way higher probability to not work. The sound from Bluetooth speakers and microphone work OK.

If sound from speakers works, there are no error messages in dmesg related to sound. If sound does not work, the alsa-info.sh output is attached. BTW, there was an attempt to reload sound driver for this log file.

alsa-info.txt

Hardware: Dell XPS 17 9700 OS: Fresh install of OpenSUSE 15.6 64-bit.

P.S. Also see: https://bugzilla.opensuse.org/show_bug.cgi?id=1226280

[plbossart]

It seems that the SoundWire link is fundamentally broken on this device

[   15.964536] soundwire_intel soundwire_intel.link.0: IO transfer timed out, cmd 3 device 0 addr 3501 len 1
[   15.964554] soundwire_intel soundwire_intel.link.0: RX AVAIL 63 too long
[   15.964771] soundwire sdw-master-0-0: trf on Slave 0 failed:-110 write addr 3501 count 0
[   16.476540] soundwire_intel soundwire_intel.link.0: IO transfer timed out, cmd 3 device 0 addr 7308 len 1

This isn't exactly a new configuration, CML is like 4 years old already. That said, we don't have this configuration in the kernel, so not sure what skew this is.

can you please add this file sof-dyndbg.conf.txt as /etc/modprobe.d/sof-dyndbg.conf, reboot and attach the dmesg log.

[OleksiiR]

Thanks for your reply, report attached.

alsa-info.txt.af0CoCbkUH_syndbg_conf.txt

[plbossart]

Thanks @OleksiiR .

It looks like your SoundWire link.0 is not functional, the rt711 device is not enumerated and then things go South. if you search for "link.0", you'll see that nothing happens and then the transfers time out.

Can you try and update your kernel to something more recent than 6.4?

Also to rule out a configuration issue, can you double-check that your device does have a jack connector?

@bardliao FYI.

[plbossart]

also I was mistaken earlier, we do support this SKU which makes me think of a hardware problem.

    {
        .callback = sof_sdw_quirk_cb,
        .matches = {
            DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"),
            DMI_EXACT_MATCH(DMI_PRODUCT_SKU, "098F"),
        },
        .driver_data = (void *)(RT711_JD2),
    },

[OleksiiR]

Thanks @OleksiiR .

It looks like your SoundWire link.0 is not functional, the rt711 device is not enumerated and then things go South. if you search for "link.0", you'll see that nothing happens and then the transfers time out.

Can you try and update your kernel to something more recent than 6.4?

Also to rule out a configuration issue, can you double-check that your device does have a jack connector?

@bardliao FYI.

Thank you. Do you mean uploading alsa-info.sh output with newer kernel? If yes, which kernel version would you prefer?

Just FYI, I tested a plenty of kernels here https://bugzilla.opensuse.org/show_bug.cgi?id=1226280, and although there were no debug outputs, just changing the kernel did not help fixing the issue.

[plbossart]

try 6.9 with debug options, that'll tell us what's going on. If you can try with our latest development kernel as well (branch topic/sof-dev), it contains an additional piece of code to check enumeration status. We've never seen any issues on CML but who knows maybe the hardware did age...

[OleksiiR]

alsa-info.txt.IgB0e3TXu3_6.9_debug.txt

Here is the alsa-info.sh output for 6.9-debug kernel. Is it necessary to try to use your kernel?

[plbossart]

so with the new results, one can see that the RT711 is detected

[    6.711862] soundwire_cadence:cdns_update_slave_status_work: soundwire_intel soundwire_intel.link.0: Slave status change: 0x2
[    6.712170] soundwire_bus:sdw_handle_slave_status: soundwire sdw-master-0-0: Slave attached, programming device number
[    6.712991] soundwire_cadence:cdns_fill_msg_resp: soundwire_intel soundwire_intel.link.0: Msg ignored for Slave 0
[    6.712993] soundwire_bus:sdw_program_device_num: soundwire sdw-master-0-0: No more devices to enumerate
[    6.713196] soundwire_cadence:cdns_update_slave_status_work: soundwire_intel soundwire_intel.link.0: Slave status change: 0x20000001

but then later on

[   12.963553] snd_soc_rt711:rt711_jack_detect_handler: rt711 sdw:0:0:025d:0711:00: in rt711_jack_detect_handler, jack_type=0x0
[   12.963555] snd_soc_rt711:rt711_jack_detect_handler: rt711 sdw:0:0:025d:0711:00: in rt711_jack_detect_handler, btn_type=0x0
[   13.794452] soundwire_cadence:cdns_update_slave_status_work: soundwire_intel soundwire_intel.link.0: Slave status change: 0x10000000
[   13.794512] rt711 sdw:0:0:025d:0711:00: Slave 7 state check1: UNATTACHED, status was 1

That means the RT711 is no longer connected on the link, or was reset somehow and does not reattach.

The SoundWire stack does not support this sort of problems well, or at all really.

My money is on a hardware problem, usually this happens because of electrical issues that cannot be worked-around in software.

You could try with the newer kernel, we might have more information from more recent debug capabilities, but this really suggests a broken hardware I am afraid.

[bardliao]

Yeah, it looks like a HW issue to me, too. It seems that rt711 can be attached sometimes but not always.

[OleksiiR]

Oh wow, that's unexpected. Judging by your experience, does this mean that the audio card is dead, or just some minor connection problem in some port?

[bardliao]

Oh wow, that's unexpected. Judging by your experience, does this mean that the audio card is dead, or just some minor connection problem in some port?

I would guess just some minor connection problem in some port.

[plbossart]

the problem is likely a borderline timing violation and then the codec disappears. if you don't care too much about the headset/headphone support, you could filter this link out with a kernel option, that way you'd always have the speakers and mic operational. Not sure if we have this topology available though.

[bardliao]

the problem is likely a borderline timing violation and then the codec disappears. if you don't care too much about the headset/headphone support, you could filter this link out with a kernel option, that way you'd always have the speakers and mic operational. Not sure if we have this topology available though.

Looking at https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/intel/common/soc-acpi-intel-cml-match.c#L282, I don't think this configuration is supported.

[OleksiiR]

the problem is likely a borderline timing violation and then the codec disappears. if you don't care too much about the headset/headphone support, you could filter this link out with a kernel option, that way you'd always have the speakers and mic operational. Not sure if we have this topology available though.

Looking at https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/intel/common/soc-acpi-intel-cml-match.c#L282, I don't think this configuration is supported.

Well, it did work for me at this version of OpenSUSE before, it was just randomly working and not working, until it stopped working completely. So it indeed looks like a connection problem in some port. I am waiting for small screwdrivers to open the laptop.

[OleksiiR]

the problem is likely a borderline timing violation and then the codec disappears. if you don't care too much about the headset/headphone support, you could filter this link out with a kernel option, that way you'd always have the speakers and mic operational. Not sure if we have this topology available though.

Looking at https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/intel/common/soc-acpi-intel-cml-match.c#L282, I don't think this configuration is supported.

Well, it did work for me at this version of OpenSUSE before, it was just randomly working and not working, until it stopped working completely. So it indeed looks like a connection problem in some port. I am waiting for small screwdrivers to open the laptop.

Oh wow, that's unexpected. Judging by your experience, does this mean that the audio card is dead, or just some minor connection problem in some port?

I would guess just some minor connection problem in some port.

I have opened laptop and plugged-out/plugged-in all connections there. No effect.

[OleksiiR]

the problem is likely a borderline timing violation and then the codec disappears. if you don't care too much about the headset/headphone support, you could filter this link out with a kernel option, that way you'd always have the speakers and mic operational. Not sure if we have this topology available though.

Can you please specify what I should filter out?

[OleksiiR]

If this is a hardware problem, will buying new SD/Audio IO board help?

[plbossart]

It's possible to change the tables in soc-acpi-intel-cml-match.c to create a new configuration without link0, then add a kernel parameter to disable link0 in intel-sdw-acpi.c and last you would need to create a topology file that doesn't have a jack on link0.

It's relatively simple for an Intel person, but we're all busy with other things, and nearly impossible for a non-Intel person.

[bardliao]

Maybe bus an USB sound card is the simplest way.

[poltpolt]

I have a dell xps 9700 as well with opensuse but tumbleweed, I noticed issue with opensuse kernel 6.10.8 but 6.10.7 works. I'll download leap 15.6 live iso and check for you on my device.

[poltpolt]

I confirm on Dell xps 9700 where tumbleweed sound works on kernel 6.10.7 (fails on 6.10.8) , I booted Leap 15.6 livecd kde iso.

No sound at all http://alsa-project.org/db/?f=822620088fa10c11929555749ad730e5e15318cd

[OleksiiR]

I confirm on Dell xps 9700 where tumbleweed sound works on kernel 6.10.7 (fails on 6.10.8) , I booted Leap 15.6 livecd kde iso.

No sound at all http://alsa-project.org/db/?f=822620088fa10c11929555749ad730e5e15318cd

Thank you! Can this issue be re-opened then?

[bardliao]

@poltpolt Can you check if https://github.com/torvalds/linux/commit/ab8d66d132bc8f1992d3eb6cab8d32dda6733c84 is in your kernel? If so, please revert it and test again.

[poltpolt]

sorry I'm just a end-user not a dev