click/pop noise in the headphone on several lenovo laptops

Bug #1805079 reported by Hui Wang
264
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Critical
Hui Wang
Bionic
Fix Released
Undecided
Unassigned
Cosmic
Fix Released
Critical
Unassigned

Bug Description

[Impact]
Lenovo told us that some linux uers reported headphone noise on Lenovo's
website. After investigating, we found those Lenovo laptop mdoels all
have the codec of alc285, and we can reproduce the noise problem too.

[Fix]
Don't use the DAC of headphone, let headphone share the DAC with speaker,
the noise disappears.

[Test Case]
After applying this patch, we tested on Lenovo P52, P72, X1 carbon and X1
Yoda2, no noise anymore

[Regression Potential]
Low. This patch only apply to several lenovo machines, and after applying
this patch, both speaker and headphone still work very well.

Hui Wang (hui.wang)
Changed in linux (Ubuntu):
importance: Undecided → Critical
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1805079

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Hui Wang (hui.wang) wrote :

hwang4@hwang4-Inspiron-7520:~/work/mainline/alsa/sound$ git show c4cfcf6f4297c9256b53790bacbbbd6901fef468
commit c4cfcf6f4297c9256b53790bacbbbd6901fef468 (origin/for-linus)
Author: Hui Wang <email address hidden>
Date: Mon Nov 26 14:17:16 2018 +0800

    ALSA: hda/realtek - fix the pop noise on headphone for lenovo laptops

    We have several Lenovo laptops with the codec alc285, when playing
    sound via headphone, we can hear click/pop noise in the headphone,
    if we let the headphone share the DAC of NID 0x2 with the speaker,
    the noise disappears.

    The Lenovo laptops here include P52, P72, X1 yoda2 and X1 carbon.

    I have tried to set preferred_dacs and override_conn, but neither of
    them worked. Thanks for Kailang, he told me to invalidate the NID 0x3
    through override_wcaps.

    BugLink: https://bugs.launchpad.net/bugs/1805079
    Cc: <email address hidden>
    Signed-off-by: Kailang Yang <email address hidden>
    Signed-off-by: Hui Wang <email address hidden>
    Signed-off-by: Takashi Iwai <email address hidden>

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1118fd1bbf1a..e66da22272fd 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5358,6 +5358,16 @@ static void alc274_fixup_bind_dacs(struct hda_codec *codec,
        spec->gen.preferred_dacs = preferred_pairs;
 }

+/* The DAC of NID 0x3 will introduce click/pop noise on headphones, so invalidate it */
+static void alc285_fixup_invalidate_dacs(struct hda_codec *codec,
+ const struct hda_fixup *fix, int action)
+{
+ if (action != HDA_FIXUP_ACT_PRE_PROBE)
+ return;
+
+ snd_hda_override_wcaps(codec, 0x03, 0);
+}
+
 /* for hda_fixup_thinkpad_acpi() */
 #include "thinkpad_helper.c"

@@ -5495,6 +5505,7 @@ enum {
        ALC255_FIXUP_DELL_HEADSET_MIC,
        ALC295_FIXUP_HP_X360,
        ALC221_FIXUP_HP_HEADSET_MIC,
+ ALC285_FIXUP_LENOVO_HEADPHONE_NOISE,
 };

 static const struct hda_fixup alc269_fixups[] = {
@@ -6362,6 +6373,10 @@ static const struct hda_fixup alc269_fixups[] = {
                .chained = true,
                .chain_id = ALC269_FIXUP_HEADSET_MIC
        },
+ [ALC285_FIXUP_LENOVO_HEADPHONE_NOISE] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc285_fixup_invalidate_dacs,
+ },
 };

 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7035,6 +7050,11 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = {
                {0x12, 0x90a60130},
                {0x19, 0x03a11020},
                {0x21, 0x0321101f}),
