# [hässl. Workaround] Probleme beim Schreiben von udev Regeln

## 76062563

Ich habe in meinem Rechner zwei Soundkarten, eine Audigy 2 (Treiber snd_emu10k1) und einen Sound Blaster 128 (Treiber snd_ens1371)

Ausgabe von lspci:

```
05:06.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02)

        Subsystem: Ensoniq Creative Sound Blaster AudioPCI128

        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-

        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-

        Latency: 32 (3000ns min, 32000ns max)

        Interrupt: pin A routed to IRQ 21

        Region 0: I/O ports at a000 [size=64]

        Capabilities: [dc] Power Management version 1

                Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)

                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

05:08.0 Multimedia audio controller: Creative Labs SB Audigy (rev 04)

        Subsystem: Creative Labs SB Audigy 2 ZS (SB0350)

        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-

        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-

        Latency: 32 (500ns min, 5000ns max)

        Interrupt: pin A routed to IRQ 20

        Region 0: I/O ports at a400 [size=64]

        Capabilities: [dc] Power Management version 2

                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)

                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
```

Vor dem udev Update war die Audigy 2 /dev/dsp und der Soundblaster /dev/dsp1

Nach dem Update ist es meistens andersrum, aber nicht immer.

Also möchte mittels udev Regeln die beiden Einträge in /dev fest vergeben.

Ich habe noch nie udev Regeln erstellt, deswegen habe ich mir mal http://www.reactivated.net/writing_udev_rules.html zu Gemüte geführt.

Mein /etc/udev/rules.d/10-local.rules sieht jetzt so aus:

```
DRIVERS=="EMU10K1_Audigy", NAME="dsp"

DRIVERS=="ENS1371", NAME="dsp1"
```

Diese Regel hat allerdings zur Folge, dass mein Sound überhaupt nicht mehr geht:

```
zapp ~ # cat /dev/urandom > /dev/dsp

cat: Schreibfehler: Das Argument ist ungültig

zapp ~ # cat /dev/urandom > /dev/dsp1

cat: Schreibfehler: Das Argument ist ungültig
```

mplayer sagt Folgendes:

```
[AO OSS] Can't set audio device /dev/dsp to s16le output, trying s16le...

```

Ich hoffe jemand kann mir helfen ohne Sound ist alles ein bißchen doof.

Hier noch zwei Ausgaben von udevinfo:

```
zapp ~ # udevinfo -a -p /sys/class/sound/dsp/dev

Udevinfo starts with the device specified by the devpath and then

walks up the chain of parent devices. It prints for every device

found, all possible attributes in the udev rules key format.

A rule to match, can be composed by the attributes of the device

and the attributes from one single parent device.

  looking at device '/class/sound/dsp/dev':

    KERNEL=="dev"

    SUBSYSTEM=="sound"

    DRIVER==""

  looking at parent device '/class/sound/dsp':

    KERNELS=="dsp"

    SUBSYSTEMS=="sound"

    DRIVERS==""

    ATTRS{dev}=="14:3"

  looking at parent device '/devices/pci0000:00/0000:00:09.0/0000:05:08.0':

    KERNELS=="0000:05:08.0"

    SUBSYSTEMS=="pci"

    DRIVERS=="EMU10K1_Audigy"

    ATTRS{broken_parity_status}=="0"

    ATTRS{enable}=="1"

    ATTRS{modalias}=="pci:v00001102d00000004sv00001102sd00002002bc04sc01i00"

    ATTRS{local_cpus}=="ff"

    ATTRS{irq}=="20"

    ATTRS{class}=="0x040100"

    ATTRS{subsystem_device}=="0x2002"

    ATTRS{subsystem_vendor}=="0x1102"

    ATTRS{device}=="0x0004"

    ATTRS{vendor}=="0x1102"

  looking at parent device '/devices/pci0000:00/0000:00:09.0':

    KERNELS=="0000:00:09.0"

    SUBSYSTEMS=="pci"

    DRIVERS==""

    ATTRS{broken_parity_status}=="0"

    ATTRS{enable}=="1"

    ATTRS{modalias}=="pci:v000010DEd0000005Csv00000000sd00000000bc06sc04i01"

    ATTRS{local_cpus}=="ff"

    ATTRS{irq}=="0"

    ATTRS{class}=="0x060401"

    ATTRS{subsystem_device}=="0x0000"

    ATTRS{subsystem_vendor}=="0x0000"

    ATTRS{device}=="0x005c"

    ATTRS{vendor}=="0x10de"

  looking at parent device '/devices/pci0000:00':

    KERNELS=="pci0000:00"

    SUBSYSTEMS==""

    DRIVERS==""
```

