[bug_report] ALSA: snd_hda_intel probe failed with error -16

Steven Skeard stevenskeard at gmail.com
Wed Apr 21 21:59:00 CEST 2021


Hi all,

I tried to get some help with this before but I don't think I
articulated the problem very well and it seemed to fall between the
cracks, so here I am to try again
(https://mailman.alsa-project.org/pipermail/alsa-devel/2021-February/181262.html).

With the default ALSA configuration in /etc/modprobe.d/alsa-base.conf,
I experience a consistent race condition where if snd-usb-audio loads
before snd-hda-intel, then the snd-hda-intel driver will fail to load
with the -16 error as seen in the dmsg output at the end of this alsa
info dump (http://alsa-project.org/db/?f=a23ccbb818fec6eaf08b032504eac5d5d8a30589).
When this error occurs, I get a single dummy output and no working
audio. In this state the only way to get working audio is to reboot my
computer and hope things load in the correct order.

After much digging I found a couple links on the arch forums where
people experienced similar problems
(https://bbs.archlinux.org/viewtopic.php?id=264091,
https://bbs.archlinux.org/viewtopic.php?id=260373). After reading both
of those and looking at my dmsg outputs, I tested the following
modifications to my modprobe configuration:
    1. Remove the default line for the usb driver: "options
snd-usb-audio index=-2"
    2. Add a line to specify that the intel driver should be loaded
first: "options snd-hda-intel index=0"
    3. Add a line to specify that the realtek codec driver should be
loaded second: "options snd-hda-codec-realtek index=1"
    4. Add a line to specify that the usb driver should be loaded
third: "options snd-usb-audio index=2"
And this works, and not only works but works every reboot! I have
uploaded an additional alsa info with the work around applied
(http://alsa-project.org/db/?f=f2d90b82434ba89b834a67eaefe10726d538e829)

So while at the end of the day I have a working audio configuration, I
can't help but feel like this is a bug. But the question I have is
whether this is a bug with ALSA, or with the kernel driver? And how do
I properly report this so it can be fixed?

Thanks,
Steven Skeard


More information about the Alsa-devel mailing list