+ SND_HDA_PIN_QUIRK(0x10ec0285, 0x17aa, "Lenovo", ALC285_FIXUP_LENOVO_HEADPHONE_NOISE,
+ {0x12, 0x90a60130},
+ {0x14, 0x90170110},
+ {0x19, 0x04a11040},
+ {0x21, 0x04211020}),
        SND_HDA_PIN_QUIRK(0x10ec0288, 0x1028, "Dell", ALC288_FIXUP_DELL1_MIC_NO_PRESENCE,
                {0x12, 0x90a60120},
                {0x14, 0x90170110},

description: updated
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Seth Forshee (sforshee)
Changed in linux (Ubuntu):
status: Confirmed → Fix Committed
Revision history for this message
AceLan Kao (acelankao) wrote :

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-bionic
Revision history for this message
Vadim Vygonets (vygonets) wrote :

Awesome fix, Hui Wang, thank you!

I'm on Lenovo ThinkPad X1 Carbon 6th, model 20KH006JGE. After upgrading to Linux 4.19.7, the audio mute and microphone mute LEDs (on F1 and F4 keys) stopped working. They do work if I remove the line:

                {0x12, 0x90a60130},

Just removing it doesn't sound like the greatest idea, but I couldn't find the ALC285 datasheet online. If you could direct me to information about ALC285 registers so that I can fix the issue, or provide me with another value for the register so that I can test it, it will be greatly appreciated.

Many thanks,
Vadim.

Revision history for this message
Hui Wang (hui.wang) wrote :

@Vadim,

Need to add the code as below:
  .chained = true,
  .chain_id = ALC269_FIXUP_THINKPAD_ACPI

I will send the patch to fix it.

Thanks.

tags: added: verification-done-bionic
removed: verification-needed-bionic
Revision history for this message
Vadim Vygonets (vygonets) wrote :

Hi Hui Wang,

I added the lines and now everything works perfectly. Thank you!

Revision history for this message
Hui Wang (hui.wang) wrote :

Hello Vadim,

already sent the patch to review, let us wait for the next release.

Thanks.

Revision history for this message
Vadim Vygonets (vygonets) wrote :

Hi Hui Wang,

While waiting for your patch to reach the mainline, I just insert these two lines myself.

However, I still have issues with the sound.

Scenario: laptop is off, headphones are inserted, sound (both mic and output) is muted; I turn it on, log in etc., unmute the output and play something.

The sound is often too quiet (maybe 10 to 15 dB weaker than expected). If I unplug the headphones and plug them back in, the sound level rises to expected levels, but I start hearing noise reminiscent of cheap soundcards (with grounding problems?), where the noise characteristics change with the activity of other devices (e.g., mouse movements). The noise is stronger if I touch the touchpad. If I mute the sound, the noise disappears.

This does not happen if I remove the "0x12" line, whether or not I add the .chained/.chain_id lines. Interestingly, init_pin_configs in sysfs shows the same value for 0x12:

$ cat /sys/class/sound/hwC0D0/init_pin_configs
0x12 0x90a60130
0x13 0x40000000
0x14 0x90170110
0x16 0x411111f0
0x17 0x411111f0
0x18 0x411111f0
0x19 0x04a11040
0x1a 0x411111f0
0x1b 0x411111f0
0x1d 0x40600001
0x1e 0x411111f0
0x21 0x04211020

(driver_pin_configs and user_pin_configs are empty.)

Thank you,
Vadim.

Revision history for this message
Hui Wang (hui.wang) wrote :

@Vadim,

I will try to reproduce your problem next week.

thanks.
hui.

Revision history for this message
Vadim Vygonets (vygonets) wrote :

Awesome, thank you. Let me know if you want me to run particular tests or provide information. I'm not sure if the issue manifests every time.

On kernels before 4.19.7 I was hearing noise sometimes, especially after waking up from S3 sleep, but S4 hibernation or reboot (possibly turning the machine off was required) was solving it every time. I did not have the issue with quiet sound output.

Have a nice weekend,
Vadim.

Revision history for this message
Hui Wang (hui.wang) wrote :

@Vadim,

For comment#8, I can reproduce the former parts, but "I start hearing noise reminiscent of cheap soundcards..." can't be reproduced, there is no noise on my machine (x1 carbon).

Revision history for this message
Vadim Vygonets (vygonets) wrote :

Hui Wang,

Apologies for the slow reply.

Do you mean that you also have quiet sound after the boot?

Today I upgraded to 4.19.12, and the results seem the same. I'm running Funtoo Linux with "gentoo-sources" kernel, HDA and the Realtek codec as modules and plain ALSA with no daemons. I tried to compile them into the main kernel image, but the results were the same, except that the LEDs didn't work.

Here are sone more details:

The noise level I hear does not change with the playback volume. It's stronger when I play something (e.g., with mplayer) or touch the touchpad.

Without the 0x12 line, alsamixer shows heasphone and speaker controls at 100%, and "alsactl store" has {Headphone,Speaker} Playback {Volume,Switch}. Under the standard kernel (with your patch), the aforementioned controls in alsamixer show up as "00" in a box, and alsactl has only "Line Out Playback Volume" (and the two Switches). Is it possible that "line out" is treated differently from "headphone" by the hardware, or is it just a name?

With the standard kernel, the output of "alsactl store" is identical whether the sound is in the "too quiet" state or in the "noisy headphone" state.

Sometimes after I warm-reboot from a standard kernel to a kernel without the 0x12 line, I hear clicks when muting and unmuting the output, or noise, but they disappear after I play something.

I put my kernel config and alsactl store output under http://www.vygo.net/hda/ but I don't know if it aids debugging in any way. Do you think it may help if I try your kernel config?

Thank you for your efforts and, if appropriate, merry Christmas.

Revision history for this message
Hui Wang (hui.wang) wrote :

I also have the quiet sound after the boot (but not too quiet).

About the noise you mentioned, I didn't hear that yet.

About the "Line Out Playback Volume" and "{Headphone,Speaker} Playback Volume, without my patch, the Headphone and Speaker has its own independent DAC, with my patch, they share one DAC, then the mixer name is changed to "Line Out".

Could you generate 2 alsa-info.txt?

1) under the quiet sound condition, sudo echo 1 > /sys/modules/snd_hda_codec/parameters/dump_coef; alsa-info.sh; then upload the generated alsa-info.txt-quiet-headphone

