# [solved] udev lädt Module?

## Battlestar Gentoo

Hallo,

gerade vorher habe ich den Kernel durch die Version 2.6.20.7 aktualisiert. Beim Booten kommt mir aber etwas seltsam vor. udev startet plötzlich das nvidia- und intel8x0-Modul (AC97 Sound).

Ein paar Zeilen weiter unten ladet modprobe nochmals die beiden Module, so wie es eben sein sollte. Was hat udev plötzlich damit zu tun? 

Es kommt mir nämlich irgendwie nicht ganz richtig vor.

----------

## tgurr

udev ersetzt quasi hotplug und lädt benötigte Module automatisch. Siehe z.B. /etc/udev/rules.d/50-udev.rules

----------

## Polynomial-C

Falls du das Laden der Module durch udev verhindern möchtest, einfach in der Datei /etc/conf.d/rc die Variable RC_COLDPLUG auf "no" setzen:

```
RC_COLDPLUG="no"
```

----------

## Battlestar Gentoo

Danke, das mit Coldplug hat funktioniert. Ich hoffe nur, dass es nicht andere Auswirkungen aufs System hat.

----------

## musv

Falls du das Coldplug-Verhalten nicht generell deaktivieren willst, kannst du auch bestimmte Module in die Blacklist eintragen. Diese werden dann nicht automatisch geladen. Mach ich so bei den Modulen für meine Soundkarten, da die sonst immer in willkürlicher aber falscher Reihenfolge geladen werden.

```

blacklist snd_intel8x0

blacklist snd_emu10k1

blacklist snd_bt87x

```

Danach ein modules-update und du hast diese "Sorgen" auch los.

----------

## firefly

 *musv wrote:*   

