Sound card module loading sequence (was: Re: [PATCH] fix udevtrigger first/default/last ordering)

Sound card module loading sequence (was: Re: [PATCH] fix udevtrigger first/default/last ordering)

[juuso.alasuutari]

Quoting Greg KH <greg@kroah.com>:

> On Thu, Apr 13, 2006 at 02:22:49AM +0300, juuso.alasuutari@tamperelainen.org
> wrote:
<snip>
> > I don't completely understand the issue that this patch deals with, but
> does it
> > have something to do with module loading order? This has been giving
> > considerable trouble for people (also previously discussed on this list),
> and
> > is still one major obstacle for udev to reliably replace hotplug. At least
> this
> > is the case for the distribution I assist in developing.
>
> It is?  What distro?

Source Mage. While we don't enforce udev and udev-based module autoloading upon
anyone, it would still be great to have it working completely.
Of course this is just a matter of finding the right rules and writing the right
scripts, which is what I'm set on doing.

> > Is there a chance that udev could in the future load modules (network,
> audio,
> > etc.) in the same order every time if no significant hardware changes take
> > place? If yes, when and thanks to what changes? If not, what prevents it?
>
> No, as the modules could be loaded in any order if the buses are probed
> a little bit differently next boot time.  Or if the BIOS reorders the
> bus numbers.  Or another PCI device is added to the system.  Or one
> removed.  Or any of a zillion different other things happening.

I do understand that devices being added/removed have this kind of effect, but
the cases I've experienced and seen have had no such reason. Is it the kernel
that's responsible for this, and are there plans to change that behavior? Is
this what I've heard being called a race condition?

> In short, any reliance on the order of modules being loaded, in order to
> name devices properly for a system is broken.  Use persistant names,
> that is what udev is for.  Look at /dev/disk/ for examples of how to do
> this with block devices today.  It works wonderfully thanks to Kay's
> work.
>
> thanks,
>
> greg k-h
>

I've so far ony taken a quick glance at the persistent storage rules, so I can't
say I'm much wiser yet. Maybe studying them in depth will indeed help me. But
before I start on that I wanted to ask if you (or others) have any ideas how to
create sound device numbering bindings. They seem much more confusing than e.g.
network devices. (I recently managed to handle network device naming problems,
so one worry less now.)

Juuso

----------------------------------------------------------------
This mail sent through L-secure: http://www.l-secure.net/



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Sound card module loading sequence (was: Re: [PATCH] fix udevtrigger first/default/last ordering

[Greg KH]

On Sun, Apr 16, 2006 at 02:48:49AM +0300, juuso.alasuutari@tamperelainen.org wrote:
> Quoting Greg KH <greg@kroah.com>:
> 
> > On Thu, Apr 13, 2006 at 02:22:49AM +0300, juuso.alasuutari@tamperelainen.org
> > wrote:
> <snip>
> > > I don't completely understand the issue that this patch deals with, but
> > does it
> > > have something to do with module loading order? This has been giving
> > > considerable trouble for people (also previously discussed on this list),
> > and
> > > is still one major obstacle for udev to reliably replace hotplug. At least
> > this
> > > is the case for the distribution I assist in developing.
> >
> > It is?  What distro?
> 
> Source Mage. While we don't enforce udev and udev-based module autoloading upon
> anyone, it would still be great to have it working completely.
> Of course this is just a matter of finding the right rules and writing the right
> scripts, which is what I'm set on doing.
> 
> > > Is there a chance that udev could in the future load modules (network,
> > audio,
> > > etc.) in the same order every time if no significant hardware changes take
> > > place? If yes, when and thanks to what changes? If not, what prevents it?
> >
> > No, as the modules could be loaded in any order if the buses are probed
> > a little bit differently next boot time.  Or if the BIOS reorders the
> > bus numbers.  Or another PCI device is added to the system.  Or one
> > removed.  Or any of a zillion different other things happening.
> 
> I do understand that devices being added/removed have this kind of effect, but
> the cases I've experienced and seen have had no such reason. Is it the kernel
> that's responsible for this, and are there plans to change that behavior? Is
> this what I've heard being called a race condition?

No, it's not a race condition.  It all comes down to how the busses are
enumerated by the kernel.  For PCI, it usually always is enumerated in
the same order, so things are always numbered the same.  But, if you
upgrade your BIOS, or plug a new device into the PCI bus, things can get
renumbered the next time you boot.  Also, PCI hotplug devices need to be
taken into account here.  So you can not rely on the PCI devices always
being discovered in the same order.

Same thing for USB.  Some usb devices can take longer to initialize than
others, and cause them to show up in different order at boot time than
the last time.  So again, you can not rely on the enumeration to always
happen in the same order.

> > In short, any reliance on the order of modules being loaded, in order to
> > name devices properly for a system is broken.  Use persistant names,
> > that is what udev is for.  Look at /dev/disk/ for examples of how to do
> > this with block devices today.  It works wonderfully thanks to Kay's
> > work.
>
> I've so far ony taken a quick glance at the persistent storage rules, so I can't
> say I'm much wiser yet. Maybe studying them in depth will indeed help me. But
> before I start on that I wanted to ask if you (or others) have any ideas how to
> create sound device numbering bindings. They seem much more confusing than e.g.
> network devices. (I recently managed to handle network device naming problems,
> so one worry less now.)

Name the sound devices based on the pci id.  Or the path.  Or something
else you think might be unique (vendor/product id?, etc.)

good luck,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Sound card module loading sequence (was: Re: [PATCH] fix udevtrigger first/default/last ordering

[Darren Salt]

I demand that Greg KH may or may not have written...

[snip]
>> I've so far ony taken a quick glance at the persistent storage rules, so I
>> can't say I'm much wiser yet. Maybe studying them in depth will indeed
>> help me. But before I start on that I wanted to ask if you (or others)
>> have any ideas how to create sound device numbering bindings. They seem
>> much more confusing than e.g. network devices. (I recently managed to
>> handle network device naming problems, so one worry less now.)

> Name the sound devices based on the pci id.  Or the path.  Or something
> else you think might be unique (vendor/product id?, etc.)

I use this (stripped down to the minimum):

  insert snd-emu10k1 modprobe -i snd-emu10k1 index=0
  insert snd-via82xx modprobe -i snd-via82xx index=1

It's probably a good thing that I don't have two requiring the same driver.
:-)

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Output less CO2 => avoid boiling weather.     TIME IS RUNNING OUT *FAST*.

You have only a very small head and must live within it.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Sound card module loading sequence (was: Re: [PATCH] fix udevtrigger first/default/last ordering

[Alexander E. Patrakov]

Greg KH wrote:

> Name the sound devices based on the pci id.  Or the path.  Or something
> else you think might be unique (vendor/product id?, etc.)

Please see also http://lkml.org/lkml/2006/1/5/214

The question here is whether it is an acceptable idea to have persistent 
soundcard naming with this crazy "plughw:CARDID,0" or "index" hack instead of 
symlinks created by udev. BTW I think this hack won't work reliably for two 
identical cards (i.e., it would break if one upgrades BIOS).

I have not enough power to push this to ALSA maintainers, though.

-- 
Alexander E. Patrakov


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel