I reverted the kernel source in the directory sys/dev/sound/pci/hda to r342378:

$ cd /usr/src/sys/dev/sound/pci
$ svn info hda
Path: hda
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/head/sys/dev/sound/pci/hda
Relative URL: ^/head/sys/dev/sound/pci/hda
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 342378
Node Kind: directory
Schedule: normal
Last Changed Author: mav
Last Changed Rev: 340071
Last Changed Date: 2018-11-02 18:02:10 +0100 (Fri, 02 Nov 2018)

compiled and installed the kernel:

$ uname -a
FreeBSD c720-r368166 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r342378:368166M: Fri Dec 11 07:46:32 CET 2020     guru@c720-r368166:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

and all is fine again as it was before. Someone with more knowledge should
have a look into a 'svn diff -r342378:368166 sys/dev/sound/pci/hda' and
see which of the changes might break the things.

The issue was reproduced by others on the same hardware Acer C720, see freebsd-current@

I have nailed down the problem and locally fixed it with this:

# svn diff sys/dev/sound/pci/hda/hdaa.c
Index: sys/dev/sound/pci/hda/hdaa.c
===================================================================
--- sys/dev/sound/pci/hda/hdaa.c	(revisión: 368166)
+++ sys/dev/sound/pci/hda/hdaa.c	(copia de trabajo)
@@ -6598,6 +6598,7 @@
 	devinfo->newgpo = -1;
 	callout_init(&devinfo->poll_jack, 1);
 	devinfo->poll_ival = hz;
+	devinfo->init_clear = 1;    /* added by guru@unixarea.de */

 	hdaa_lock(devinfo);
 	res = hda_command(dev,

because there seems to be no code to set devinfo->init_clear from
the device.hints(5) file;

I added a few debug statements in hdaa.c and here is what gets logged (without the above change of setting devinfo->init_clear = 1) to messages:

Dec 16 08:21:33 c720-r368166 kernel: hdaa0: DEBUG hdaa.c: hdaa_audio_prepare_pin_ctrl() has  devinfo->init_clear as: 0
Dec 16 08:21:33 c720-r368166 kernel: hdaa0: DEBUG hdaa.c: hdaa_attach() calls SYSCTL_ADD_INT() macro for init_clear
Dec 16 08:21:33 c720-r368166 kernel: hdaa1: DEBUG hdaa.c: hdaa_audio_prepare_pin_ctrl() has  devinfo->init_clear as: 0
Dec 16 08:21:33 c720-r368166 kernel: hdaa1: DEBUG hdaa.c: hdaa_attach() calls SYSCTL_ADD_INT() macro for init_clear

I am no expert on the code, but I did test sbruno's patch from D17772 and verified that it helped my case.  And I recall that he (at least) tried to make the clearing optional.

The code contains(e.g):

hdaa.c-6673-        dev, 0, hdaa_sysctl_reconfig, "I", "Reprocess configuration");
hdaa.c-6674-    SYSCTL_ADD_INT(device_get_sysctl_ctx(dev),
hdaa.c-6675-        SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO,
hdaa.c:6676:        "init_clear", CTLFLAG_RW,
hdaa.c:6677:        &devinfo->init_clear, 1,"Clear initial pin widget configuration");
hdaa.c-6678-    bus_generic_attach(dev);
hdaa.c-6679-    return (0);
hdaa.c-6680-}


And checking, I find:
g1-48(12.2-S)[2] sysctl dev.hdaa.{0,1}.init_clear
dev.hdaa.0.init_clear: 0
dev.hdaa.1.init_clear: 0


So: What happens if you set the appropriate dev.hdaa.%d.init_clear to 1?

What happens is that the values have no effect:

[guru@c720-r368166 ~]$ grep init_clear /boot/device.hints
dev.hdaa.0.init_clear=1
dev.hdaa.1.init_clear=1
[guru@c720-r368166 ~]$ sysctl dev.hdaa.0.init_clear
dev.hdaa.0.init_clear: 0
[guru@c720-r368166 ~]$ sysctl dev.hdaa.1.init_clear
dev.hdaa.1.init_clear: 0