und

```
zapp ~ # udevinfo -a -p /sys/class/sound/dsp1/dev

Udevinfo starts with the device specified by the devpath and then

walks up the chain of parent devices. It prints for every device

found, all possible attributes in the udev rules key format.

A rule to match, can be composed by the attributes of the device

and the attributes from one single parent device.

  looking at device '/class/sound/dsp1/dev':

    KERNEL=="dev"

    SUBSYSTEM=="sound"

    DRIVER==""

  looking at parent device '/class/sound/dsp1':

    KERNELS=="dsp1"

    SUBSYSTEMS=="sound"

    DRIVERS==""

    ATTRS{dev}=="14:19"

  looking at parent device '/devices/pci0000:00/0000:00:09.0/0000:05:06.0':

    KERNELS=="0000:05:06.0"

    SUBSYSTEMS=="pci"

    DRIVERS=="ENS1371"

    ATTRS{broken_parity_status}=="0"

    ATTRS{enable}=="1"

    ATTRS{modalias}=="pci:v00001274d00005880sv00001274sd00002000bc04sc01i00"

    ATTRS{local_cpus}=="ff"

    ATTRS{irq}=="21"

    ATTRS{class}=="0x040100"

    ATTRS{subsystem_device}=="0x2000"

    ATTRS{subsystem_vendor}=="0x1274"

    ATTRS{device}=="0x5880"

    ATTRS{vendor}=="0x1274"

  looking at parent device '/devices/pci0000:00/0000:00:09.0':

    KERNELS=="0000:00:09.0"

    SUBSYSTEMS=="pci"

    DRIVERS==""

    ATTRS{broken_parity_status}=="0"

    ATTRS{enable}=="1"

    ATTRS{modalias}=="pci:v000010DEd0000005Csv00000000sd00000000bc06sc04i01"

    ATTRS{local_cpus}=="ff"

    ATTRS{irq}=="0"

    ATTRS{class}=="0x060401"

    ATTRS{subsystem_device}=="0x0000"

    ATTRS{subsystem_vendor}=="0x0000"

    ATTRS{device}=="0x005c"

    ATTRS{vendor}=="0x10de"

  looking at parent device '/devices/pci0000:00':

    KERNELS=="pci0000:00"

    SUBSYSTEMS==""

    DRIVERS==""
```

----------

## McEnroe

So wie ich das sehe hast das Henne-Ei Problem...

Woher soll udev denn wissen welchen Treiber das Gerät verwendet wenn es selber dafür zuständig ist dem Kernel zu melden dass diese Geräte überhaupt existieren?

Ich würde die Regel so ändern:

```
ATTRS{subsystem_vendor}=="0x1102", ATTRS{subsystem_device}=="0x2002", NAME="dsp" 
```

Analog dazu das andere Gerät

----------

## 76062563

Ich habe die Regel so geändert:

```
ATTRS{subsystem_vendor}=="0x1102", ATTRS{subsystem_device}=="0x2002", NAME="dsp"

ATTRS{subsystem_vendor}=="0x1274", ATTRS{subsystem_device}=="0x2000", NAME="dsp1"
```

Das Problem besteht weiterhin.

Wenn ich alsamixer starten möchte kommt:

```
zapp ~ # alsamixer 

alsamixer: function snd_ctl_open failed for default: No such device
```

Hilft das irgendwie weiter?

Die Devices werden angelegt, ich kann sie aber nicht benutzen:

```
zapp ~ # ll /dev/dsp

crw-rw---- 1 root audio 14, 16 10. Feb 2007  /dev/dsp

zapp ~ # ll /dev/dsp1

crw-rw---- 1 root audio 14, 0 10. Feb 2007  /dev/dsp1
```

