[SOLVED] Kernel 6.7: snd_hda_intel and i915 loaded but device is un...

soulsuke · 2024-02-01 10:02:22

Hello,

apparently the 6.7 line has some serious beef with certain intel audio cards and... Here's a new one!. I've tried to look up for similar scenarios here and there, but so far none helped. A few examples are:

To keep it short, all modules are loaded, no wrong driver is uesd for the device and it is in UNCLAIMED state.
Nothing is blacklisted in /etc/modprobe.d, the only file there is the one created by the vmware package (it literally only contains `alias char-major-10-229 fuse`).
The first thing I've tried was to try to manually bind it and here comes the surprise:

# print "0000:00:1f.3" >> /sys/bus/pci/drivers/snd_hda_intel/bind
print: write error: resource temporarily unavailable

I've tried to rmmod snd-hda-intel -f/modprobe snd-hda-intel, got no errors but nothing did change.
I've set systemd.log_level=debug and here's the output of journalctl -b.

I'll switch to lts for the time being, but any advice is welcome.

The kernel modules are all there and loaded:

# lsmod | grep snd
snd_seq_dummy          12288  0
snd_hrtimer            12288  1
snd_seq               131072  7 snd_seq_dummy
snd_seq_device         16384  1 snd_seq
snd_soc_avs           217088  0
snd_soc_hda_codec      28672  1 snd_soc_avs
snd_hda_ext_core       36864  2 snd_soc_avs,snd_soc_hda_codec
snd_soc_core          462848  2 snd_soc_avs,snd_soc_hda_codec
snd_compress           28672  2 snd_soc_avs,snd_soc_core
snd_hda_codec_hdmi     94208  1
ac97_bus               12288  1 snd_soc_core
snd_pcm_dmaengine      16384  1 snd_soc_core
snd_hda_intel          65536  1
snd_intel_dspcfg       40960  2 snd_soc_avs,snd_hda_intel
snd_intel_sdw_acpi     16384  1 snd_intel_dspcfg
snd_hda_codec         225280  4 snd_soc_avs,snd_hda_codec_hdmi,snd_soc_hda_codec,snd_hda_intel
snd_hda_core          151552  6 snd_soc_avs,snd_hda_codec_hdmi,snd_soc_hda_codec,snd_hda_intel,snd_hda_ext_core,snd_hda_codec
snd_hwdep              20480  1 snd_hda_codec
snd_pcm               204800  8 snd_soc_avs,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_compress,snd_soc_core,snd_hda_core,snd_pcm_dmaengine
snd_timer              53248  3 snd_seq,snd_hrtimer,snd_pcm
snd                   155648  14 snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_compress,snd_soc_core,snd_pcm
soundcore              16384  1 snd

# lsmod | grep i915  
i915                 4169728  0
drm_buddy              20480  1 i915
i2c_algo_bit           20480  1 i915
ttm                   110592  1 i915
drm_display_helper    229376  1 i915
cec                    86016  2 drm_display_helper,i915
intel_gtt              28672  1 i915
video                  77824  3 dell_wmi,i915,nvidia_modeset

But none is used for the device:

# lspci -vvv -nn -s 1f.3
00:1f.3 Audio device [0403]: Intel Corporation CM238 HD Audio Controller [8086:a171] (rev 31)
	Subsystem: Dell CM238 HD Audio Controller [1028:0774]
	Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at dd128000 (64-bit, non-prefetchable) [size=16K]
	Region 4: Memory at dd100000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Kernel modules: snd_hda_intel, snd_soc_avs

For comparison, here's what happens on 6.6.10-arch1-1.
I have to add, manually unbinding/binding the device give no error here, and everything works as expected.

