Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1211446 > unrolled thread

Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization ael <witwall3@disroot.org> - 2024-09-04 13:40 +0200
    Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization Marco d'Itri <md@Linux.IT> - 2024-09-04 14:00 +0200
      Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization ael <witwall3@disroot.org> - 2024-09-04 14:50 +0200
        Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization Marco d'Itri <md@linux.it> - 2024-09-04 15:30 +0200
          Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization ael <witwall3@disroot.org> - 2024-09-04 21:30 +0200
          Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization ael <witwall3@disroot.org> - 2024-09-04 22:10 +0200
          Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization ael <witwall3@disroot.org> - 2024-09-04 22:20 +0200
            Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization Marco d'Itri <md@linux.it> - 2024-09-04 22:40 +0200
              Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization ael <witwall3@disroot.org> - 2024-09-04 22:50 +0200
    Bug#1080459: systemd after all? Failed to find module 'options snd_hda_intel... ael <witwall3@disroot.org> - 2024-09-09 12:20 +0200
    Bug#1080459: Correction: probably not systemd after all. ael <witwall3@disroot.org> - 2024-09-09 12:30 +0200
    Bug#1080459: Possible clues ael <witwall3@disroot.org> - 2024-09-09 12:50 +0200
    Bug#1080459: update initramfs did not help. REverting to 6.10.4-amd64 worked ael <witwall3@disroot.org> - 2024-09-11 18:10 +0200
      Bug#1080459: update initramfs did not help. REverting to 6.10.4-amd64 worked Marco d'Itri <md@Linux.IT> - 2024-09-11 18:20 +0200
    Bug#1080459: update initramfs did not help. REverting to 6.10.4-amd64 worked ael <witwall3@disroot.org> - 2024-09-11 21:10 +0200
    Bug#1080459: Comparing initramfs versions ael <witwall3@disroot.org> - 2024-09-12 22:30 +0200
    Bug#1080459: Problem remains with 6.10.9-amd64 ael <witwall3@disroot.org> - 2024-09-14 14:50 +0200
    Bug#1080459: Adding snd_hda_intel to /etc/initramfs-tools/modules did not help ael <witwall3@disroot.org> - 2024-09-22 18:10 +0200
    Bug#1080459: Changes to /proc/modules after reisnatllinh snd_hda_intel ael <witwall3@disroot.org> - 2024-09-24 14:00 +0200
    Bug#1080459: Cannot probe codecs... ael <witwall3@disroot.org> - 2024-09-25 15:40 +0200

#1211446 — Bug#1080459: kmod: Option parameters under /etc/modprobe.d are not obeyed on system initialization

Package: kmod
Version: 33+20240816-2
Severity: normal

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.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.10.6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kmod depends on:
ii  libc6       2.40-2
ii  libkmod2    33+20240816-2
ii  liblzma5    5.6.2-2
ii  libssl3t64  3.3.1-7
ii  libzstd1    1.5.6+dfsg-1

kmod recommends no packages.

kmod suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#1211447

[Multipart message — attachments visible in raw view] — view raw

On Sep 04, ael <witwall3@disroot.org> wrote:

> Yet manually correcting with
> 
> # modprobe -r snd_hda_intel
> # modprobe snd_hda_intel
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

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#1211457

On Wed, Sep 04, 2024 at 01:51:19PM +0200, Marco d'Itri wrote:
> On Sep 04, ael <witwall3@disroot.org> wrote:
> 
> > Yet manually correcting with
> > 
> > # modprobe -r snd_hda_intel
> > # modprobe snd_hda_intel
> 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

I had already checked that:
# 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. 

[toc] | [prev] | [next] | [standalone]

#1211459

[Multipart message — attachments visible in raw view] — view raw

On Sep 04, ael <witwall3@disroot.org> wrote:

> # cat /boot/initrd.img-6.10.6-amd64 | cpio -t
These are multiple concatenated archives. Use lsinitramfs.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#1211491

On Wed, Sep 04, 2024 at 02:47:03PM +0200, Marco d'Itri wrote:
> On Sep 04, ael <witwall3@disroot.org> wrote:
> 
> > # cat /boot/initrd.img-6.10.6-amd64 | cpio -t
> 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

[toc] | [prev] | [next] | [standalone]

#1211496

On Wed, Sep 04, 2024 at 02:47:03PM +0200, Marco d'Itri wrote:
> On Sep 04, ael <witwall3@disroot.org> wrote:
> 
> > # cat /boot/initrd.img-6.10.6-amd64 | cpio -t
> These are multiple concatenated archives. Use lsinitramfs.

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.

[toc] | [prev] | [next] | [standalone]

#1211498

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.

[toc] | [prev] | [next] | [standalone]

#1211502

[Multipart message — attachments visible in raw view] — view raw

On Sep 04, ael <witwall3@disroot.org> wrote:

> Or could there be another explanation? Puzzled.
This suspiciously looks like 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663436 .

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#1211503

On Wed, Sep 04, 2024 at 10:33:22PM +0200, Marco d'Itri wrote:
> On Sep 04, ael <witwall3@disroot.org> wrote:
> 
> > 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...

[toc] | [prev] | [next] | [standalone]

#1212016 — Bug#1080459: systemd after all? Failed to find module 'options snd_hda_intel...

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.

[toc] | [prev] | [next] | [standalone]

#1212017 — Bug#1080459: Correction: probably not systemd after all.

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?

[toc] | [prev] | [next] | [standalone]

#1212024 — Bug#1080459: Possible clues

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.

[toc] | [prev] | [next] | [standalone]

#1212405 — Bug#1080459: update initramfs did not help. REverting to 6.10.4-amd64 worked

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?

[toc] | [prev] | [next] | [standalone]

#1212407 — Bug#1080459: update initramfs did not help. REverting to 6.10.4-amd64 worked

[Multipart message — attachments visible in raw view] — view raw

On Sep 11, ael <witwall3@disroot.org> wrote:

> initrd.img-6.10.6-amd64   (8.1M)
Try rebuilding this initrd (update-initramfs -u -k 6.10.6-amd64).

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#1212431 — Bug#1080459: update initramfs did not help. REverting to 6.10.4-amd64 worked

On Wed, Sep 11, 2024 at 06:47:34PM +0200, Marco d'Itri wrote:
> On Sep 11, ael <witwall3@disroot.org> wrote:
> 
> > Yes, I did that and no change. I thought that I said I had done that
> > under 1).
> Then compare the content with lsinitramfs.

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 ??

[toc] | [prev] | [next] | [standalone]

#1212588 — Bug#1080459: Comparing initramfs versions

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.

[toc] | [prev] | [next] | [standalone]

#1212843 — Bug#1080459: Problem remains with 6.10.9-amd64

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.

[toc] | [prev] | [next] | [standalone]

#1213967 — Bug#1080459: Adding snd_hda_intel to /etc/initramfs-tools/modules did not help

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.

[toc] | [prev] | [next] | [standalone]

#1214109 — Bug#1080459: Changes to /proc/modules after reisnatllinh snd_hda_intel

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
---
> snd_hda_intel 61440 0 - Live 0xffffffffc08ca000
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
---
> snd_hda_codec 212992 4 snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_hdmi, Live 0xffffffffc0863000
> snd_hda_core 143360 5 snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_hdmi,snd_hda_codec, Live 0xffffffffc075a000
> snd_pcm 188416 4 snd_hda_intel,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_core, Live 0xffffffffc0717000
> snd 147456 8 snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_hdmi,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.

[toc] | [prev] | [next] | [standalone]

#1214231 — Bug#1080459: Cannot probe codecs...

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)
====================================================

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web