2) after the sound change back to normal (quiet->not quiet), sudo echo 1 > /sys/modules/snd_hda_codec/parameters/dump_coef; alsa-info.sh; then upload the generated alsa-info.txt-notquiet-headphone.

thanks.

Revision history for this message
Vadim Vygonets (vygonets) wrote :

The script uploaded the info under random names, but they're the same anyway.

Quiet:
http://www.alsa-project.org/db/?f=7712362b1f31c1c142d4016983e648b99d8e5036

Not quiet:
http://www.alsa-project.org/db/?f=579cbfe2a915281a46e449a07b4f359917191943

I also generated one without the 0x12 line:
http://www.alsa-project.org/db/?f=d439ec39632f226a7c156df5373df31de28f4a53

Thank you!

Revision history for this message
Hui Wang (hui.wang) wrote :

For the quiet and non-quiet problem, since there is no difference between 1st and 2nd alsa-info.txt, I really have no idea what is the root cause for this problem. Probably, we can do another test:
don't plug the headphone in poweroff state,
poweron the machine, and let machine enter grub, then plug the headphone, after that, let machine boot linux kernel..., let us see if the headphone is still quiet or not, if not, it looks like bios do sth if plugging headphone in poweroff state.

For the noise problem, since I did not hear the noise in my test two weeks ago, and I don't have machine in my hand now, I need to wait for ending of holiday (after new year holiday), then I will get the machines and redo the test.

thanks.

Revision history for this message
Vadim Vygonets (vygonets) wrote :

Plugging the headphones during Grub doesn't seem to matter.

thanks!

Revision history for this message
Hui Wang (hui.wang) wrote :

@Vadim

Today I tested on lenovo P72 and Yoda again, I installed the kernel here (https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.20/), I can't reproduce the noise you mentioned. I can reproduce the quiet volume issue on both machines.

Revision history for this message
James Thorne (jameswthorne) wrote :

I am using an X1 Carbon Gen 6 (BIOS 1.31) with Ubuntu 18.04.1 LTS, and I too experience the popping sounds in the left-channel of my headphones (this does not occur when connecting the same headphones with a 3.5mm-to-USB-C adapter to the second USB-C port).

Other than that issue, audio through the headphones sounds great and can get very loud (I typically cannot go above 58%), but audio through the speakers can get tinny/distorted and is quiet at 100%. I believe this is a known issue with the X1 Carbon's speakers and is probably unrelated to the issue at hand, but I thought it is worth mentioning since there is discussion in this thread about using the speaker's DAC for the headphones instead of the headphone's DAC.

I applied the changes mentioned here [1], and the popping sounds in the left-channel of my headphones appear to have stopped. I have been using this video [2] to test before and after the changes due to its wide range of audio and vocals (quiet, normal, and loud moments).

alsa-info: http://www.alsa-project.org/db/?f=d961cfbf429bc18b38ce8d1cf8e931482ba4a627