# lsmod | grep snd
snd_seq_dummy          12288  0
snd_hrtimer            12288  1
snd_seq               131072  7 snd_seq_dummy
snd_seq_device         16384  1 snd_seq
snd_ctl_led            24576  0
snd_hda_codec_realtek   196608  1
snd_hda_codec_generic   114688  1 snd_hda_codec_realtek
snd_soc_avs           221184  0
snd_soc_hda_codec      28672  1 snd_soc_avs
snd_hda_ext_core       36864  2 snd_soc_avs,snd_soc_hda_codec
snd_soc_core          458752  2 snd_soc_avs,snd_soc_hda_codec
snd_compress           28672  2 snd_soc_avs,snd_soc_core
snd_hda_codec_hdmi     94208  1
ac97_bus               12288  1 snd_soc_core
snd_pcm_dmaengine      16384  1 snd_soc_core
snd_hda_intel          65536  2
ledtrig_audio          12288  3 snd_ctl_led,snd_hda_codec_generic,dell_wmi
snd_intel_dspcfg       40960  2 snd_soc_avs,snd_hda_intel
snd_intel_sdw_acpi     16384  1 snd_intel_dspcfg
snd_hda_codec         225280  6 snd_hda_codec_generic,snd_soc_avs,snd_hda_codec_hdmi,snd_soc_hda_codec,snd_hda_intel,snd_hda_codec_realtek
snd_hda_core          151552  8 snd_hda_codec_generic,snd_soc_avs,snd_hda_codec_hdmi,snd_soc_hda_codec,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_realtek
snd_hwdep              20480  1 snd_hda_codec
snd_pcm               204800  8 snd_soc_avs,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_compress,snd_soc_core,snd_hda_core,snd_pcm_dmaengine
snd_timer              53248  3 snd_seq,snd_hrtimer,snd_pcm
snd                   155648  19 snd_ctl_led,snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_compress,snd_soc_core,snd_pcm
soundcore              16384  2 snd_ctl_led,snd

# lsmod | grep i915
i915                 4136960  0
drm_buddy              20480  1 i915
i2c_algo_bit           20480  1 i915
ttm                   110592  1 i915
drm_display_helper    229376  1 i915
cec                    86016  2 drm_display_helper,i915
intel_gtt              28672  1 i915
video                  77824  3 dell_wmi,i915,nvidia_modeset

# lspci -vvv -nn -s 1f.3
00:1f.3 Audio device [0403]: Intel Corporation CM238 HD Audio Controller [8086:a171] (rev 31)
	Subsystem: Dell CM238 HD Audio Controller [1028:0774]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 32, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 161
	Region 0: Memory at dd128000 (64-bit, non-prefetchable) [size=16K]
	Region 4: Memory at dd100000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
	Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee00778  Data: 0000
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel, snd_soc_avs

journalctl -b

Last edited by soulsuke (2024-02-01 16:09:18)

V1del · 2024-02-01 14:19:50

i915.modeset=0 is basically the same as disabling it for most intents and purposes. remove that.

soulsuke · 2024-02-01 16:08:15

V1del wrote:

i915.modeset=0 is basically the same as disabling it for most intents and purposes. remove that.

That solved it!

I seriously appreciate the answer, but I want to understand what happened here... With previous kernels setting i915.modeset=0 was the only way not to mess up ttys (due to nvidia/intel shenanigans) without blacklisting i915, but sound was functional.. Although there was this odd message in the journal:

Feb 01 10:05:47 unmei kernel: snd_hda_intel 0000:00:1f.3: couldn't bind with audio component

And taking a look at it, the sound card was correctly initialized about 1 minute after the boot.

Now that message is gone and it gets initialized within the first ~15 seconds.

So... Was the audio actually not expected to work up until now with that kernel option?

V1del · 2024-02-01 16:15:53

I find it generally weird that apparently this strange hard dependency on i915 came about for internal sound cards that you're not even going to use the (intel) hdmi output for/with.

But to properly understand that we'd have to look at what changed in the kernel. I'd say that it used to work without that should be "more" correct than what's happening now.

... this reads interesting https://github.com/torvalds/linux/commi … 76b2058b30

Try restoring the i915.modeset=0 and add snd_hda_core.gpu_bind=0 but I wonder whether that would break nvidia HDA/HDMI binding. as mentioned in the commit message the correct way of killing i915 would be i915.force_probe=!* that should prevent the binding attempt in any case assuming I'm reading that right. -- But that would be effectively a blacklist do you have a reason for not wanting to do that or was that also a test because the blacklist would actually cause the audio issue?

Last edited by V1del (2024-02-01 16:50:18)

soulsuke · 2024-02-01 18:03:51

V1del wrote:

I find it generally weird that apparently this strange hard dependency on i915 came about for internal sound cards that you're not even going to use the (intel) hdmi output for/with.
But to properly understand that we'd have to look at what changed in the kernel. I'd say that it used to work without that should be "more" correct than what's happening now.
... this reads interesting https://github.com/torvalds/linux/commi … 76b2058b30

My thanks for pointing out that commit, I'd never have found it myself, and it definitely explains a few things.

If I read it correctly, it seems to actually make modeset 0 less nuclear, as before it would have always bound the sound card to the gpu, right?
Maybe it was made to allow that after this previous commit?

