You are not logged in.
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
Last edited by soulsuke (2024-02-01 16:09:18)
Offline
i915.modeset=0 is basically the same as disabling it for most intents and purposes. remove that.
Online
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?
Offline
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)
Online
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
Offline
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)
Online
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.
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!
Offline