Bug 205045 - ALC892 randomly not recognized on startup
Summary: ALC892 randomly not recognized on startup
Status: NEW
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: 2019-09-30 09:03 UTC by e.mohr
Modified: 2020-10-17 09:05 UTC (History)
4 users (show)

See Also:
Kernel Version: 4.18 5.0.0.29
Tree: Mainline
Regression: No


Attachments

Description e.mohr 2019-09-30 09:03:07 UTC
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.
Comment 1 e.mohr 2019-11-21 09:43:16 UTC
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.
Comment 2 r.kuehl 2020-02-25 12:17:26 UTC
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.
Comment 3 Vinzenz Vietzke 2020-04-27 11:44:58 UTC
Problem persists with Kernel version 5.4.0 (Ubuntu 20.04).
Comment 4 pb.roberts 2020-06-30 21:00:51 UTC
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.
Comment 5 bernd 2020-10-17 09:05:12 UTC
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.

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