> Falls du das Coldplug-Verhalten nicht generell deaktivieren willst, kannst du auch bestimmte Module in die Blacklist eintragen. Diese werden dann nicht automatisch geladen. Mach ich so bei den Modulen für meine Soundkarten, da die sonst immer in willkürlicher aber falscher Reihenfolge geladen werden.
> 
> ```
> 
> blacklist snd_intel8x0
> ...

 

Nur das Problem mit dieser Blacklist ist der, das diese Module überhaupt nicht mehr automatisch geladen werden. Nicht beim starten des Systems oder wenn das entsprechende Gerät zu laufzeit angeschlossen wird.

----------

## furanku

Das Problem mit der falschen Reihenfolge der Soundkarten hatte ich auch mal. Es war ein bisschen Gebastel (ich hatte damals auch mit blacklisting angefangen, und das führt dann zu anderen Problemen ... entschuldigt wenn ich mich meinem damaligen Thread nicht mehr gemeldet habe, ich hatte dann was anderes, wichtigeres zu tun), aber es geht mit den entsprechenden index Optionen in der /etc/modules.d/alsa die Reihenfolge festzulegen. Z.B. sorgt bei mir 

```
options snd-intel8x0 index=0
```

dafür, daß meine onboard Soundkarte als erstes geladen wird. Ebenso lädt

```
options cx88-alsa index=1
```

den Audioteil meiner DVB-T Karte als zweite Soundkarte, usw.

Für ganz fortgeschrittene Anwendungen kann man mittels udev Regeln sogar noch bei mehreren gleichen Soundkarten dafür sorgen, daß diese auch eine feste definierte Reihenfolge der Devices bekommen. Blacklisting ist eher eine gute Idee bei Distributionen wie SuSE, die quasi alle Treiber des Kernels als Modul mitbringen und bei denen der YaST dann die tatsächlich benötigten Treiber auswählt, um zu verhindern, daß der falsche, zuviele Treiber oder problematische (wie z.B. das event debuggung Modul evbug, oder z.B. Netwerkkarten Module die in mehreren Versionen im Kernel vorhanden sind). Da man bei Gentoo Usern allerdings davon ausgehen kann, daß diese den Kernel für ihr System passend konfigurieren, ist der Weg über Module Blacklisting eher umständlich, fehlerträchtig und auch problematisch, da man das vorgesehene Verhalten explizit aushebelt.

Aber auch bei mir hat die Umstellung, daß udev das coldplugging erledigt zunächst für Verwirrung gesorgt. Vielleicht habe ich da was überlesen, oder man hätte bei diesem Umstieg besser auf die evtl. nötigen Konfigurationsänderungen hinweisen sollen.

----------

## musv

 *furanku wrote:*   

> Das Problem mit der falschen Reihenfolge der Soundkarten hatte ich auch mal. Es war ein bisschen Gebastel (ich hatte damals auch mit blacklisting angefangen, und das führt dann zu anderen Problemen ... , aber es geht mit den entsprechenden index Optionen in der /etc/modules.d/alsa die Reihenfolge festzulegen. Z.B. sorgt bei mir 
> 
> ```
> options snd-intel8x0 index=0
> ```
> ...

 

Sorry, aber da mußt du 'n anderes Gentoo benutzen als ich. Die Indizes hab ich in der /etc/modules.d/alsa ebenfalls drinstehen. Nur leider werden die nach allen Regeln der Kunst ignoriert. Und ich hab mit diesem Problem schon monatelang Foren und Newsbeiträge gewälzt, getestet und ausprobiert.

Beim Booten des Systems wurden über coldplug die Soundkartenmodule immer willkürlich in falscher Reihenfolge geladen. Damit wurden die Devices auch in Ladereihenfolge festgelegt. Nach meiner Erfahrung kann man die Reihenfolge der Soundkarten nur selbst festlegen, wenn man:

die Ladereihenfolge der Module explizit festlegt (über Blacklisting und dann als Eintrag bei /etc/modules.autoload.d/kernel26)

Restart des alsasound-Scripts nachdem das ganzes System fertiggebootet hat.

Wobei zweitere "Lösung" relativ unzuverlässig und bei tatsächlicher Nutzung auch nervig ist. Die Indizes für die einzelnen Soundkarten hab ich schon seit Jahren in der Config stehen. Die wurden immer ignoriert. Sollte es jetzt tatsächlich funktionieren, dann muß sich innerhalb des letzten halben Jahres ziemlich viel an udev/coldplug/alsa/wasauchimmer geändert haben.

Vielleicht hast du ja nur Glück, daß die Module bei Dir von vornherein in der richtigen Reihenfolge geladen werden, dann fällt das Problem nicht weiter auf. Bei mir zumindest ist Blacklisting die einzige Lösung, die bei der Soundkartenreihenfolge funktioniert. 

PS: Ich benutz übrigens die alsa-driver aus dem Portage und nicht die Kernelversion.

----------

## furanku

Es ist schon lustig (naja, Du dürftest das weniger lustig finden, sorry  :Wink:  ), aber genau wie Du habe ich auch lange probiert und mich auch über udevs coldplugging hier im Forum beschwert. Und auch mir sagten alle anderen, doch, es geht. Ich verwende hier udev-110-r1, Kernel 2.6.20-gentoo-r6, habe lediglich evbug und  eth1394 geblacklistet, und kein sound modul in modules.autoload. Folgende /etc/modules.d/alsa legt mir zuverlässig die Sound Devices in der gewünschten Reihenfolge an, obwohl die module beim start von udev geladen werden.

```

alias char-major-116 snd

alias char-major-14 soundcore

alias snd-card-0 snd-intel8x0

alias sound-slot-0 snd-card-0

alias sound-service-0-0 snd-mixer-oss

alias sound-service-0-3 snd-pcm-oss

alias sound-service-0-12 snd-pcm-oss

options snd-intel8x0 index=0

alias /dev/mixer snd-mixer-oss

alias /dev/dsp snd-pcm-oss

alias snd-card-1 cx88-alsa

alias sound-slot-1 cx88-alsa

alias sound-service-1-0 snd-mixer-oss

alias sound-service-1-3 snd-pcm-oss

alias sound-service-1-8 snd-seq-os

alias sound-service-1-12 snd-pcm-oss

options cx88-alsa index=1

alias /dev/mixer1 snd-mixer-oss

alias /dev/dsp1 snd-pcm-oss

alias /dev/midi snd-seq-oss

alias snd-card-2 snd-cmipci

alias sound-slot-2 snd-cmipci

alias sound-service-2-0 snd-mixer-oss

alias sound-service-2-3 snd-pcm-oss

alias sound-service-2-8 snd-seq-oss

alias sound-service-2-12 snd-pcm-oss

options snd-cmipci mpu_port=0x330 fm_port=0x388 index=2

alias /dev/mixer2 snd-mixer-oss

alias /dev/dsp2 snd-pcm-oss

options snd cards_limit=3

