[BUG] ALC236 (Lenovo IdeaPad S145-15IWL) codec becomes unresponsive after 7.2.4 update; probe_mask/single_cmd quirks make it worse, not better #1052

Summary

After the 2026-09-14 kernel package update (linux-cachyos 7.2.3-1 → 7.2.4-3, linux-cachyos-lts 6.18.48-1 → 6.18.50-3), the onboard Realtek ALC236 audio codec became unreliable and eventually failed to probe entirely. A cold reboot with no forced driver parameters resolved it. This report includes a pitfall we hit while troubleshooting that's worth flagging for others: probe_mask=1 made things measurably worse, not better.

Hardware

• Laptop: Lenovo IdeaPad S145-15IWL (DMI product_name: 81MV)
• CPU: Intel Core i5-8265U
• Audio controller: Intel Cannon Point-LP HDA (PCI 8086:9dc8, subsystem 17aa:3803)
• Codec: Realtek ALC236 (vendor 10ec0230, subsystem 17aa382c)

Timeline

1. 2026-09-14: linux-cachyos upgraded 7.2.3-1 → 7.2.4-3, linux-cachyos-lts upgraded 6.18.48-1 → 6.18.50-3 (both installed).
2. 2026-09-16, ~20:28: During normal use, kernel log showed the codec becoming unreliable at runtime:

   snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x008f0600
   snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x008f0600
   snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x008f0600
   

   Mixer/PipeWire state still looked "fine" (cached from before the fault), but no audio reached the speakers.
3. Troubleshooting mistake: we added /etc/modprobe.d/alsa-quirk.conf with options snd-hda-intel probe_mask=1 position_fix=1 single_cmd=1 and reloaded the module. This made it fail completely on every subsequent boot (regular kernel and LTS alike):

   snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000
   snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000
   snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it...
   snd_hda_intel 0000:00:1f.3: no codecs initialized
   

   Per the kernel HD-audio docs, probe_mask is a bitmask restricting which codec slots get probed (default -1 = probe all); forcing it to 1 combined with single_cmd=1 (explicitly documented as "for debugging only") appears to have made codec enumeration fail outright on this hardware rather than working around anything.
4. Fix: removed /etc/modprobe.d/alsa-quirk.conf entirely and did a full cold reboot (not just a module reload). The codec probed cleanly again on both installed kernels, full autoconfig succeeded, and all mixer controls (Speaker/Headphone/Master) came back:

   snd_hda_codec_alc269 hdaudioC0D0: ALC236: picked fixup  for PCI SSID 17aa:0000
   snd_hda_codec_alc269 hdaudioC0D0: autoconfig for ALC236: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
   

What we're less sure about

We don't have a clean isolated test of "reboot on 7.2.4 with zero forced parameters, before ever adding the quirk file" — by the time we tried a plain reboot, the harmful quirk file was already in place. So we can't say with certainty whether the original Sept 16 runtime degradation would have self-resolved with just a reboot, independent of the quirk-file misadventure. What we can say confidently: the quirk file made it strictly worse, and removing it + cold-booting restored full functionality on both kernels.

Ask

• Has anyone else on Cannon Point-LP + ALC236 (or similar Realtek codecs) hit azx_get_response timeout / codec becoming unresponsive at runtime after the 7.2.4 kernel update?
• Should linux-cachyos carry a documented warning against probe_mask/single_cmd as "quick fix" options for this class of symptom, given how easily they turn a partial/degraded fault into total codec failure? A related pattern (codec needs cold reboot to reinit) shows up in Conexant SN6140 HDA codec fails to re-init after s2idle resume (CORBRP=0xFFFF, "no codecs initialized"), needs cold reboot #950 for a different codec (Conexant SN6140), so this "needs cold reboot" theme may be worth a general troubleshooting note.

System

• Distro: CachyOS (Limine bootloader)
• uname -r at time of writing: 6.18.50-3-cachyos-lts (working)