Bug 436257

Libin,

Do you have a patch for this?

Libin, what exactly is the modprobe configuration issue?  I suspect this doesn't
need a kernel patch but a configuration issue for Red Hat to fix/enable support.

This is an issue of configuration. 

In the file /etc/modprobe.conf:

alias scsi_hostadapter ahci
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0
remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-hda-intel
alias eth0 tg3

It means snd-hda-intel kernel module will be loaded with the parameter index =
0. This causes 2 audio card(SB HDA & HDMI Audio) will use the same index. So
conflict occurs. 

Only one card will be initialized. When initializing the other card, the driver
will find index = 0 card has been loaded. And the driver will fail to initialize
the second card.

What should do is just remove the following 2 lines in the modprobe.conf file:
options snd-card-0 index=0
options snd-hda-intel index=0

I have done a test after removing the upper 2 lines. SB HDA and HDMI Audio both
can be initialized well.

Russ, this is not a kernel specific issue.  Can you raise this with the right
group that makes user level modprobe changes?   And assign it to them?
Thanks,
Bhavana

Changing component so this bug gets looked at.

Created attachment 297971 [details]
this version was tested at AMD

Bill, you voiced some concerns regarding this on IRC, but unfortunately I lost 
of internet connection and can't get back on.  Please discuss them here so 
Libin can take part in the discussion as well.

Basically, other than it being a file used by modprobe, modprobe.conf has
nothing to do with module-init-tools.

Those aliases are written by kudzu, in order to ensure some semblance of
consistent ordering of sound devices.

If we leave them in, as you note, machines where the same driver serves multiple
ALSA devices will have issues.

If we remove the writing of them, any machine will multiple audio devices (pci
and usb, or pci and pci) will have their sound interfaces potentially in random
order on each boot.

Any recommendations for AMD on how to resolve this?

Not immediately.

Based on Bill's description, can we suppose that kudzu will give a correct
configuration file? If so, I think we need not do anything on this issue.

I'm not familiar with how modprobe works. Do you think we just remove the
following 2 lines:
options snd-card-0 index=0
options snd-hda-intel index=0
while keeping "alias snd-card-0 snd-hda-intel"

Can this fix this issue?
"If we remove the writing of them, any machine will multiple audio devices (pci
and usb, or pci and pci) will have their sound interfaces potentially in random
order on each boot."

The alias doesn't help you, as sound modules aren't loaded that way in RHEL 5.

Can I assume that the following two items 
"options snd-card-0 index=0
options snd-hda-intel index=0"
do the same work because of "alias snd-card-0 snd-hda-intel" in this case?

So only one item is needed?

I suppose we use the item "options snd-hda-intel index=0"

Actually the item "options snd-hda-intel index=0" only has effect on
snd-hda-intel probe the HDA cards. It will not impact on which card will be
loaded first, which card will be loaded next. 

If "index=0" is assigned, only one HDA card will be initialized. The other HDA
cards will not be initialized correctly. 

I have tested on the RHEL5.2 Snapshot1 for this issue. The issues still exists.

Does anyone have good solution for this issue? If this issue exists, every
platform that has 2 HDA controller cards will fail to make the second HDA work.

