The audio chip ALC892 some times does not get recognized on startup. Only the HDMI devices are recognized correctly. It affects certain Clevo notebooks with board_name "N350TW". The problem happens on Ubuntu's (18.04 Ubuntu, Lubuntu, Budgie) as well as on openSUSE (15.1). So i think it does not depend on distribution. It seems to me that the state of the audio chip (recognizable/not recognizable) only (or most of the time) changes when the power plug gets removed/attached while the notebook is switched off and this happens more frequently when the battery is low. Here the ALSA-info file for a recognized ALC892: http://alsa-project.org/db/?f=a5ba97796ba72a35513707e0e696f5abce77fa15 Here the ALSA-info file for a unrecognized ALC892: http://alsa-project.org/db/?f=c2b42c21884c47be51f9ed35e1bd49b3b4bb31b9 On Ubuntu i managed to reactivate the audio chip by doing the following calls to the sysfs: echo auto | tee /sys/devices/pci0000\:00/0000\:00\:1f.3/power/control echo 1 | tee /sys/devices/pci0000\:00/0000\:00\:1f.3/remove echo 1 | tee /sys/bus/pci/rescan In openSUSE i don't have to change the file "control" but i still have to remove the device "0000:00:1f.3" and rescan the pci bus. Why is ALSA (or the kernel) not able to initialize the audio chip by itself? How can this be repaired? I would gladly assist with testing, information and help to solve this problem.
The fix mentioned above only works on some of the notebooks. On some it does not work at all.The sound chip never becomes visible to the kernel (mostly same hardware). I am trying to debug the kernel to see what is going wrong. I am thankful for any help i could get.
Is there any news on this? I have got a Clevo N350TW with Ubuntu 18.04.4 and HWE Kernel right by my side, which shows this annoying Error. No sound via the ALC892 (which is not recognized at all) and the Workaround above does not work. Only HDMI out seems to work when plugged in, otherwise only "Dummy output" is shown.
Problem persists with Kernel version 5.4.0 (Ubuntu 20.04).
I too have seen this problem. I have information that may be useful to anyone still seeking a work around. The machine in question is also a Clevo N350TW. When new (Xmas 2019) I tried a dozen Live distributions. No sound from the built in speakers but HDMI sound was good. Linux Mint 19.3 was installed with kernel 5.0.0 Sound on only three occasions in five months. Circumstances not known. An ALC892 device was 'present' only when sound worked but not otherwise. lspci reports the audio device as Cannon Lake PCH cAVS with kernel modules snd_hda_intel and snd_soc_skl. Linux Mint upgraded to kernel 5.3.0 (2020-05-51). No sound on boot. Kernel modules snd_hda_intel and sof_pci_dev. A script to remove the audio device from the PCI bus and rescan the bus failed to 'reactivate' sound. It ran in a loop for hundreds of iterations. Kernel 5.7.4 installed 2020-06-27. No sound on boot. However, removing the audio device and rescanning the PCI bus does 'reactivate' sound. Consistently. Kernel modules snd_hda_intel and snd_sof_pci. Comparing the output of alsa-info before and after the rescan, the first difference is: < HDA Intel PCH at 0x604b100000 irq 137 --- > HDA Intel PCH at 0x4010100000 irq 137 It seems that when there is no sound the kernel has the 'high' address and simply does not 'see' the ALC892. When it has the 'low' address it 'sees' the ALC892 and there is sound as there should be.
Hello everybody, I have the same problem with my laptop. It's also a CLEVO N350TW. I made a bug report here: https://bugzilla.kernel.org/show_bug.cgi?id=208695 and here: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1890869 Then I wrote a script like this (short form): echo auto > /sys/devices/pci0000\:00/0000\:00\:1f.3/power/control echo 1 > /sys/devices/pci0000\:00/0000\:00\:1f.3/remove echo 1 > /sys/bus/pci/rescan When I boot LINUX the script runs as root in a loop until the ALC892 is recognized. But the ALC892 is only recognized after I hear a crack from the speakers. Sometimes after 5 loops, sometimes after very many loops, sometimes never. Always after a crack. It doesn't matter whether the laptop runs on a battery or a charger. Meanwhile, I believe that the problem has nothing to do with ALSA or PULSEAUDIO. I think there is a problem with the pci scanning in conjunction with ACPI or PCI-Power-Management. Maybe PM-UTILS too. But that's for experts. I am not familiar with kernel drivers. Finally, I would like to apologize for my English. Everything was translated with GOOGLE.
I am having the same problem with my Gigabyte Z270 motherboard. The sound occasionally works after a reboot, then suddenly stops working after a few hours. I've even upgraded from Ubuntu 20.04 to Ubuntu 20.10 (5.8 kernel version), and the behavior is exactly the same. It's extremely annoying, because none of the solutions posted anywhere have worked for me. The only "fix" is to unplug the speaker jack from the back panel, and plug it into the front panel audio (headphone jack). That particular device switch seems to trigger something, so that the next time I plug it into the back panel, it works normally again for a few hours or so. And I tend to agree with Comment #5, as to this issue not truly being an ALSA or Pulseaudio problem at all, since in both cases (working properly and broken), the device is fully visible and recognized by the Ubuntu sound settings.
If you still see this problem, can you please boot with the "efi=debug" kernel parameter and attach the complete dmesg log here?
Hi, Sorry for the delay in getting back to you. The laptop isn't mine and I've not had access to it for some time. The good news is the problem seems to have been fixed. For us, the problem was apparent in the 5.4 kernel installed with Linux Mint 20. We tried the HWE kernel to see if that made any difference. The first HWE was 5.8 and we were able to work around the problem. When the HWE upgraded to 5.13 and later 5.15 the problem went away. I have had the chance to revisit the 5.4 kernel. Last year 5.4.0-77 exhibited the problem. This year 5.4.0-121 does not. So, as far as I am concerned, the problem is resolved. Many thanks.