ThinkPad P14s Gen 5 AMD micmute LED is not working sometimes.

[pma1]

The mic and sound output works fine.
The mute LED works fine.
But when press Fn+F4, the mic-mute led is not working sometimes after bootup.
The failrate is like 1/10.

Tested with latest alsa-ucm from git, it's reproduced.
/sys/class/sound/ctl-led/mic/card1# cat list
7

amixer -c 1 controls

numid=12,iface=CARD,name='Headphone Jack'
numid=11,iface=CARD,name='Mic Jack'
numid=13,iface=CARD,name='Speaker Phantom Jack'
numid=10,iface=MIXER,name='Master Playback Switch'
numid=9,iface=MIXER,name='Master Playback Volume'
numid=2,iface=MIXER,name='Headphone Playback Switch'
numid=1,iface=MIXER,name='Headphone Playback Volume'
numid=16,iface=MIXER,name='PCM Playback Volume'
numid=17,iface=MIXER,name='Mic ACP LED Capture Switch'
numid=8,iface=MIXER,name='Mic Boost Volume'
numid=7,iface=MIXER,name='Capture Switch'
numid=6,iface=MIXER,name='Capture Volume'
numid=5,iface=MIXER,name='Auto-Mute Mode'
numid=4,iface=MIXER,name='Speaker Playback Switch'
numid=3,iface=MIXER,name='Speaker Playback Volume'
numid=15,iface=PCM,name='Capture Channel Map'
numid=14,iface=PCM,name='Playback Channel Map'

echo 'Capture Switch' > detach

echo 'Mic ACP LED Capture Switch' > attach

/sys/class/sound/ctl-led/mic/card1# cat list
17

Then the micmute LED will work.
alsa-info-amd-micmutled.txt

[perexg]

The ctl-led mic setting is set here: https://github.com/alsa-project/alsa-ucm-conf/blob/40d9c6c/ucm2/HDA/HDA.conf#L57-L58 . The alsactl utility should execute the Boot sequences on boot (udev / alsa-state service). I would check logs,if there's something suspicious when things are not working.

[pma1]

alsa-info-matterhorn-p-amd-3-6.5-1025-oem-ucm1.2.6.3.log

Uploaded the failure log of alsa-info with 6.5 kernel and UCM 1.2.6.3.

[mschiu77]

@perexg It seems that the BootSequence is not executed correctly in the fail case. What log would you suggest us to check? How do we make sure the detach/attach are really invoked in the HDA.conf?

[perexg]

It may be something with the card probe order. UCM tries to detect the ACP microphone here: https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/HDA/HDA.conf#L6 . But if ACP driver is loaded with a delay, the microphone is not detected, thus the FixedBootSequence is not executed.

To debug: You can add those lines at the end of the above file:

FixedBootSequence [
   exec "/usr/local/bin/run-my-script"
]

and create a bash script like (do not forget to make it executable):

#!/bin/bash

cat /proc/asound/cards > /tmp/alsa-cards-hda.txt

Reboot and check the contents of /tmp/alsa-cards-hda.txt , if there is ACP sound card.

[superm1]

I think you're on to something.

Is this the same bug as https://bugzilla.kernel.org/show_bug.cgi?id=219229?

[pma1]

t14g5-amd-micmuteled-fail-journal.log

@perexg no output from FixedBootSequence from the script.

I suspect it's the following error in log above:
Sep 10 09:39:40 u-ThinkPad-T14-Gen-5 wireplumber[2848]: SPA handle 'api.alsa.acp.device' could not be loaded; is it installed?
Sep 10 09:39:40 u-ThinkPad-T14-Gen-5 wireplumber[2848]: Failed to create 'api.alsa.acp.device' device

Note:
The log above is from v6.11-rc6 which will reproduce this issue every one time of boot because of bug:219229.
V6.9- kernel version can NOT reproduce bug:219229, but have a failrate 1/10 of micmute led issue.

[perexg]

The FixedBootSequence should be called using udev rule (invoking alsactl). Perhaps SELinux blocked this call (check audit log).

From log:

Sep 10 09:39:33 u-ThinkPad-T14-Gen-5 kernel: initcall snd_amd_acp_pci_driver_init+0x0/0xff0 [snd_acp_pci] returned 0 after 70 usecs
...
Sep 10 09:39:33 u-ThinkPad-T14-Gen-5 systemd[1]: Starting alsa-restore.service - Save/Restore Sound Card State..
...
Sep 10 09:39:35 u-ThinkPad-T14-Gen-5 kernel: probe of hdaudioC1D0 returned 0 after 42320 usecs

So the HDA driver is loaded after alsa-restore service. In this case, udev rule in /lib/udev/rules.d/90-alsa-restore.rules should handle this (your distro may have slightly different filename/config):

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/sbin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", RUN+="/usr/sbin/alsactl restore $devnode"
TEST=="/etc/alsa/state-daemon.conf", RUN+="/usr/sbin/alsactl nrestore $devnode"

LABEL="alsa_restore_end"

[pma1]

@perexg Ubuntu 24.04 do have this udev rule:

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/sbin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $attr{device/number}"
TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $attr{device/number}"

LABEL="alsa_restore_end"

Tested your udev rule too, no effects.

[perexg]

Check if you have SELinux in the permissive mode (if active) to test FixedBootSequence additions. Also alsactl have '-v' option which can be used multiple times to produce some debug log to see what's wrong. I can give only hints. This hardware is not in my hands.

[pma1]

@perexg selinux is disabled:
$ sudo sestatus
SELinux status: disabled

After adding '-v', it's still no useful log.
+++ /lib/udev/rules.d/90-alsa-restore.rules 2024-09-19 14:23:15.996178585 +0800
@@ -2,7 +2,7 @@
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"
-TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $attr{device/number}"
-TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $attr{device/number}"
+TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -v -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $attr{device/number}"
+TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -v -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $attr{device/number}"

LABEL="alsa_restore_end"

[pma1]

@superm1 and @perexg
Not sure if there are 2 issues here, another finding:
After the commit "eb24c9788cd9 (HEAD) tpm: disable the TPM if NULL name changes", sometimes 'Mic ACP LED Capture Switch' is not shown, sometimes it is shown, the micmute led will never be working.
If CONFIG_TCG_TPM2_HMAC=n, the micmute led is OK.
At first I thought it's because of timing, but after Jarkko fix the timing issue with patches: https://lore.kernel.org/linux-integrity/[email protected]/T/#t

The issue is still there.

[pma1]

amd-micmuteled-tpm2-hmac.tar.gz

Attach the log of both disabled and enabled TPM2_HMAC.

[superm1]

To me it sounds like a subtle race condition still. How about changing the conditions for /lib/systemd/system/alsa-restore.service to also wait for LED to be present?