This is a strange one and maybe is not directly a modprobe problem.

I have etc/modprobe.d/snd-hda.conf containing the line
options snd_hda_intel id=[HDMI,PCH] index=1,0

It has been working on testing for many years correcting the default
sound output from HDMI to PCH (which is connected to speakers etc.

But in a very recent testing update (I haven't been able to identify
which), the kernel no longer sees this parameter setting which it had
been doing properly for years.

Yet manually correcting with

# modprobe -r snd_hda_intel
# modprobe snd_hda_intel


which seems to let modprobe itself off the hook. Yet I thought that
modprobe was invoked by the kernel when loading modules so I am very
confused. Maybe this is related to udev? I see in my /var/log/dpkg
triggers-pending udev:amd64 256.5-1 about the time this problem
showed up.

Unpack your initramfs and check:
- if snd_hda_intel is there (so it is probably loaded in early boot)
- if so, if the module parameter configuration is there too

# cat /boot/initrd.img-6.10.6-amd64 | cpio -t
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/.enuineIntel.align.0123456789abc
kernel/x86/microcode/GenuineIntel.bin
48 blocks

so only microcode. I would not expect sound support there. Have I missed
something?

I see it dated as
-rw-r--r-- 1 root root 8.1M Aug 31 10:32 initrd.img-6.10.6-amd64
and I think that sound was working properly after that.

These are multiple concatenated archives. Use lsinitramfs.

Ah. I had missed that. A quick look is showing
etc/modprobe.d/snd-hda.conf
so you are probably right.

I will extract it and check...

ael

I have now used unmkinitramfs to extract the contents and the correct
modprobe.d/snd-hda.conf is there:
$ /tmp/image/main/etc/modprobe.d$ less snd-hda.conf
ptions snd_hda_intel id=[HDMI,PCH] index=1,0
# Don't need to specify id above, [HDMI,PCH] is the default
#See /usr/local/src/linux-stable/Documentation/sound/alsa-configuration.rst
#and /usr/local/src/linux-stable/Documentation/sound/hd-audio.rst
# modinfo snd_hda_intel, of course...
# also /sys/module/snd_hda_intel/ etc.


Actually, I did wonder whether it should be called
snd_hda_intel.conf ? Why did I ever call it snd_hda.conf

I better read the modprobe man page again.

Ok,I think that I have now checked the contents of /boot/initrd.img-6.10.6-amd64
and conformed that it has a correct
  etc/modprobe.d/snd-hda.conf
entry.

And I know that modprobe operates correctly manually on snd-hda.conf.

So I can't see how that initramfs can be a problem, although it is the
obvious candidate since it sets up the kernel initially.

It was last built on Aug 31 probably as triggered by a dpkg upgrade.
It could be that I didn't notice that sound was astray until a day or so
later. So I guess there has to be something astray there, but what?

Or could there be another explanation? Puzzled.

This suspiciously looks like
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663436 .

Indeed. Very odd. I read the alsa list and the authors from Intel often
post there. I am tempted to send a note to one of them to ask if they
have any ideas. But I don't want to make a fool of myself if there is a
trivial explanation somehow...

Thanks for the suggestion. No I hadn't checked there, and the results
are peculiar: it is looking like an obscure bug in the snd_hda_intel
driver.

The parameter that matters is "index".
Checking
/sys/module/snd_hda_intel/parameters/index
gives 1,0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
which is "correct" as if the options have been correctly set.
BUT sound is still connected to the HDMI port (index 0,1) !!

As usual, manually removing and restoring snd_hda_intel fixes the
problem: sound is then connected to PCH (index 1,0):
# modprobe -r snd_hda_intel
# modprobe  snd_hda_intel

/sys/module/snd_hda_intel/parameters/index
does not change, but is now reflecting the truth.

This is now a debian bug against modprobe, although it is probably not
modprobe at fault: 1080459@bugs.debian.org
As noted there, bug=663436 many years ago had something similar going on
with snd_hda_intel.

I will copy this reply to that the current bug because it adds
significant information. I am wondering whether to contact the
maintainer for snd_hda_intel, but I wnatto be sure that I am not
overlooking something silly.
Yes, I know about the kernel command line possibility, but I already have
a workaround. Rather I wnat to nail this bug. But thanks for the
suggestion.

ael

Yes, I did try to find anything relevant using journalctl. There were no
hits for snd_hda_intel with journalctl -b .

In 1080459@bugs.debian.org you will see that that it appears that the
options are included properly in the initrd.image which is where the
initial kernel is set up, I think before invoking PID 1 = systemd .

Somehow those options are not being set properly by snd_hda_intel. Or so
it seems. Very odd since it has only just started happening, very likely
when the a new initrd.image was generated by an unrelated dpkg trigger
was fired.  No, I have not (yet) tried to rebuild the initrd.image. I
should try that when I have more time.

I will copy this to the bug report in case it is useful.

ael

I have just checked journalctl -b and today I have an entry:

systemd-modules-load[352]: Failed to find module 'options snd_hda_intel id=[HDMI,PCH] index=1,0'

So as usual maybe this is systemd fault somehow? I find systemd
documentation impenetrable, but I suppose that I will have to try and
find out what is happening. Obviously it is somehow taking an parameter
option as the name of a module.

Earlier in my attempts to resolve this problem, I have placed a
copy of snd-hda.conf under
/etc/modules-load.d/

Systemd only expects such files to contain the names of modules, not
options, so the error that I have just reported in
journalctl is to be expected, and is thus spurious.

I have now, of course, deleted
sdn-hda.conf
from /etc/modules-load.d/

But why in the world doesn't systemd handle options there?
But then why in the world do we have systemd?

Trawling through journalctl for any clues, I see the following
when sound was working properly, ie. the parameters were being loaded
properly and sound delivered to the PCH port:

------------------------------------------------------------
kernel: snd_hda_intel 0000:00:1b.0: Unstable LPIB (131072 >= 8192); disabling LPIB delay counting

kernel: snd_hda_intel 0000:00:1b.0: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.

------------------------------------------------------------

Since bdl-pos-adj is itself a parameter, adjusting it would presumably
hit the same problem...

As I say, above were reported when all was well, but maybe could hint at
what is now going wrong.

I have some more data points:-

1) I regenerated initrd.img-6.10.6-amd64 using
    # update-initramfs -uv
   and rebooted. The problem remains.