```

----------

## musv

In der Hoffnung, daß sich wirklich was geändert hat, hab ich mal getestet:

Folgende Soundkarten stecken bei mir drin:

-Soundblaster Audigy 1 (emu10k1)

-Nforce Onboard Soundchip (intel8x0)

-Hauppauge TV-Karte (Bt87x)

Hab wie du gesagt hast, die Blacklist bereinigt und neu gebootet:

Gewünschte Reihenfolge:

1. snd_emu10k1

2. snd_intel8x0

3. snd_bt87x

Ladereihenfolge der Module per coldplug (bei allen Versuchen gleich):

1. snd_bt87x

2. snd_intel8x0

3. snd_emu10k1

Reihenfolge der Soundkarten (1. Versuch):

1. snd_emu10k1

2. snd_bt87x

3. snd_intel8x0

Reihenfolge der Soundkarten (2. Versuch - ohne Configänderung!!!):

1. snd_intel8x0

2. snd_bt87x

3. snd_emu10k1

```

alias char-major-116 snd

alias char-major-14 soundcore 

# Set this to the correct number of cards. 

options snd cards_limit=3 

# Reihenfolge festlegen

alias snd-card-0 snd-emu10k1 

alias sound-slot-0 snd-emu10k1 

options snd-card-emu10k1 index=0

alias snd-card-1 snd-intel8x0 

alias sound-slot-1 snd-intel8x0 

options snd-card-intel8x0 index=1 

alias snd-card-2 snd-bt87x 

alias sound-slot-2 snd-bt87x 

options snd-card-bt87x index=2 

alias sound-slot-0 snd-card-0 

alias sound-service-0-0 snd-mixer-oss 

alias sound-service-0-1 snd-seq-oss 

alias sound-service-0-3 snd-pcm-oss 

alias sound-service-0-8 snd-seq-oss 

alias sound-service-0-12 snd-pcm-oss 

alias sound-slot-1 snd-card-1 

alias sound-service-1-0 snd-mixer-oss 

alias sound-service-1-1 snd-seq-oss 

alias sound-service-1-3 snd-pcm-oss 

alias sound-service-1-8 snd-seq-oss 

alias sound-service-1-12 snd-pcm-oss 

alias sound-slot-2 snd-card-2 

alias sound-service-2-0 snd-mixer-oss 

alias sound-service-2-1 snd-seq-oss 

alias sound-service-2-3 snd-pcm-oss 

alias sound-service-2-8 snd-seq-oss 

alias sound-service-2-12 snd-pcm-oss 

alias /dev/mixer snd-mixer-oss 

alias /dev/dsp snd-pcm-oss 

alias /dev/midi snd-seq-oss

```

Wenn ich da irgendwo einen Fehler drin haben sollte, dann probier ich gerne weiter. Aber bis dahin bleib ich bei meiner Meinung, daß die Soundkartenreihenfolge nicht durch die Indizierung in oben aufgelisteter Datei beeinflußt werden kann. Ich behaupte mal einfach weiterhin, daß bei Dir die zufällig durch das System gewählte Reihenfolge der Soundkarten glücklicherweise gerade der von Dir gewünschten entspricht.

----------

## furanku

Das ist merkwürdig. Ich habe eben mal probehalber neu gebootet. udev lädt tatsächlich die Module in der reihenfolge. Nun habe ich die cmipci und die cx88 (also Nr. 2 und 3) in der /etc/modules/alsa vertauscht. Resultat wie gewünscht: Beim Booten lud udev nun zurest das cmipci und danach das cx88 Modul, so daß mit ein  

```
$ cat /proc/asound/cards

 0 [CK804          ]: NFORCE - NVidia CK804

                      NVidia CK804 with ALC850 at 0xfe02d000, irq 22

 1 [CMI8738MC6     ]: CMI8738-MC6 - C-Media PCI CMI8738-MC6

                      C-Media PCI CMI8738-MC6 (model 55) at 0xac00, irq 17

 2 [CX8811         ]: CX88x - Conexant CX8811

                      Conexant CX8811 at 0xfa000000