----------

## McEnroe

 *76062563 wrote:*   

> 
> 
> Die Devices werden angelegt, ich kann sie aber nicht benutzen:
> 
> ```
> ...

 

Reboote ein paar Mal und schau nach ob die devices jedes mal richtig erstellt werden. Wenn ja, so liegt das Problem mit sehr hoher Warscheinlichkeit an deiner ALSA-Konfiguration. Eine Möglichkeit es zu beheben wäre es alle ALSA-Treiber fest in den Kernel einzubinden. Andere Möglichkeiten sind mir nicht bekannt, da ich sie schlicht nicht benötige.

----------

## 76062563

Ich habe jetzt die beiden Soundtreiber fest in den Kernel einkompiliert.

Es sieht so aus, als ob die beiden Soundkarten immer genau andersrum sind als wie ich es will.

Man kann in der /etc/asound.conf einstellen welche Soundkarte die Defaulsoundkarte von alsa sein soll, das bringt mir aber nichts, weil sich weder mplayer noch skype an diese Einstellung halten.

Ich muss 'nur' irgendwie die Namen der Geräte 'umdrehen' , jedoch keine der drei von mir versuchten udev Regeln funktioniert:

```
KERNEL=="dsp1", NAME="dsp"

KERNEL=="dsp", NAME="dsp1"
```

```
ATTRS{subsystem_vendor}=="0x1102", ATTRS{subsystem_device}=="0x2002", NAME="dsp"

ATTRS{subsystem_vendor}=="0x1274", ATTRS{subsystem_device}=="0x2000", NAME="dsp1"
```

```
KERNELS=="0000:05:08.0", SUBSYSTEMS=="pci", DRIVERS=="EMU10K1_Audigy", NAME="dsp"

