Created attachment 283853 [details] dmesg output Since kernel 5.2 there is no sound on my Broadwell-based laptop with bdw-rt5677 driver. The laptop is a Chromebook Pixel 2015 (Samus) converted to Linux with UEFI firmware by MrChromebox. There was no problem with this component with 4.19.*, 5.0.* and 5.1.* kernels up until 5.1.16. > uname -a Linux pixie 5.2.1-arch1-1-ARCH #1 SMP PREEMPT Sun Jul 14 14:52:52 UTC 2019 x86_64 GNU/Linux > cat /proc/version Linux version 5.2.1-arch1-1-ARCH (builduser@heftig-55221) (gcc version 9.1.0 (GCC)) #1 SMP PREEMPT Sun Jul 14 14:52:52 UTC 2019 > cat /proc/cpuinfo | grep -i name model name : Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz
awk -f scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux pixie 5.2.1-arch1-1-ARCH #1 SMP PREEMPT Sun Jul 14 14:52:52 UTC 2019 x86_64 GNU/Linux GNU C 9.1.0 GNU Make 4.2.1 Binutils 2.32 Util-linux 2.34 Mount 2.34 Module-init-tools 26 E2fsprogs 1.45.3 Jfsutils 1.1.15 Reiserfsprogs 3.6.27 Xfsprogs 4.20.0 Linux C Library 2.29 Dynamic linker (ldd) 2.29 Linux C++ Library 6.0.26 Procps 3.3.15 Kbd 2.0.4 Console-tools 2.0.4 Sh-utils 8.31 Udev 242 Modules Loaded 8021q ac ac97_bus aesni_intel aes_x86_64 agpgart ahci arc4 atkbd atmel_mxt_ts battery ccm cfg80211 chromeos_laptop cmdlinepart coretemp crc16 crc32c_generic crc32c_intel crc32_pclmul crct10dif_pclmul cros_ec_core cros_ec_lpcs cros_kbd_led_backlight cryptd crypto_simd drm drm_kms_helper evdev ext4 fat fb_sys_fops garp ghash_clmulni_intel glue_helper gpio_lynxpoint i2c_algo_bit i8042 i915 input_leds intel_cstate intel_gtt intel_pch_thermal intel_powerclamp intel_rapl intel_rapl_perf intel_spi intel_spi_platform intel_uncore ip_tables irqbypass iTCO_vendor_support iTCO_wdt iwlmvm iwlwifi jbd2 joydev kvm kvm_intel libahci libata libps2 llc lpc_ich lz4 lz4_compress mac80211 mac_hid mbcache media mei mei_me mousedev mrp msr mtd nls_cp437 nls_iso8859_1 ofpart pcc_cpufreq pcspkr rfkill rng_core scsi_mod sd_mod serio serio_raw snd snd_compress snd_hda_codec snd_hda_codec_hdmi snd_hda_core snd_hda_intel snd_hwdep snd_pcm snd_pcm_dmaengine snd_soc_acpi snd_soc_acpi_intel_match snd_soc_core snd_soc_rl6231 snd_soc_rt5677 snd_soc_rt5677_spi snd_soc_sst_acpi snd_soc_sst_bdw_rt5677_mach snd_soc_sst_dsp snd_soc_sst_firmware snd_soc_sst_haswell_pcm snd_soc_sst_ipc snd_sof snd_sof_intel_bdw snd_sof_intel_byt snd_sof_intel_ipc snd_sof_xtensa_dsp snd_timer sof_acpi_dev soundcore spi_nor spi_pxa2xx_platform stp syscopyarea sysfillrect sysimgblt tpm tpm_tis tpm_tis_core uvcvideo vfat videobuf2_common videobuf2_memops videobuf2_v4l2 videobuf2_vmalloc videodev x86_pkg_temp_thermal xhci_hcd xhci_pci x_tables
Created attachment 283855 [details] /proc/modules
Created attachment 283857 [details] /proc/iomem
Created attachment 283859 [details] lspci -vvv
> cat /etc/modprobe.d/modprobe.conf blacklist btintel blacklist btusb blacklist bluetooth options snd slots=snd_soc_sst_bdw_rt5677_mach,snd-hda-intel
I can confirm that this is an issue with Linux 5.2 and the bdw-rt5677 hardware. Downgrading to Linux 4.19.59 fixes the issue. This issue was not present in Linux 5.0 or 5.1. The hardware is a 2015 Chromebook Pixel (Samus). Looking at Dmitry Savostyanov logs, we have very similar output. Our only difference is that I have not edited /etc/modprobe.d/modprob.conf to blacklist modules via udev. I will post additional information.
Created attachment 283891 [details] lsmod
Exact same issue here. Probably related to this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f6c2a2e9abe1ac636a49ad96dfbb42ce8d39be
The issue persists with kernel 5.2.4-arch1-1-ARCH. When attempting to play sound the kernel reports the following error: Jul 30 21:42:25 pixie kernel: haswell-pcm-audio haswell-pcm-audio: ipc: error set dx state 3 failed
The issue persists in kernel 5.3.
Liam and Pierre-Louis, I have bisected this to the Sound Open Framework support from Intel that was added during the v5.2-rc1 cycle. Specifically, the issue is present beginning with this commit: commit f35bf70f61d389754fafd7fce75efbb3bd2eea87 Author: Liam Girdwood <liam.r.girdwood@linux.intel.com> Date: Fri Apr 12 11:09:03 2019 -0500 ASoC: Intel: Make sure BDW based machine drivers build for SOF BDW uses hard coded IPC calls to set SSP, not needed in SOF as SSP is configured via topology. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org> For me, this is occurring on a Dell Latitude 7350, running out-of-the-box Fedora 30 or Arch Linux. I see the output from dmesg that others have mentioned and then more -- including a kernel bug involving sst_dsp_dma_put_channel(). I will attach it here.
Created attachment 285641 [details] dmesg (Latitude 7350, kernel 5.3.7, typical output)
Created attachment 285643 [details] dmesg (Latitude 7350, kernel 5.3.7, output with DMA bug)
*** Bug 205083 has been marked as a duplicate of this bug. ***
It's likely that you enabled both drivers for Broadwell, which is an invalid configuration. Just deselect SOF_BROADWELL with make menuconfig and retry.
Pierre, 1) This is occurring with the stock Linux kernel that ships with mainline Linux distributions (Fedora, Ubuntu, Arch Linux). It's affecting end users who just want sound to work out-of-the-box, like it did before SOF was introduced. 2) If selecting both kernel configuration options would produce an invalid build, that is a bug in the Kconfig files, which should be adjusted to enforce these dependencies. Thanks!
> 1) This is occurring with the stock Linux kernel that ships with mainline > Linux > distributions (Fedora, Ubuntu, Arch Linux). It's affecting end users who just > want sound to work out-of-the-box, like it did before SOF was introduced. The notion of stock kernel is misleading, it all depends on what options are selected. > 2) If selecting both kernel configuration options would produce an invalid > build, that is a bug in the Kconfig files, which should be adjusted to > enforce > these dependencies. Indeed the distros don't seem to have a proper communication channel with driver developers to make sure the options make sense. We just had a case with Ubuntu where HDaudio support was removed due to the selection of an option explicitly marked as 'use at your own risk' We'll try to make the options more self-explanatory, in the mean time, can you please try and confirm the hypothesis that it's indeed a Kconfig option issue
Disabling SND_SOC_SOF_BROADWELL_SUPPORT does help at least on Dell Venue 11 Pro 7140.
Removing SND_SOC_SOF_BROADWELL_SUPPORT fixes Pixel 2015 audio on Arch default kernel config
(In reply to Pierre Bossart from comment #17) > The notion of stock kernel is misleading, it all depends on what options > are selected. Yes I agree with that. From your earlier message, I couldn't tell if it was clear that the settings were chosen by the distro (several of them), not accidentally selected by end users rebuilding the kernel with custom options. I think we're on the same page now. > We'll try to make the options more self-explanatory, in the mean time, > can you please try and confirm the hypothesis that it's indeed a Kconfig > option issue 1) With SND_SOC_SOF_INTEL_TOPLEVEL=n and SND_SOC_INTEL_SST_TOPLEVEL=y on v5.3.7: The reported errors disappear, and sound works (just like others have said). 2) With SND_SOC_SOF_INTEL_TOPLEVEL=y and SND_SOC_INTEL_SST_TOPLEVEL=n on v5.3.7: The reported errors disappear, but sound does not work. I manually installed the appropriate SOF v1.3 firmware file¹, and it loads: sof-audio-acpi INT3438:00: Firmware info: version 1:1:0-5dd9a sof-audio-acpi INT3438:00: Firmware: ABI 3:7:0 Kernel ABI 3:8:0 sof-audio-acpi INT3438:00: firmware boot complete but ALSA only sees the HDMI interface. This is appearing several times in dmesg: broadwell-audio broadwell-audio: info: override FE DAI link Codec broadwell-audio broadwell-audio: ASoC: CPU DAI snd-soc-dummy-dai not registered 3) With SND_SOC_SOF_INTEL_TOPLEVEL=y and SND_SOC_INTEL_SST_TOPLEVEL=y on the current sound subsystem tree (with the DSP probe module for Intel platforms²): The behavior is no different than what was originally described in this bug. Perhaps (2) is a separate issue (potentially misconfiguration on my part), and/or (3) may not be completed yet, but I hope this is useful. ¹ https://github.com/thesofproject/sof/releases/download/v1.3/sof-bdw-gcc.ri ² https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=82d9d54a6c0ee8b12211fa4e59fd940a2da4e063
Can you try to cherry-pick what's on https://github.com/thesofproject/linux/pull/1382 that should prevent SOF from being selected if you've already selected the legacy drivers.
With those commits cherry-picked on top of the current sound subsystem tree (aside from 65263bf16116 and 3f89e62cf14c, which both revert changes that are not in that tree), it works. The option for SOF support on Broadwell gets deselected automatically during the build, because the legacy driver is selected. One note about the help text added to Kconfig: see https://github.com/thesofproject/linux/pull/1382#pullrequestreview-309637829
Thanks for testing David, much appreciated.
(In reply to Pierre Bossart from comment #17) > Indeed the distros don't seem to have a proper communication channel > with driver developers to make sure the options make sense. It's not easy to have multiple drivers for the same hardware. This bug is just an example what we are trying to resolve in distros. We need to compile _ALL_ drivers and let users to choose the right one. The best practise is to select the correct driver at run-time with the possibility that the user might force another one. What we need to add the support the Chromebook Pixel 2015 to the universal distribution in this example. The SND_SOC_SOF_INTEL_TOPLEVEL=n is not a solution (DMIC for HDA DSP). Another option is SND_SOC_SOF_BROADWELL_SUPPORT=n . Ideally, we should have both SOF / SST drivers in the kernel and let users to select the right one (if the automatic selection does not work). If you confirm, that we can use the newer SOF driver for this hardware with the correct firmware files, it's also ok for us. The code in commit f35bf70f61d389754fafd7fce75efbb3bd2eea87 (comment #11) assumes that SOF _or_ SST driver is built exclusively.
Created attachment 286585 [details] dmesg output (5.4.7-arch1-1)
Created attachment 286587 [details] /proc/modules (5.4.7-arch1-1)
Created attachment 286589 [details] /proc/iomem (5.4.7-arch1-1)
Created attachment 286591 [details] lspci -vvv (5.4.7-arch1-1)
Created attachment 286593 [details] lsmod (5.4.7-arch1-1)
The issue seems to be resolved in the current kernel supplied with Arch Linux. I attached updated files to the report. > uname -a Linux pixie 5.4.7-arch1-1 #1 SMP PREEMPT Tue, 31 Dec 2019 17:20:16 +0000 x86_64 GNU/Linux > cat /proc/version Linux version 5.4.7-arch1-1 (linux@archlinux) (gcc version 9.2.0 (GCC)) #1 SMP PREEMPT Tue, 31 Dec 2019 17:20:16 +0000
FWIW there are still issues with the latest ALSA/ASoC code when using bdw-rt5677 with the legacy BIOS, see https://github.com/thesofproject/linux/pull/1659
After upgrade to the 5.5.1 kernel supplied with Arch Linux, the issue re-appeared. There is no error message in dmesg any more, so the reason may be different. > uname -a Linux pixie 5.5.1-arch1-1 #1 SMP PREEMPT Sat, 01 Feb 2020 16:38:40 +0000 x86_64 GNU/Linux > cat /proc/version Linux version 5.5.1-arch1-1 (linux@archlinux) (gcc version 9.2.0 (GCC)) #1 SMP PREEMPT Sat, 01 Feb 2020 16:38:40 +0000 I will attach the system logs separately.
Created attachment 287125 [details] dmesg output (5.5.1-arch1-1)
Created attachment 287127 [details] /proc/modules (5.5.1-arch1-1)
Created attachment 287129 [details] /proc/modules (5.5.1-arch1-1)
Created attachment 287131 [details] /proc/iomem (5.5.1-arch1-1)
Created attachment 287133 [details] lspci -vvv (5.5.1-arch1-1)
Created attachment 287135 [details] lsmod (5.5.1-arch1-1)
(In reply to Dmitry Savostyanov from comment #32) > After upgrade to the 5.5.1 kernel supplied with Arch Linux, the issue > re-appeared. There is no error message in dmesg any more, so the reason may > be different. Please file a different bug. The runtime conflict between SOF and SST drivers has been worked around for now, by making the Kconfig options mutually exclusive. This is still resolved even on Linux 5.5.1 (I'm testing on Arch Linux as well). The issue you are seeing may be related to ALSA userspace or to PulseAudio instead of the kernel; both have been undergoing changes including the conversion to UCM2 profiles, which has unintentionally broken sound in some cases [1]. Please check journalctl for more output. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1772498#c45