It'd make sense, but I admit it's been years since I last dabbled with C and I'm not that proficient with the kernel itself, so I could be waaaay off here

Try restoring the i915.modeset=0 and add snd_hda_core.gpu_bind=0 but I wonder whether that would break nvidia HDA/HDMI binding. as mentioned in the commit message the correct way of killing i915 would be i915.force_probe=!* that should prevent the binding attempt in any case assuming I'm reading that right.

Setting snd_hda_core.gpu_bind=0 solves the issue without any evident side effect (neither on HDMI or detected cards), and it works with both i915.modeset=0 and i915.force_probe=!*. I'll stick with the latter since it's the actual way to blacklist the module.

--But that would be effectively a blacklist do you have a reason for not wanting to do that or was that also a test because the blacklist would actually cause the audio issue?

I do want to blacklist the module, but I keep it as a kernel param mostly because even though this laptop doesn't play well with the integrated card I sometimes get the urge to check if anything has changed, and editing the kernel params at boot time is less error prone than editing a file and forgetting to change it back... Which happened enough times to bring shame to me, my family and my ancestors

V1del · 2024-02-01 19:38:34

soulsuke wrote:

If I read it correctly, it seems to actually make modeset 0 less nuclear, as before it would have always bound the sound card to the gpu, right?
Maybe it was made to allow that after this previous commit?

That's what I'm thinking as well. This reads like in order to facilitate a kernel/code based evaluation of whether i915 or xe should be loaded for any given GPU they basically broke modprobe based evaluation. Which also explains why people that used to just have the module blacklist suddenly started to have this issue, i915 is not loaded via modprobe anymore, so the module blacklist silently didn't do anything anymore and i915 (or rather this HDA portion of it) was "pseudo-loaded" regardless and tried to bind to the sound card. While this is technically not an userspace break, it breaks users(..space, sorry) expectations with how modprobe interacts with things so might be worth somewhat of a bug report, or well just use that param as a workaround.

I do want to blacklist the module, but I keep it as a kernel param mostly because even though this laptop doesn't play well with the integrated card I sometimes get the urge to check if anything has changed, and editing the kernel params at boot time is less error prone than editing a file and forgetting to change it back... Which happened enough times to bring shame to me, my family and my ancestors

While there's apparently this new method, blacklisting "properly"/"the modprobe way" via the cmdline has always been possible: https://wiki.archlinux.org/title/Kernel … and_line_2

Last edited by V1del (2024-02-01 19:39:15)

soulsuke · 2024-02-01 20:04:02

V1del wrote:

That's what I'm thinking as well. This reads like in order to facilitate a kernel/code based evaluation of whether i915 or xe should be loaded for any given GPU they basically broke modprobe based evaluation. Which also explains why people that used to just have the module blacklist suddenly started to have this issue, i915 is not loaded via modprobe anymore, so the module blacklist silently didn't do anything anymore and i915 (or rather this HDA portion of it) was "pseudo-loaded" regardless and tried to bind to the sound card. While this is technically not an userspace break, it breaks users(..space, sorry) expectations with how modprobe interacts with things so might be worth somewhat of a bug report, or well just use that param as a workaround.

Reported as in on https://bugzilla.kernel.org ? Never done so before, but it may be worth a shot since they did introduce a mechanism with a different default behaviour. I'll give it a shot tomorrow.

V1del wrote:

While there's apparently this new method, blacklisting "properly"/"the modprobe way" via the cmdline has always been possible: https://wiki.archlinux.org/title/Kernel … and_line_2

Oh, I didn't.know that! Duly noted, thanks!

Arch Linux

#1 2024-02-01 10:02:22

[SOLVED] Kernel 6.7: snd_hda_intel and i915 loaded but device is un...

#2 2024-02-01 14:19:50

Re: [SOLVED] Kernel 6.7: snd_hda_intel and i915 loaded but device is un...

#3 2024-02-01 16:08:15

Re: [SOLVED] Kernel 6.7: snd_hda_intel and i915 loaded but device is un...

#4 2024-02-01 16:15:53

Re: [SOLVED] Kernel 6.7: snd_hda_intel and i915 loaded but device is un...

#5 2024-02-01 18:03:51

Re: [SOLVED] Kernel 6.7: snd_hda_intel and i915 loaded but device is un...

#6 2024-02-01 19:38:34

Re: [SOLVED] Kernel 6.7: snd_hda_intel and i915 loaded but device is un...

#7 2024-02-01 20:04:02

Re: [SOLVED] Kernel 6.7: snd_hda_intel and i915 loaded but device is un...

Board footer