Bug 206851 - Strange issue... Kernel hangs since 5.4.19 and not when i disable mic in the BIOS
Summary: Strange issue... Kernel hangs since 5.4.19 and not when i disable mic in the ...
Status: RESOLVED INVALID
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: Intel Linux
: P1 high
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-14 06:19 UTC by Jean-Luc Livémont
Modified: 2020-03-15 13:42 UTC (History)
1 user (show)

See Also:
Kernel Version: 5.5.8-200
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Jean-Luc Livémont 2020-03-14 06:19:04 UTC
Hello.
Since 5.4.19, my laptop dell vostro 5790 hang while init 5. (init 3 was OK)
I tried to install last BIOS without effect.
I looked fir a moment at the cause of this (not an expert) but i found nothing nore in journalctl, dmesg or xorg log that explains this...
Finaly i have disabled some programs loaded during the boot without effect.
I tried to diasble the audio card in the bios and the laptop has can boot normaly... I have reactivated the audio but without the mic and i could boot normaly...
I guess this issue is due to the kernel support of the sound architecture...
The audio controler is Multimedia audio controller: Intel Corporation Cannon Lake PCH cAVS (rev 10)
cat /proc/asound/pcm
00-00: ALC3254 Analog : ALC3254 Analog : playback 1 : capture 1
00-02: ALC3254 Alt Analog : ALC3254 Alt Analog : capture 1
00-03: HDMI 0 : HDMI 0 : playback 1
00-07: HDMI 1 : HDMI 1 : playback 1
00-08: HDMI 2 : HDMI 2 : playback 1
00-09: HDMI 3 : HDMI 3 : playback 1
00-10: HDMI 4 : HDMI 4 : playback 1

dmesg |grep snd
[   29.555427] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
[   29.555547] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[   29.555656] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[   29.845847] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3254: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   29.845852] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   29.845855] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[   29.845858] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
[   29.845860] snd_hda_codec_realtek hdaudioC0D0:    inputs:
[   29.845863] snd_hda_codec_realtek hdaudioC0D0:      Headphone Mic=0x1b
[   29.845866] snd_hda_codec_realtek hdaudioC0D0:      Headset Mic=0x19

grubby --info=ALL
index=0
kernel="/boot/vmlinuz-5.5.8-200.fc31.x86_64"
args="ro resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet"
root="/dev/mapper/fedora_localhost--live-root"
initrd="/boot/initramfs-5.5.8-200.fc31.x86_64.img"
title="Fedora (5.5.8-200.fc31.x86_64) 31 (Thirty One)"
id="580cd2f5cac54cb09251204e43285a8e-5.5.8-200.fc31.x86_64"

Can you help me?
Comment 1 Jean-Luc Livémont 2020-03-14 06:51:47 UTC
I continued my investigations ...
I found this workaround which allows me to leave the microphone on in the BIOS

grubby --update-kernel="/boot/vmlinuz-5.5.8-200.fc31.x86_64" --args="snd-hda-intel.dmic_detect=0"

The kernel 5.5.8 is now running (without microphone, of course...

I am at your disposal to test firmware or kernel corrections on my architecture if necessary...

I hope this issue will be fixed in the future kernel versions.

:)
Comment 2 Takashi Iwai 2020-03-14 07:57:53 UTC
Right, this is a known issue for some audio devices that has HD-audio DSP and DMIC.  It's switched to SOF driver and you'd need proper firmware files in addition to the very recent version of alsa-lib and PulseAudio.

In the recent kernel version (5.5 and later), the module switch was changed.
Now the effectively same workaround is:
  snd-intel-dspcfg.dsp_driver=1
Comment 3 Jaroslav Kysela 2020-03-14 15:20:18 UTC
F31 requires to install latest alsa-firmware, alsa-ucm and pulseaudio packages for this hardware. Anyway, the hang looks suspicious. Create a Fedora bug for this with the kernel log. I'll check.

Note You need to log in before you can comment on or make changes to this bug.