2) I reverted to kernel 6.10.4-amd64 ( with its
  rw-r--r-- 1 root root  14M Aug 24 12:14 initrd.img-6.10.4-amd64)
  and all was well.


Comment: I have only just noticed the large difference in the size of
initrd.img-6.10.4-amd64   (14M)
and of
initrd.img-6.10.6-amd64   (8.1M)

I assume, but have not checked, that they use the same compression,
if any.

Maybe this is a kernel regression of some sort after all?
Does this bug need to be re-assigned?

Maybe there is some kernal debug parameter that might help with
diagnosis?

Try rebuilding this initrd (update-initramfs -u -k 6.10.6-amd64).

That was an excellent suggestion! I compared
initrd.img-6.10.6-amd64		(failing, size 8.1M)
with
initrd.img-6.10.4-amd64		(working, size 14M)

and it looks as if 6.10.4 contains relevant firmware:
usr/lib/firmware/i915.*
whereas the 6.10.6 has no such entries.

In fact 6.10.4 also has
usr/lib/modules/6.10.4-amd64/kernel/drivers/gpu/drm/i915/i915.ko
but there is no such entry in initrd.img-6.10.6-amd64

This looks very significant! But why are the entries missing? Is the
problem in update-initramfs maybe ??

Following my last message comparing the contents of
initrd.img-6.10.6-amd64 (failing) with those of initrd.img-6.10.4-amd64
(working) in which I found firmware in 6.10.4 which was not in 6.10.6,
I have now looked more carefully, and I can see nothing relevant to
sound in there.

In passing, here is part of the output of
lspci -k :

00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
        Subsystem: CLEVO/KAPOK Computer Device 5455
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel

which shows the details of the hardware being controlled by
snd-hda_intel. Not sure that any of this helps track down what is wrong.

The kernel (here on testing) was updated today to 6.10.9-amd64
with
# ls -l /boot/initrd.img-6.10.9-amd64
-rw-r--r-- 1 root root 8448795 Sep 14 13:36 /boot/initrd.img-6.10.9-amd64

The snd_hda_intel options are still broken requiring
# modprobe -r snd_hda_intel
# modprobe snd_hda_intel

to correct the situation.

Just to record that adding
  snd_hda_intel
to /etc/initramfs-tools/modules
did not help. This is not surprising since snd_hda_intel is already
being loaded, but without the parameter options being correctly obeyed.

Just in case this is useful I recorded the changes in /proc/modules
after the usual "correction"
# modprobe -r snd_hda_intel
# modprobe snd_hda_intel

I just used
cat /proc/modules |grep snd_hda_intel > ~/after.txt
before and after the above commands
and then
diff before.txt after.txt >compare.diff
Since compare.diff is short, here it is:

==================================================
1c1
< snd_hda_intel 61440 0 - Live 0xffffffffc08c8000
---
3,6c3,6
< snd_hda_codec 212992 2 snd_hda_codec_hdmi,snd_hda_intel, Live 0xffffffffc0863000
< snd_hda_core 143360 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec, Live 0xffffffffc075a000
< snd_pcm 188416 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core, Live 0xffffffffc0717000
< snd 147456 6 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer, Live 0xffffffffc060c000
---

=====================================

I have yet to understand the trailing hex value on the first line. I
suppose that if it is just an address, the change from 8 to c may not be
significant, but otherwise perhaps it is important.

One more data point:

On a failure, dmesg shows:

0.741723] snd_hda_intel 0000:00:1b.0: Cannot probe codecs, giving up (on a
fail)

But on an older working kernel, there is no such message, but dmesg
includes:-

==========================================================
    5.155954] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[    5.159403] cryptd: max_cpu_qlen set to 1000
[    5.172208] sr 0:0:0:0: Attached scsi CD-ROM sr0
[    5.178871] input: HDA Intel HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/sound/card1/input15
[    5.179641] input: HDA Intel HDMI HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:03.0/sound/card1/input16
[    5.181417] input: HDA Intel HDMI HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:03.0/sound/car
 ( kernel 6.10.3-amd64)
====================================================