[1] https://forums.lenovo.com/t5/Linux-Discussion/X1-Carbon-Gen-6-weird-audio-behaviour/m-p/4172468/highlight/true#M11520

[2] https://youtu.be/f2kesmAO8VU

Revision history for this message
Hui Wang (hui.wang) wrote :

@James, thanks for your comment, the kernel of 18.04.1 doesn't include my patches yet, you can have a try https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.20/, to see if you still can experience popping from L-Channel and if you can hear noise from headphone (#12).

Revision history for this message
Hui Wang (hui.wang) wrote :

@Vadim,

Since James pointed out a solution, let us test if this workaround can fix the noise of headphone on your machine?

After you heard the noise from headphone, run "sudo hda-verb /dev/snd/hwC0D0 0x1d SET_PIN_WIDGET_CONTROL 0x0" in the terminal. Then can you still hear the noise?

Revision history for this message
Vadim Vygonets (vygonets) wrote :

Hui Wang,

Yes, this solves the noise issue. Both the modprobe method from Lenovo forum and the command you provided work perfectly. Thank you, and thank you James!

I still have quiet sound initially. And, now that I compared it to the kernel without the 0x12 line, it seems that the sound is quieter also after replugging the headphones (which must be dome while sound is playing). It's about 20dB lower before replugging and about 10dB lower after, and perhaps less bassy, though I may be imagining things here. I'm testing it with http://www.vygo.net/hda/11-Ultimatum.ogg which has strong bass indeed. But I understand that you can reproduce it, so I trust in you :)

Many thanks for solving the noise issue, and happy new year!
Vadim.

Revision history for this message
James Thorne (jameswthorne) wrote :

I think the poster here [1] and here [2] are the same person. That person mentions in the Lenovo thread [2] that the "sudo hda-verb /dev/snd/hwC0D0 0x1d SET_PIN_WIDGET_CONTROL 0x0" command is temporary, and to permanently apply it the method mentioned in the same Lenovo thread needs to be done.

Knowing that either of those methods appear to be the fix, what is necessary to resolve this permanently and not require the method mentioned here [2]?

Additionally, for my own curiosity, what exactly is happening when applying either of the fixes?

Thanks.

[1] https://www.reddit.com/r/thinkpad/comments/8j8208/audio_crackling_through_both_headphone_jack_and/

[2] https://forums.lenovo.com/t5/Linux-Discussion/X1-Carbon-Gen-6-weird-audio-behaviour/m-p/4172468/highlight/true#M11520

Revision history for this message
Vadim Vygonets (vygonets) wrote :

The two methods appear to do the same, except hda-verb applies the change when run and the other method at the time the hda kernel module is loaded. You can run hda-verb at boot instead, but the other method looks cleaner to me, as it applies the fix when the hardware is configured by the driver. I believe this fix can also be added to the driver itself.

As I described above[0], after Hui Wang fixed this bug here that we're commenting on[1], I started to hear noise in headphones. This is not occasional crackling sound, this is constant annoying noise. Not every gen6 Carbon has this issue, apparently. This fixes the issue.