KERNELS=="0000:05:06.0", SUBSYSTEMS=="pci", DRIVERS=="ENS1371", NAME="dsp1"
```

----------

## firefly

hmm eine möglichkeit wäre, die treiber als modul zu bauen, dann sollte die lade reihenfolge das problem beheben.

Also mplayer kannst du dafür sorgen, das es nicht hw:0.0 nimmt sondern default beim alsa ausgabe treiber:

```
-ao alsa:device=default
```

----------

## 76062563

Meinst du wirklich, dass die Reihenfolge in der /etc/modules.autoload.d/kernel-2.6 etwas damit zu tun hat?

Ich hatte die Treiber vorher als Module und das Modul das ich als dsp haben wollte wurde als Erstes geladen.

Die Info mit dem mplayer ist schonmal nicht schlecht, ich habe die zweite Soundkarte aber eigentlich nur wegen dem Headset für sykpe drin. Und skype interessiert es nicht was ich in die /etc/asound.conf schreibe.

Ich kompiliere jetzt den Kernel nochmal mit den Treibern als Modul.

----------

## firefly

 *76062563 wrote:*   

> Meinst du wirklich, dass die Reihenfolge in der /etc/modules.autoload.d/kernel-2.6 etwas damit zu tun hat?
> 
> Ich hatte die Treiber vorher als Module und das Modul das ich als dsp haben wollte wurde als Erstes geladen.
> 
> Die Info mit dem mplayer ist schonmal nicht schlecht, ich habe die zweite Soundkarte aber eigentlich nur wegen dem Headset für sykpe drin. Und skype interessiert es nicht was ich in die /etc/asound.conf schreibe.
> ...

 

ja klar hat die reihenfolge was damit zu tun  :Smile:  denn wer zu erst kommt, bekommt /dev/dsp  :Wink: .

Seit v1.0.3.x  unterstütz skype auch alsa, Das wird dir aber bei diesem Problem nur wenig helfen, denn du müsstest beim jeden start die Einstellungen von skype ändern, falls sich die reihenfolge der SOundkarten wieder geändert hat.

Ach ja folgende regel funktioniert bei mir:

```
DRIVERS=="EMU10K1_Audigy", KERNEL=="dsp", NAME="sound/%k", SYMLINK+="%k_emu", GROUP="audio"
```

----------

## 76062563

Ich habe das Problem jetzt nicht wirklich gelöst, es aber mit einem richtig hässlichen Workaround behoben:

Nachdem ich die Audigy 2 fest, und den Sound Blaster als Modul in den Kernel genommen habe werden die Devices in der richtigen Reihenfolge angelegt.

Vielen lieben Dank trotzdem an McEnroe und firefly

----------

## TheSmallOne

 *76062563 wrote:*   

> Ich habe jetzt die beiden Soundtreiber fest in den Kernel einkompiliert.
> 
> Es sieht so aus, als ob die beiden Soundkarten immer genau andersrum sind als wie ich es will.
> 
> Man kann in der /etc/asound.conf einstellen welche Soundkarte die Defaulsoundkarte von alsa sein soll, das bringt mir aber nichts, weil sich weder mplayer noch skype an diese Einstellung halten.
> ...

 

Hast du es mal mit komplett anderen Namen versucht? Ich habe zwar nicht allzuviel Ahnung von UDEV, kann mir aber vorstellen, dass es Probleme bekommt, wenn du einem Device einen Namen zuweisen willst, der bereits existiert und an ein anderes Device vergeben ist. Genau das machst du hier aber scheinbar.

Probiere es am besten mal mit etwas ganz anderem ("test1", "test2" o.ä.).

----------

## Polynomial-C

Hi,

falls du auf die coldplug-Funktionalität von udev nicht anderweitig angewiesen bist, dann schalte sie doch einfach komplett ab und konfiguriere die Reihenfolge, in der die Module der einzelnen Soundkarten geladen werden sollen, wieder über /etc/modules.d/alsa.

```
sed -e 's:^RC_COLDPLUG=.*$:RC_COLDPLUG="no":' -i /etc/conf.d/rc
```

Grüße Poly-C

----------

## musv

Erstmal /dev/dspx ist nur die OSS-Emulation von alsa. Hat direkt mit Deinem Problem nicht soviel zu tun.

Ich hab dasselbe Problem auf meinem Rechner (an den ich aber in den nächsten 2-3 Wochen auch nicht rankomme). Da verwende ich 3 Soundkarten:

Audigy für normale Soundausgabe

Onboard-AC97 für Skype

BT8x8 für Soundgrabben von TV-Karte.

Beim Booten wird die Reihenfolge immer so festgelegt, wie ich es nicht will. Ist 'n intelligentes System. Die Konfiguration der Reihenfolge in /etc/modules.d/alsa wird dabei ignoriert. Ein manuelles Laden der Module scheint auch nichts zu bringen. (/etc/modules.autoload.d/).

Das Ganze hängt mit Coldplug zusammen. Beim Starten von Alsa werden die notwendigen Module geladen. Und zwar so, wie der Rechner grad Lust dazu hat. Wie bereits erwähnt, kannst du coldplug deaktivieren, bzw. in /etc/rc.conf festlegen, welche Module nicht geladen werden sollen. Frag mich aber nicht, wie das genau geht. Allerdings scheint das die einzige saubere Möglichkeit zu sein.

Siehe dazu auch hier:

https://forums.gentoo.org/viewtopic-t-448670-highlight-alsa.html

https://forums.gentoo.org/viewtopic-t-461482-highlight-alsa.html

----------

## Marlo

 *76062563 wrote:*   

> 
> 
> Nach dem Update ist es meistens andersrum, aber nicht immer.
> 
> 

 

Ich hatte mir Ende letzten Jahres einen Multimedia-Desktop aufgesetzt mit 2 Sound und 2 TV Karten, also insgesamt 4 Soundchips, Mythtv und den ganzen Schikimiki mit Fernbediehnung, DVD, Wetter und so weiter. Dabei kam mir auch udev-100 in die Quere und die Soundchips wurden durcheinandergewürfelt. Irgendwo in den Tiefen des Gentoo-Howto-Web gibt es einen ->kleinen-< Hinweiß, dass ab udev-100 die Alsa-Module, die in  /etc/modules.autoload.d/kernel-2.6 enthalten sind, in umgedrehter Reihenfolge geladen werden. Nicht mehr von oben nach unten, sondern andersrum. 

Der Tipp hatte geholfen, den Link finde ich leider nicht mehr, habe schon aufgeräumt. Dabei wird das Standarddevice, welches in der kernel-2.6 unten steht, zuverlässig geladen, die TV-devices liegen dann zwischen dem zweiten Soundchip, die man Dank coldplug nicht in der kernel-2.6 angeben mußte, sondern in /etc/modules.d/"modulname-mit-Parametern". Voraussetzung ist natürlich eine korrekte /etc/modules.d/alsa für multiple cards,  und eine passende .asoundrc.

Insgesamt hat mir der Ausflug in die Alsa-Welt mit der obigen Hardware gezeigt, dass es sich bei dem Thema Sound um das schwerste zu lösende Thema handelt, welches mir bisher unter Gentoo, oder Linux, untergekommen ist. Die manchmal ideologisch geführte Diskussion um die Vor- oder Nachteile der Kernel-Alsa oder media-sound/alsa-driver kann man auch vergessen, die Kernel-Alsa-Module funktionieren einwandfrei.

An die Udev-Rules ranzugehen halte ich für eine echte Herausforderung, wenn die notwendigen config Voraussetzungen nicht, oder unzureichend geschaffen worden sind.

Grüße

Ma

----------

## WiredEd

Also ich kann von einem sehr ähnlichen Problem bei mir berichten:

3 Sounddevices (emu10k1, intel8x0, und zeitweise eine hollywood+ karte). Ich hatte auch das problem, dass jedesmal nach nem neustart die devices in ner anderen reihenfolge vorlagen. Bei mir liess sich das Problem aber ganz einfach mit der option "index" vom kernelmodul lösen:

```

