Re: [REGRESSION] Speaker pop/chirp on Meteor Lake ALC287 (17aa:231e) -- 6.12.73 to 6.12.85
Takashi Iwai <[email protected]>
| Newsgroups | dev.linux.lists.regressions,org.kernel.vger.linux-kernel,org.kernel.vger.linux-sound,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 28 May 2026 20:27:30 +0200, Mike Karcic wrote: > > Yes, I can confirm the patched kernel is running, and commenting out that line fixes the problem completely. > > Below is output with the added debug lines as requested: > > $ uname -r > 6.12.90-debug-no-discoefs > > $ sudo dmesg | grep -i "alc287_alc1318" > [ 453.823528] snd_hda_codec_realtek ehdaudio0D0: alc287_alc1318_playback_pcm_hook called action=0 > [ 453.871577] snd_hda_codec_realtek ehdaudio0D0: alc287_alc1318_playback_pcm_hook called action=1 > [ 459.605379] snd_hda_codec_realtek ehdaudio0D0: alc287_alc1318_playback_pcm_hook called action=2 > [ 459.605497] snd_hda_codec_realtek ehdaudio0D0: alc287_alc1318_playback_pcm_hook called action=3 > > $ grep -n -A5 -B2 "alc_process_coef_fw.*dis_coefs" sound/pci/hda/patch_realtek.c > 7918- return; > 7919- alc_update_coef_idx(codec, 0x10, 1<<11, 1<<11); > 7920: /* alc_process_coef_fw(codec, dis_coefs); */ /* commented out for testing */ > 7921- alc_process_coef_fw(codec, coefs); > 7922- spec->power_hook = alc287_s4_power_gpio3_default; > 7923- spec->gen.pcm_playback_hook = alc287_alc1318_playback_pcm_hook; > 7924-} Hm, then the previous fix doesn't seem working, obviously. Kailang, could you check this in your side? Maybe we should apply the AMP-silence-detection disablement conditionally to certain models? thanks, Takashi > > > > Sent with Proton Mail secure email. > > On Thursday, May 28th, 2026 at 10:07 AM, Takashi Iwai <[email protected]> wrote: > > > On Thu, 28 May 2026 15:38:54 +0200, > > Mike Karcic wrote: > > > > > > I did test 46c862f5419e on 6.12.90. Chirp still present. > > > > > > I'm also on a ThinkPad X1 Carbon Gen 12 with ALC287 (17aa:231e), > > > same as the original reporter. The fix resolved it for them but > > > not for me. > > > > > > Only a full revert of 630fbc6e870e resolves the issue. > > > > > > Verification on the running kernel: > > > > > > $ grep -c "dis_coefs" sound/pci/hda/patch_realtek.c > > > 2 > > > > > > $ grep -c "en_coefs" sound/pci/hda/patch_realtek.c > > > 0 > > > > > > $ sed -n '/alc287_alc1318_playback_pcm_hook/,/^}/p' sound/pci/hda/patch_realtek.c > > > static void alc287_alc1318_playback_pcm_hook(struct hda_pcm_stream *hinfo, > > > struct hda_codec *codec, > > > struct snd_pcm_substream *substream, > > > int action) > > > { > > > switch (action) { > > > case HDA_GEN_PCM_ACT_OPEN: > > > alc_write_coefex_idx(codec, 0x5a, 0x00, 0x954f); > > > break; > > > case HDA_GEN_PCM_ACT_CLOSE: > > > alc_write_coefex_idx(codec, 0x5a, 0x00, 0x554f); > > > break; > > > } > > > } > > > > > > Happy to test further patches. > > > > Just to be sure, could you verify that you've tested really the > > patched kernel, e.g. by adding a debug print, etc? > > If yes and the problem is seen even with the patch, try to comment out > > alc_process_coef_fw(codec, dis_coefs); > > and confirm that this fixes the problem. > > > > > > Takashi > >