```

 ausgibt, was ja genau der neuen, gewünschten Reihenfolge entspricht.

Ich sehe jedoch beim schnellen Überfliegen Deiner /etc/moduls.d/alsa keinen Fehler. Bist Du Dir sicher, daß alles in die /etc/modprobe.conf richtig beim update-modules übernommen wird? Wie, gesagt, ich hatte diese Probleme auch mal, und dachte auch es geht nicht. Dann habe ich auf gutes zureden hier aus dem Forum alles was Sound und Module laden betrifft nochmal von Grundauf neu angelegt und seit dem klappts wie am Schnürchen.

PS.: Das ist hier mal ein Beispiel wie sich ein gut gemeintes [solved] in der Betreffzeile auch mal negativ auswirken kann.

PPS.: Du erwähnst, daß Dir "coldplug" die Module lädt, ich hoffe wir meinen beide damit das gleiche, nämlich die coldplugging Funktionalität von udev. Ich habe hier kein seperates coldplug installiert (und portage sagt mir auch daß udev coldplug blockiert).

----------

## musv

 *furanku wrote:*   

> PS.: Das ist hier mal ein Beispiel wie sich ein gut gemeintes [solved] in der Betreffzeile auch mal negativ auswirken kann.

 

Naja, mit dem eigentlichen Thema hat's ja auch nicht mehr soviel zu tun.

 *furanku wrote:*   

> PPS.: Du erwähnst, daß Dir "coldplug" die Module lädt, ich hoffe wir meinen beide damit das gleiche, nämlich die coldplugging Funktionalität von udev. Ich habe hier kein seperates coldplug installiert (und portage sagt mir auch daß udev coldplug blockiert).

 

Jap, coldplug als Teil von udev. Installiert hab ich Version udev-110-r1. Coldplug selbst hab ich schon seit Ewigkeiten nicht mehr installiert.

PS: Selbstverständlich hab ich auch update-modules ausgeführt.

----------

## Polynomial-C

Hi,

ich kann mich ja auch irren, aber mir kommt an deiner /etc/modules.d/alsa etwas seltsam vor musv. Du hast folgendes in der Datei drinstehen: 

```
...

options snd-card-emu10k1 index=0

...

options snd-card-intel8x0 index=1

...

options snd-card-bt87x index=2

...
```

 Jetzt frage ich mich, woher das -card in den Zeilen kommt?

Müßte das nicht eher so aussehen? 

```
...

options snd-emu10k1 index=0

...

options snd-intel8x0 index=1

...

options snd-bt87x index=2

...
```

Ich habe noch nie Optionen an Alsamodule übergeben, deshalb weiß ich es nicht exakt. Aber in den ALSA-Dokus habe ich nur die "options snd-[Treibername] [...]" Version gefunden...

----------

## furanku

 *Polynomial-C wrote:*   

>  
> 
> ```
> ...
> 
> ...

 

Stimmt, das habe ich vollkommen überlesen! Gute Augen, Polynomial-C!

Die Optionen müssen natürlich an das Kernelmodul selber übergeben werden und snd-card-intel8x0 gibt es nicht. (Ich meine mich dunkel zu erinneren, daß die Alsa Entwickler vor ein paar Jahren mal die Namenskonventionen geändert haben, trotzdem ist das anscheinend noch eine ziemliche fehlerträchtige Notation)

 *musv wrote:*   

> Naja, mit dem eigentlichen Thema hat's ja auch nicht mehr soviel zu tun.

 Wir sind doch immer noch bei den Tücken des coldplugging von udev.

musv, probiers mal damit, das stinkt geradezu danach, der Fehler zu sein!

----------

## musv

Na sowas aber auch...

Du hast recht, jetzt funktioniert das bei mir ebenfalls. Habs ausprobiert. Es lag wirklich an snd-card0-xxx. Danke, darauf wär ich sonst nie gekommen.

----------

## furanku

 *musv wrote:*   

> Na sowas aber auch...
> 
> Du hast recht, jetzt funktioniert das bei mir ebenfalls. Habs ausprobiert. Es lag wirklich an snd-card0-xxx. Danke, darauf wär ich sonst nie gekommen.

 

Siehste  :Wink:   Dank sei Polynominal-Cs guten Augen! So ein AHA Erlebnis hatte ich wie gesagt auch mit meiner Installation und war vorher auch schon sauer auf diesen "offensichtlichen" Fehler.

Aber wäre das nicht sogar eigentlich ein Verbesserungsvorschlag für update-modules? Es müßte doch ohne größeren Aufwand möglich sein, zu überprüfen ob es das Modul, an das da Optionen übergeben werden auch wirklich gibt. Ein einfaches modinfo sollte doch ausreichen um sogar noch zu überprüfen ob es auch die optionen gibt. Macht man Verbesserungswünsche immer noch bei bugs.gentoo oder sollte man mit sowas lieber den Maintainer anmailen?

----------