~ $ cat /proc/asound/cards

 0 [Live           ]: EMU10K1 - SB Live 5.1 [SB0220]

                      SB Live 5.1 [SB0220] (rev.10, serial:0x100a1102) at 0xd000, irq 20

 1 [nForce2        ]: NFORCE - NVidia nForce2

                      NVidia nForce2 with ALC650F at 0xef001000, irq 16

```

```

~ $ modinfo snd_emu10k1

filename:       /lib/modules/2.6.17.13/kernel/sound/pci/emu10k1/snd-emu10k1.ko

author:         Jaroslav Kysela <perex_at_suse.cz>

description:    EMU10K1

license:        GPL

vermagic:       2.6.17.13 preempt mod_unload K7 REGPARM gcc-3.4

depends:        snd-pcm,snd-util-mem,snd-page-alloc,snd-rawmidi,snd-hwdep,snd-ac97-codec

alias:          pci:v00001102d00000002sv*sd*bc*sc*i*

     ...  snip  ...

parm:           enable:Enable the EMU10K1 soundcard. (array of bool)

parm:           id:ID string for the EMU10K1 soundcard. (array of charp)

parm:           index:Index value for the EMU10K1 soundcard. (array of int)

```

```

~ $ cat /etc/modules.d/alsa

  ... snip ...

alias snd-card-0 snd-emu10k1

options snd-emu10k1 index=0

alias snd-card-1 snd-intel8x0

options snd-intel8x0 index=1 ac97_clock=0

```

Ich finde, dass das ganz elegant an den udev-rules vorbei gelöst ist   :Shocked:  , und gar nicht hässlich ^^. Allerdings benutze ich kein OSS und weiss deshalb nicht, wie sich das auf die dsp-devices auswirkt. Aber der logik nach ist sound-card-0 dann doch auch dsp0 und sound-card-1 dsp1 oder nicht?

----------

## 76062563

Weiß jemand ob dieser 'indexkernelparameter' auch für Netzwerkkarten geht?

Ich habe eben festgestellt, warum mein Router manchmal nicht geht, auch hier ist in sehr seltenen Fällen die Reihenfolge der NICs vertauscht.

Per Udevregel konnte ich das Problem bis jetzt nicht in den Griff bekommen, da hat die Reihenfolge auch nur meistens (und nicht immer) gestimmt.

----------

## firefly

 *76062563 wrote:*   

> Weiß jemand ob dieser 'indexkernelparameter' auch für Netzwerkkarten geht?
> 
> Ich habe eben festgestellt, warum mein Router manchmal nicht geht, auch hier ist in sehr seltenen Fällen die Reihenfolge der NICs vertauscht.
> 
> Per Udevregel konnte ich das Problem bis jetzt nicht in den Griff bekommen, da hat die Reihenfolge auch nur meistens (und nicht immer) gestimmt.

 

bei netzwerkkarten bestimmt auf jedenfall die reihenfolge wie die module geladen werden. Wenn du aber 2 gleiche Karten hast, die den selben treiber verwenden, dann spielt die reihenfolge davon ab, im welchem pci-slot die karten stecken.

Aber du kannst über eine udev-regel, welche die MAC-Addresse mit einbezieht, die karten umbenennen.

Beispiele:

```
SUBSYSTEM=="net", ATTRS{address}=="aa:bb:cc:dd:ee:ff", NAME="lan0"