[0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1805079/comments/8

[1] https://lkml.org/lkml/2018/12/4/520

Revision history for this message
Hui Wang (hui.wang) wrote :

Let me consult the expert of Realtek codec, to see if we can get some explanation from him.

Revision history for this message
Vadim Vygonets (vygonets) wrote :

Thank you!

Meanwhile I use modprobe to configure the "verb", but also run hda-verb on wakeup from sleep or hibernation.

Revision history for this message
Vadim Vygonets (vygonets) wrote :

Hui Wang,

BTW, in case the sound card distinguishes between headphone out and line out modes, thus may be relevant: my headphones have impedance of 70Ω.

Vadim.

Stefan Bader (smb)
Changed in linux (Ubuntu Cosmic):
importance: Undecided → Critical
status: New → Fix Committed
Changed in linux (Ubuntu Bionic):
status: New → Fix Committed
Revision history for this message
Hui Wang (hui.wang) wrote :

Realtek told me that in the alc285, the pin 0x1d is for PC beep in, if PC beep in has noise, it will affect speaker or headphone, set the pinctl of 0x1d to 0x0 is helpful to reduce the noise or close the pc peep in passthrough by setting 0x57d7 to Node 0x20 COEF index 0x36.

Revision history for this message
Brad Figg (brad-figg) wrote :

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-cosmic' to 'verification-done-cosmic'. If the problem still exists, change the tag 'verification-needed-cosmic' to 'verification-failed-cosmic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-cosmic
Hui Wang (hui.wang)
tags: added: verification-done-cosmic
removed: verification-needed-cosmic
Revision history for this message
Vincenzoml (vincenzoml) wrote :

Wait, I just found out about this bug today. I am available to test and am going to test right now, but can the fix be added to source again? What's the procedure?

Revision history for this message
Vincenzoml (vincenzoml) wrote :

Ah sorry, I misunderstood the comment. So verification is done and the fix will be committed? What a relief, on a 2.5k euros laptop the hissing was really unbearable.

Revision history for this message
Hui Wang (hui.wang) wrote :

@vincezoml,

You also met the hissing problem? could you elaborate a little bit on it? And in what kernel versions did you meet this problem?

Revision history for this message
Vadim Vygonets (vygonets) wrote :

Hui Wang,

Do you have a patch to set the values? I don't run Ubuntu. Is there a publicly accessible branch with -proposed patches?

Thank you!

Revision history for this message
Hui Wang (hui.wang) wrote :

@Vadim,

Not yet.

According to [1], the noise you mentioned in the #8 is reported by someone already before my patch is merged to linux kernel, but in the #8, you wrote "This does not happen if I remove the "0x12" line", and it looks like even don't remove "0x12" line, running "sudo hda-verb /dev/snd/hwC0D0 0x1d SET_PIN_WIDGET_CONTROL 0x0" also can fix it.

I am a little bit confused. is the noise related to the "0x12" line (my patch)?

Thanks.

[1] https://forums.lenovo.com/t5/Linux-Discussion/X1-Carbon-Gen-6-weird-audio-behaviour/m-p/4172468/highlight/true#M11520

Revision history for this message
Vadim Vygonets (vygonets) wrote :

Hui Wang,

Apologies for the slow reply.

Do you mean that you also have quiet sound after the boot?

Today I upgraded to 4.19.12, and the results seem the same. I'm running Funtoo Linux with "gentoo-sources" kernel, HDA and the Realtek codec as modules and plain ALSA with no daemons. I tried to compile them into the main kernel image, but the results were the same, except that the LEDs didn't work.

Here are sone more details:

The noise level I hear does not change with the playback volume. It's stronger when I play something (e.g., with mplayer) or touch the touchpad.

Without the 0x12 line, alsamixer shows heasphone and speaker controls at 100%, and "alsactl store" has {Headphone,Speaker} Playback {Volume,Switch}. Under the standard kernel (with your patch), the aforementioned controls in alsamixer show up as "00" in a box, and alsactl has only "Line Out Playback Volume" (and the two Switches).

With the standard kernel, the output of "alsactl store" is identical whether the sound is in the "too quiet" state or in the "noisy headphone" state.

Sometimes after I warm-reboot from a standard kernel to a kernel without the 0x12 line, I hear clicks when muting and unmuting the output, or noise, but they disappear after I play something (e.g., with mplayer).

Revision history for this message
Vadim Vygonets (vygonets) wrote :

Hui Wang,

Without the 0x12 line (but with the rest of your patch) there is no noise.

Likewise, with your patch (standard kernel), running hda-verb or loading the module with the equivalent options also stops the noise.

Additionally, with your full patch the sound is 10dB lower (or 20dB lower before replugging the headphones) than without the 0x12 line.

Thanks,
Vadim.

Revision history for this message
Vadim Vygonets (vygonets) wrote :

(sorry about comment #34, please disregard)

Revision history for this message
Hui Wang (hui.wang) wrote :

@Vadim,

since I can't reproduce the noise you mentioned, I can't verify this patch.

Could you please build a kernel with the patch below and do a test? thanks.

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index aee4cbd29d53..e20cf752ce76 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5582,6 +5582,7 @@ enum {
        ALC294_FIXUP_ASUS_HEADSET_MIC,
        ALC294_FIXUP_ASUS_SPK,
        ALC225_FIXUP_HEADSET_JACK,
+ ALC285_FIXUP_LENOVO_PC_BEEP_IN_NOISE,
 };

 static const struct hda_fixup alc269_fixups[] = {
@@ -6522,6 +6523,17 @@ static const struct hda_fixup alc269_fixups[] = {
                .type = HDA_FIXUP_FUNC,
                .v.func = alc_fixup_headset_jack,
        },
+ [ALC285_FIXUP_LENOVO_PC_BEEP_IN_NOISE] = {
+ .type = HDA_FIXUP_VERBS,
+ .v.verbs = (const struct hda_verb[]) {
+ /* Set EAPD high */
+ { 0x20, AC_VERB_SET_COEF_INDEX, 0x36 },
+ { 0x20, AC_VERB_SET_PROC_COEF, 0x57d7 },
+ { }
+ },
+ .chained = true,
+ .chain_id = ALC285_FIXUP_LENOVO_HEADPHONE_NOISE
+ },
 };

 static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -7205,7 +7217,7 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = {
                {0x12, 0x90a60130},
                {0x19, 0x03a11020},
                {0x21, 0x0321101f}),
- SND_HDA_PIN_QUIRK(0x10ec0285, 0x17aa, "Lenovo", ALC285_FIXUP_LENOVO_HEADPHONE_NOISE,
+ SND_HDA_PIN_QUIRK(0x10ec0285, 0x17aa, "Lenovo", ALC285_FIXUP_LENOVO_PC_BEEP_IN_NOISE,
                {0x12, 0x90a60130},
                {0x14, 0x90170110},
                {0x19, 0x04a11040},

Revision history for this message
Vadim Vygonets (vygonets) wrote :

Hui Wang,

After applying the patch to 4.20.4 (and even after removing hda-verb on module load and wake-up from sleep / hibernation), there's no noise, neither after boot nor after S3 sleep or hibernation. Yes!!!

The quiet sound still remains. After testing it again (mplayer, http://www.vygo.net/hda/11-Ultimatum.ogg 4:00-4:30) I'm pretty sure the EQ is different. The bass is about 10dB lower; the middles also lower but not by as much.

Thanks for your hard work,
Vadim.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (47.0 KiB)

This bug was fixed in the package linux - 4.15.0-44.47

---------------
linux (4.15.0-44.47) bionic; urgency=medium

  * linux: 4.15.0-44.47 -proposed tracker (LP: #1811419)

  * Packaging resync (LP: #1786013)
    - [Packaging] update helper scripts

  * CPU hard lockup with rigorous writes to NVMe drive (LP: #1810998)
    - blk-wbt: pass in enum wbt_flags to get_rq_wait()
    - blk-wbt: Avoid lock contention and thundering herd issue in wbt_wait
    - blk-wbt: move disable check into get_limit()
    - blk-wbt: use wq_has_sleeper() for wq active check
    - blk-wbt: fix has-sleeper queueing check
    - blk-wbt: abstract out end IO completion handler
    - blk-wbt: improve waking of tasks

  * To reduce the Realtek USB cardreader power consumption (LP: #1811337)
    - mmc: sdhci: Disable 1.8v modes (HS200/HS400/UHS) if controller can't support
      1.8v
    - mmc: core: Introduce MMC_CAP_SYNC_RUNTIME_PM
    - mmc: rtsx_usb_sdmmc: Don't runtime resume the device while changing led
    - mmc: rtsx_usb: Use MMC_CAP2_NO_SDIO
    - mmc: rtsx_usb: Enable MMC_CAP_ERASE to allow erase/discard/trim requests
    - mmc: rtsx_usb_sdmmc: Re-work runtime PM support
    - mmc: rtsx_usb_sdmmc: Re-work card detection/removal support
    - memstick: rtsx_usb_ms: Add missing pm_runtime_disable() in probe function
    - misc: rtsx_usb: Use USB remote wakeup signaling for card insertion detection
    - memstick: Prevent memstick host from getting runtime suspended during card
      detection
    - memstick: rtsx_usb_ms: Use ms_dev() helper
    - memstick: rtsx_usb_ms: Support runtime power management

  * Support non-strict iommu mode on arm64 (LP: #1806488)
    - iommu/io-pgtable-arm: Fix race handling in split_blk_unmap()
    - iommu/arm-smmu-v3: Implement flush_iotlb_all hook
    - iommu/dma: Add support for non-strict mode
    - iommu: Add "iommu.strict" command line option
    - iommu/io-pgtable-arm: Add support for non-strict mode
    - iommu/arm-smmu-v3: Add support for non-strict mode
    - iommu/io-pgtable-arm-v7s: Add support for non-strict mode
    - iommu/arm-smmu: Support non-strict mode

  * ELAN900C:00 04F3:2844 touchscreen doesn't work (LP: #1811335)
    - pinctrl: cannonlake: Fix community ordering for H variant
    - pinctrl: cannonlake: Fix HOSTSW_OWN register offset of H variant

  * Add Cavium ThunderX2 SoC UNCORE PMU driver (LP: #1811200)
    - perf: Export perf_event_update_userpage
    - Documentation: perf: Add documentation for ThunderX2 PMU uncore driver
    - drivers/perf: Add Cavium ThunderX2 SoC UNCORE PMU driver
    - [Config] New config CONFIG_THUNDERX2_PMU=m

  * Update hisilicon SoC-specific drivers (LP: #1810457)
    - SAUCE: Revert "net: hns3: Updates RX packet info fetch in case of multi BD"
    - Revert "UBUNTU: SAUCE: {topost} net: hns3: separate roce from nic when
      resetting"
    - Revert "UBUNTU: SAUCE: {topost} net: hns3: Use roce handle when calling roce
      callback function"
    - Revert "UBUNTU: SAUCE: {topost} net: hns3: Add calling roce callback
      function when link status change"
    - Revert "UBUNTU: SAUCE: {topost} net: hns3: optimize the process of notifying
      roce client"
    - Revert "UBUNTU: S...

Changed in linux (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (56.3 KiB)

This bug was fixed in the package linux - 4.18.0-14.15

---------------
linux (4.18.0-14.15) cosmic; urgency=medium

  * linux: 4.18.0-14.15 -proposed tracker (LP: #1811406)

  * CPU hard lockup with rigorous writes to NVMe drive (LP: #1810998)
    - blk-wbt: Avoid lock contention and thundering herd issue in wbt_wait
    - blk-wbt: move disable check into get_limit()
    - blk-wbt: use wq_has_sleeper() for wq active check
    - blk-wbt: fix has-sleeper queueing check
    - blk-wbt: abstract out end IO completion handler
    - blk-wbt: improve waking of tasks

  * To reduce the Realtek USB cardreader power consumption (LP: #1811337)
    - mmc: core: Introduce MMC_CAP_SYNC_RUNTIME_PM
    - mmc: rtsx_usb_sdmmc: Don't runtime resume the device while changing led
    - mmc: rtsx_usb_sdmmc: Re-work runtime PM support
    - mmc: rtsx_usb_sdmmc: Re-work card detection/removal support
    - memstick: rtsx_usb_ms: Add missing pm_runtime_disable() in probe function
    - misc: rtsx_usb: Use USB remote wakeup signaling for card insertion detection
    - memstick: Prevent memstick host from getting runtime suspended during card
      detection
    - memstick: rtsx_usb_ms: Use ms_dev() helper
    - memstick: rtsx_usb_ms: Support runtime power management

  * Support non-strict iommu mode on arm64 (LP: #1806488)
    - iommu/io-pgtable-arm: Fix race handling in split_blk_unmap()
    - iommu/arm-smmu-v3: Implement flush_iotlb_all hook
    - iommu/dma: Add support for non-strict mode
    - iommu: Add "iommu.strict" command line option
    - iommu/io-pgtable-arm: Add support for non-strict mode
    - iommu/arm-smmu-v3: Add support for non-strict mode
    - iommu/io-pgtable-arm-v7s: Add support for non-strict mode
    - iommu/arm-smmu: Support non-strict mode

  * [Regression] crashkernel fails on HiSilicon D05 (LP: #1806766)
    - efi: honour memory reservations passed via a linux specific config table
    - efi/arm: libstub: add a root memreserve config table
    - efi: add API to reserve memory persistently across kexec reboot
    - irqchip/gic-v3-its: Change initialization ordering for LPIs
    - irqchip/gic-v3-its: Simplify LPI_PENDBASE_SZ usage
    - irqchip/gic-v3-its: Split property table clearing from allocation
    - irqchip/gic-v3-its: Move pending table allocation to init time
    - irqchip/gic-v3-its: Keep track of property table's PA and VA
    - irqchip/gic-v3-its: Allow use of pre-programmed LPI tables
    - irqchip/gic-v3-its: Use pre-programmed redistributor tables with kdump
      kernels
    - irqchip/gic-v3-its: Check that all RDs have the same property table
    - irqchip/gic-v3-its: Register LPI tables with EFI config table
    - irqchip/gic-v3-its: Allow use of LPI tables in reserved memory
    - arm64: memblock: don't permit memblock resizing until linear mapping is up
    - efi/arm: Defer persistent reservations until after paging_init()
    - efi: Permit calling efi_mem_reserve_persistent() from atomic context
    - efi: Prevent GICv3 WARN() by mapping the memreserve table before first use

  * ELAN900C:00 04F3:2844 touchscreen doesn't work (LP: #1811335)
    - pinctrl: cannonlake: Fix community ordering for H variant
    - pinctrl: c...

Changed in linux (Ubuntu Cosmic):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (14.1 KiB)

This bug was fixed in the package linux - 4.19.0-12.13

---------------
linux (4.19.0-12.13) disco; urgency=medium

  * linux: 4.19.0-12.13 -proposed tracker (LP: #1813664)

  * kernel oops in bcache module (LP: #1793901)
    - SAUCE: bcache: never writeback a discard operation

  * Disco update: 4.19.18 upstream stable release (LP: #1813611)
    - ipv6: Consider sk_bound_dev_if when binding a socket to a v4 mapped address
    - mlxsw: spectrum: Disable lag port TX before removing it
    - mlxsw: spectrum_switchdev: Set PVID correctly during VLAN deletion
    - net: dsa: mv88x6xxx: mv88e6390 errata
    - net, skbuff: do not prefer skb allocation fails early
    - qmi_wwan: add MTU default to qmap network interface
    - ipv6: Take rcu_read_lock in __inet6_bind for mapped addresses
    - net: clear skb->tstamp in bridge forwarding path
    - netfilter: ipset: Allow matching on destination MAC address for mac and
      ipmac sets
    - gpio: pl061: Move irq_chip definition inside struct pl061
    - drm/amd/display: Guard against null stream_state in set_crc_source
    - drm/amdkfd: fix interrupt spin lock
    - ixgbe: allow IPsec Tx offload in VEPA mode
    - platform/x86: asus-wmi: Tell the EC the OS will handle the display off
      hotkey
    - e1000e: allow non-monotonic SYSTIM readings
    - usb: typec: tcpm: Do not disconnect link for self powered devices
    - selftests/bpf: enable (uncomment) all tests in test_libbpf.sh
    - of: overlay: add missing of_node_put() after add new node to changeset
    - writeback: don't decrement wb->refcnt if !wb->bdi
    - serial: set suppress_bind_attrs flag only if builtin
    - bpf: Allow narrow loads with offset > 0
    - ALSA: oxfw: add support for APOGEE duet FireWire
    - x86/mce: Fix -Wmissing-prototypes warnings
    - MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur
    - crypto: ecc - regularize scalar for scalar multiplication
    - arm64: perf: set suppress_bind_attrs flag to true
    - drm/atomic-helper: Complete fake_commit->flip_done potentially earlier
    - clk: meson: meson8b: fix incorrect divider mapping in cpu_scale_table
    - samples: bpf: fix: error handling regarding kprobe_events
    - usb: gadget: udc: renesas_usb3: add a safety connection way for
      forced_b_device
    - fpga: altera-cvp: fix probing for multiple FPGAs on the bus
    - selinux: always allow mounting submounts
    - ASoC: pcm3168a: Don't disable pcm3168a when CONFIG_PM defined
    - scsi: qedi: Check for session online before getting iSCSI TLV data.
    - drm/amdgpu: Reorder uvd ring init before uvd resume
    - rxe: IB_WR_REG_MR does not capture MR's iova field
    - efi/libstub: Disable some warnings for x86{,_64}
    - jffs2: Fix use of uninitialized delayed_work, lockdep breakage
    - clk: imx: make mux parent strings const
    - pstore/ram: Do not treat empty buffers as valid
    - media: uvcvideo: Refactor teardown of uvc on USB disconnect
    - powerpc/xmon: Fix invocation inside lock region
    - powerpc/pseries/cpuidle: Fix preempt warning
    - media: firewire: Fix app_info parameter type in avc_ca{,_app}_info
    - ASoC: use dma_ops of parent device for acp_audio_dma
    - media: ve...

Changed in linux (Ubuntu):
status: Fix Committed → Fix Released
Lawrence Chiu (lawchiu)
information type: Public → Public Security
Brad Figg (brad-figg)
tags: added: cscc
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.