and if you look also in my DEBUG messages above, the code in hdacc.c in the test

...
                device_printf(devinfo->dev,
                "DEBUG hdaa.c: hdaa_audio_prepare_pin_ctrl() has  devinfo->init_clear as: %d\n",
                        devinfo->init_clear);
                /* Disable everything. */
                if (devinfo->init_clear) {
                        device_printf(devinfo->dev,
                        "DEBUG hdaa.c: hdaa_audio_prepare_pin_ctrl() disables everything\n");
                        w->wclass.pin.ctrl &= ~(
                        HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
...
does not have any value !=0 in devinfo->init_clear;

Comment 7 Sean Bruno 2020-12-17 01:52:26 UTC

(In reply to Matthias Apitz from comment #6)
Hrm ... I have my settings in /etc/sysctl.conf 

I wonder if I've totally confused myself where these should be.  I didn't call them "hints" so /boot/device.hints is not correct.

Ugh ... the man page clearly states these are device.hints changes.  Can you verify that moving them to /etc/sysctl.conf works for you?

(In reply to Sean Bruno from comment #7)
moving the seetings to /etc/sysctl.conf sets them now correctly:

[root@c720-r368166 /home/guru]# grep dev.hdaa. /etc/sysctl.conf
dev.hdaa.0.init_clear=1
dev.hdaa.1.init_clear=1
[root@c720-r368166 /home/guru]# sysctl dev.hdaa.0.init_clear
dev.hdaa.0.init_clear: 1
[root@c720-r368166 /home/guru]# sysctl dev.hdaa.1.init_clear
dev.hdaa.1.init_clear: 1

but this has nothing todo with the clearing of the BIOS values, which is done (or not done) during the attach phase when the kernel boots up; as you see the value devinfo->init_clear in hdaa.c is checked *before* the root gets mounted (and /etc/sysctl.conf could have any affect):

# egrep 'DEBUG|Root mount' /var/log/messages
Dec 17 06:35:31 c720-r368166 kernel: hdaa0: DEBUG hdaa.c: hdaa_audio_prepare_pin_ctrl() has  devinfo->init_clear as: 0
Dec 17 06:35:31 c720-r368166 kernel: hdaa0: DEBUG hdaa.c: hdaa_attach() calls SYSCTL_ADD_INT() macro for init_clear
Dec 17 06:35:31 c720-r368166 kernel: hdaa1: DEBUG hdaa.c: hdaa_audio_prepare_pin_ctrl() has  devinfo->init_clear as: 0
Dec 17 06:35:31 c720-r368166 kernel: hdaa1: DEBUG hdaa.c: hdaa_attach() calls SYSCTL_ADD_INT() macro for init_clear
Dec 17 06:35:31 c720-r368166 kernel: Root mount waiting for: usbus0 usbus1 CAM
Dec 17 06:35:31 c720-r368166 kernel: Root mount waiting for: usbus0 usbus1 CAM
Dec 17 06:35:31 c720-r368166 kernel: Root mount waiting for: CAM

this can not be configured from sysctl.conf;

Comment 9 Andriy Gapon 2020-12-17 09:41:34 UTC

Sean, and I think that that was what I asked about here: https://reviews.freebsd.org/D17772#553549
sysctl.conf:dev.hdaa.0.init_clear=0 "worked" for you, because it seems that init_clear is always a zero on boot anyway.
sysctl.conf:dev.hdaa.0.init_clear=1 wouldn't work for that reason.

Also, another comment of mine: https://reviews.freebsd.org/D17772#553550

here is a proposal to fix this issue with values in device.hints(5) as:

# grep init_clear /boot/device.hints 
hint.hdaa.0.init_clear=1
hint.hdaa.1.init_clear=1

# svn diff sys/dev/sound/pci/hda/hdaa.c
Index: sys/dev/sound/pci/hda/hdaa.c
===================================================================
--- sys/dev/sound/pci/hda/hdaa.c	(revisión: 368166)
+++ sys/dev/sound/pci/hda/hdaa.c	(copia de trabajo)
@@ -5031,6 +5031,11 @@
 
 		pincap = w->wclass.pin.cap;
 
+		/* default is "disable everything" */
+		devinfo->init_clear = 1;
+		resource_int_value(device_get_name(devinfo->dev),
+	    		device_get_unit(devinfo->dev), "init_clear",
+			&(devinfo->init_clear));
 		/* Disable everything. */
 		if (devinfo->init_clear) {
 			w->wclass.pin.ctrl &= ~(
@@ -6671,10 +6676,6 @@
 	    SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO,
 	    "reconfig", CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_NEEDGIANT,
 	    dev, 0, hdaa_sysctl_reconfig, "I", "Reprocess configuration");
-	SYSCTL_ADD_INT(device_get_sysctl_ctx(dev),
-	    SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO,
-	    "init_clear", CTLFLAG_RW,
-	    &devinfo->init_clear, 1,"Clear initial pin widget configuration");
 	bus_generic_attach(dev);
 	return (0);
 }

Comment 11 Andriy Gapon 2020-12-18 09:20:17 UTC

(In reply to Matthias Apitz from comment #10)
This looks good to me.

Created attachment 220693 [details]
patch against head to solve this PR (including man page snd_hda.4)

After my usual daily update on head (amd64) on my laptop (from r368756 to r368801), I applied the patch from attachment 220693 [details] (via "svn patch"), then rebuilt (world -- which was superfluous -- as well as kernel).

On reboot, everything seems fine; sound still plays as it did before.  I did not change anything in /etc/sysctl/conf or /boot/loader.conf or /boot/device.hints.

So: works for me.  This is on the Dell Precision M4800 that is described at https://wiki.freebsd.org/Laptops/Dell_Precision_M4800?highlight=%28\bCategoryLaptop\b%29

Reviewing a diff of the dmesg from verbose boots (before & after the change), I see a few different addresses for kernel modules and some slightly different timing numbers; I don't believe those are either "significant" or "issues."

In particular, the pcm0 & pcm1 lines merely appear to had other things interspersed at different points: filtering the non-pcm lines out is not showing any difference that I spot by eye; here it is, in case it's useful:

 pcm0: <NVIDIA (0x0041) (HDMI/DP 8ch)> at nid 5 on hdaa0
 pcm0: Playback:
 pcm0:      Stream cap: 0x00000005 AC3 PCM
 pcm0: Mixer "vol" -> "none": child=0x00000010
 pcm0: Mixer "pcm": parent="vol"
 pcm0: Soft PCM mixer ENABLED
 pcm0: Playback channel matrix is: unknown, assuming 7.1 (disconnected)
 pcm1: <NVIDIA (0x0041) (HDMI/DP 8ch)> at nid 7 on hdaa0
 pcm1: Playback:
 pcm1:      Stream cap: 0x00000005 AC3 PCM
-pcm1:         PCM cap: 0x000e07f0 16 20 24 bits, 32 44 48 88 96 176 192 KHz
-pcm1:             DAC: 9
-pcm1: 
-pcm1:     nid=7 [pin: Digital-out (Jack)]
-pcm1:       + <- nid=9 [audio output] [src: pcm]
-pcm1: 
-pcm1: Mixer "vol" -> "none": child=0x00000010
-pcm1: Mixer "pcm": parent="vol"
-pcm1: Soft PCM mixer ENABLED
+pcm1:         PCM cap: 0x000e07f0 16 20 24 bits, 32 44 48 88 96 176 192 KHz
+pcm1:             DAC:battery0: units = 0
-pcm1: Playback channel matrix is: unknown, assuming 7.1 (disconnected)
+pcm1: 
+pcm1:     nid=7 [pin: Digital-out (Jack)]
+pcm1:       + <- nid=9 [audio output] [src: pcm]
+pcm1: 
+pcm1: Mixer "vol" -> "none": child=0x00000010
+pcm1: Mixer "pcm": parent="vol"
+pcm1: Soft PCM mixer ENABLED
+pcm1: Playback channel matrix is: unknown, assuming 7.1 (disconnected)

Comment 14 Christos Margiolis 2024-10-16 13:34:11 UTC

I am willing to commit this patch. Can you please explain in a few lines why this works and what the underlying problem is?