SUBSYSTEM=="net", ATTRS{address}=="ff:ee:dd:cc:bb:aa", NAME="wlan0"
```

----------

## 76062563

Ich habe zwei verschiedene Netzwerkkarten, beide Treiber habe ich als Modul kompiliert und die Reihenfolge ist definitiv nicht immer gleich, aber meistens.

Ich glaub hier mach ich das auch, dass ich eine Karte als Modul reinnehme und die andre fest.

----------

## firefly

sollte normalerweise sein, auser das manchmal die eine karte länger braucht zum initialisieren als die andere.

----------

## musv

 *WiredEd wrote:*   

> Also ich kann von einem sehr ähnlichen Problem bei mir berichten:
> 
> 3 Sounddevices (emu10k1, intel8x0, und zeitweise eine hollywood+ karte). Ich hatte auch das problem, dass jedesmal nach nem neustart die devices in ner anderen reihenfolge vorlagen. Bei mir liess sich das Problem aber ganz einfach mit der option "index" vom kernelmodul lösen:
> 
> 

 

Die Index-Variante hab ich auch in meinen Optionen drinstehen. Bei werden die Indexeinträge aber konsequent und permanent ignoriert.

Abhilfe schafft bei mir nur ein:

/etc/init.d/alsasound restart

Dann sind alle Karten wie in den Config-Dateien angegeben in der richtigen Reihenfolge.

----------

## musv

Hab jetzt eine Lösung gefunden:

Das Problem mit den Soundkarten entsteht bei mir, weil die Treiber als Module gebaut werden und udev/hotplug die beim Bootvorgang willkürlich lädt. Das nachfolgende Alsascript und der Modulautoload können anschließend die Reihenfolge nicht mehr korrigieren. Also muß man die Module einfach manuell laden. 

Und das geht so:

Zuerst in die /etc/modules.d/alsa eintragen:

```

# Set this to the correct number of cards. 

options snd cards_limit=3 

# Reihenfolge festlegen

options snd-card-emu10k1 index=0

options snd-card-intel8x0 index=1 

options snd-card-bt87x index=2 

```

Dann ein modules-update und überprüfen, ob die Änderungen in die /etc/modprobe.conf übernommen wurden.

Dann in die /etc/modprobe.conf am Anfang per Hand eintragen:

```

blacklist snd_intel8x0

blacklist snd_emu10k1

blacklist snd_bt87x

...

alias char-major-10-175 agpgart

alias char-major-10-200 tun

```

Anmerkung: Ja ich weiß, daß die modprobe.conf durch update-modules bzw. modules-udpate eigentlich automatisch erzeugt wird. Allerdings hab ich in /etc/modules.d/ eine Datei "blacklist" angelegt mit den entsprechenden Einträgen. Und die wurde von den update-Scripten ignoriert. Bin für "ordentliche" Lösung immer offen.

Zum Schluß trägt man noch in /etc/modules.autoload.d/kernel-2.6 ein:

```

snd_emu10k1

snd_intel8x0

snd_bt87x

```

Dann sollten beim Booten die Module in richtiger Reihenfolge geladen werden.

EDIT (18.03.2007):

Das Blacklisting funktioniert automatisch, wenn man die nicht automatisch zu ladenden Module in /etc/modprobe.d/blacklist einträgt. /etc/modules.d/blacklist ist falsch.

----------