(In reply to comment #13)
> Can I assume that the following two items 
> "options snd-card-0 index=0
> options snd-hda-intel index=0"
> do the same work because of "alias snd-card-0 snd-hda-intel" in this case?

Yes, but changing that won't help you, as you state below.

There is a tool named "alsaconf" in alsa-util package from alsa official
website, which is used to help generate the config file for audio.

I installed it and used this tool to generate configuation file for sound on
SB700. It generated a configuration file "sound" in /etc/modprobe.d/, the
contents are:
alias snd-card-0 snd-hda-intel
alias sound-slot-0 snd-hda-intel

It works well.

So if it is hard to change the configuration file. Is it possible to include the
tool "alsaconf" in alsa-utils package for Red Hat? And user can decide whether
to use the tool to generate the configuration file "sound".

Those lines are *useless* - they're completely ignored when udev loads the
modules. Having alsaconf write those is the equivalent of doing nothing at all.

In this case, you will get all cards initialized, but in essentially random order.

Hi Bill,

I tried the "sound" file today. firstly, I removed the lines:
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0
in /etc/modprobe.conf

And then I used alsaconf to generate the "sound" file

Then I tried to load the hda and usb audio drivers in random order. HDA card
will always be the first card. 

Bill, could you please have a try and see whether this mean there is no "random"
issue? Thanks.

"I tried to load the hda and usb audio drivers in random order" means that I
rmmod the audio driver. And there was no any sound driver in kernel. 

Then I plugged USB audio card. The USB audio card driver will be loaded
automatically. Then I "cat /proc/asound/cards" and found HDA card was in the
first place. The default card was HDA card when I tried to play sound.

That works almost entirely by accident, due to some peculiarities of the ALSA
subsystem.

What happens is that when the first sound device is loaded, one of its
dependencies is the snd-pcm module. For reasons I've yet to fathom, when this
module is loaded, ALSA generates a kmod request for snd-card-0. So, essentially,
while you're loading (via hotplug, udev, whatever) one module, a request will be
generated that will load whatever is aliased to snd-card-0. And they'll race,
and oftentimes (as you see) the intended behavior will happen.

However, that doesn't guarantee you anything. Imagine a box with the following
configuration generated in the manner you suggest:

alias snd-card-0 snd-hda-intel
alias snd-card-1 snd-rme9652 (to pick a random add-in card)

You hotplug a USB device before any other modules are loaded. Due to the kmod
request generated as described above, you're likely to get snd-hda-intel as card
0. But you'll still get the USB device as card 1.

Hi Bill,

I agree with you if we use the configuration like:
alias snd-card-0 snd-hda-intel
alias snd-card-1 snd-rme9652 (to pick a random add-in card)


I missed another parameter: cards_limit
We can use: 

options snd cards_limit=n

to determine how many audio cards will be automatically detected. You can find
more information about it in the file ALSA-Configuration.txt.

This parameter is set 1 by default and then only one card is autodetected.

That's still unreliable, as on new device add, they will be hotplugged before
you'd actually get a chance to write the configuration.

Yes, no configuration will be updated when a new device is added. But the old
configuration file can not solve this issue either. 

I suggest changing the configuration file aims to fix this issue: If there are
two sound cards using the same driver, for example snd-usb-audio.ko, the second
sound card will be initialized falsely and can not be used.

As to the hotplug issue, I think we can find another solution to fix it. For
example we can use a daemon like "hald" to detect such event and call a tool to
modify the configuration file. 

Actually, I believe there must be reasons that ALSA set cards_limit=1 to let
only one sound card be autoloaded. What I understand is that the first sound
card is very important because it is the default sound card and most
applications will use the default sound card to play if there is no parameters
to appoint the card. And other sound cards' order is not so important. Anyway,
if you want to appoint the cards' order clearly, OK, here is "cards_limit".

(In reply to comment #23)
> As to the hotplug issue, I think we can find another solution to fix it. For
> example we can use a daemon like "hald" to detect such event and call a tool to
> modify the configuration file. 

booting is just another case of hotplug, and you won't catch those
events, or modify the config file then.

There is a file "/etc/init.d/alsasound". It will be invoked when booting if the
runlevel supports sound function. I think many things can be done in this file.
Or just create another similar file to do it.

There is indeed some difference whether or not to use the "index" option. But if
there is no specific requirement, the "index" param is not necessary. And if the
"index" is used, then the risk in my former comments must be considered.

(In reply to comment #25)
> There is a file "/etc/init.d/alsasound". It will be invoked when booting if the
> runlevel supports sound function. I think many things can be done in this file.
> Or just create another similar file to do it.

Having an initscript to do sound things is silly:

- it leads to a case where the admin can easily break it by disabling the init
script
- there is a delay between when the module is loaded and things are actually set
working
- there's no way to hook into hotplug events

It should just be done via udev. That's why we've never shipped such a script.