Hi Aufgrund der letzten Meldungen über local-root exploits habe ich hier einen Kernel 2.4.24 compiliert. Es scheint auch alles zu funktionieren. Mangels entsprechender Kenntnisse zum Kernel selber patchen bin ich auf Oss umgestiegen. Alsa ist deaktiviert und nach einem modprobe i810_audio höre ich auch sound. Nur wie bewerkstellige ich es nun am geschicktesten, dass dieses Modul bei jedem boot geladen wird. Ich benutze hier SuSE8.1. mfg Axel
Axel Heinrici wrote:
Aufgrund der letzten Meldungen über local-root exploits habe ich hier einen Kernel 2.4.24 compiliert. Es scheint auch alles zu funktionieren. Mangels entsprechender Kenntnisse zum Kernel selber patchen bin ich auf Oss umgestiegen. Alsa ist deaktiviert und nach einem modprobe i810_audio höre ich auch sound. Nur wie bewerkstellige ich es nun am geschicktesten, dass dieses Modul bei jedem boot geladen wird. Ich benutze hier SuSE8.1.
Lese bitte (bei installierten Kernel-Quellen, aber da Du Deinen Kernel selbst compiliert hast, sind die Quellen ja da) o /usr/src/linux/Documentation/sound/README.OSS o /usr/src/linux/Documentation/sound/README.modules da wirst Du die Antwort auf Deine Frage finden. By the way, fuer ALSA muss man keinen Kernel patchen, Du musst Dir lediglich die entsprechenden Pakete von ALSA besorgen und die fuer Dich relevanten Module compilieren. Dazu gibt es AFAIK auch eine Anleitung auf alsa-project.org. CU, Th.
Hi On Monday 12 January 2004 17:00, Thomas Hertweck wrote:
Lese bitte (bei installierten Kernel-Quellen, aber da Du Deinen Kernel selbst compiliert hast, sind die Quellen ja da) o /usr/src/linux/Documentation/sound/README.OSS o /usr/src/linux/Documentation/sound/README.modules da wirst Du die Antwort auf Deine Frage finden.
Habe ich jetzt nochmal gründlich gemacht. Hatte zuerst aufgrund der angabe "File edited 17.01.1999" bzw. "..information is current as of linux-2.1.85..." nur überflogen. Aber auch erneutes Lesen hilft mir momentan nicht weiter. Da finde ich nur Infos wie ich historische Karten zu konfigurieren habe. Zum einen ist da von nem Intel 810 noch überhaupt keine Rede. Und zum Anderen läuft meine Soundkarte ja, wenn ich modprobe von Hand aufrufe. Es geht also wirklich _nur_ darum dieses Modul beim booten laden zu lassen. Für alsa gibt es bei SuSE ein fertiges Skript, andere Distrubutionen kennen ne Datei /etc/modules. Ich denke nicht, dass ich ein lernresistenter Dokumentationsverweigerer bin. Und in Erwartung einer Kurzantwort der Form "...füge den Dreizeiler ... an der Stelle .... ein, weil ..." habe ich es mal mit einer Anfrage auf der Liste probiert. Bei diesen boot-Geschichten handelt es sich ja schließlich wirklich um ein SuSE-Spezifisches Problem. Wollte eigentlich nur vermeiden ein rc-Skript selber stricken zu müssen oder das Modul von Hand zu laden.
By the way, fuer ALSA muss man keinen Kernel patchen, Du musst Dir lediglich die entsprechenden Pakete von ALSA besorgen und die fuer Dich relevanten Module compilieren. Dazu gibt es AFAIK auch eine Anleitung auf alsa-project.org.
Wieder was gelernt. Aber bevor ich das anfange lebe ich eher noch ein paar Wochen mit dem von Hand Laden. :-) mfg Axel
Axel Heinrici wrote:
Da finde ich nur Infos wie ich historische Karten zu konfigurieren habe.
Hmm, was heisst historisch? Du musst verstehen, wie es funktioniert und es dann entsprechend fuer Deinen Fall anwenden - das Bedarf etwas Abstrahiervermoegen. Da spielt es aber keine Rolle, dass es zu dem Zeitpunkt vielleicht noch keinen Intel-Chip gegeben hat. Ich habe keinen Intel 810 und nutze kein OSS und kann Dir daher nur generelle Tips geben, wie ich es verstanden habe, und keine Details. Ich halte aber die Nutzung von ALSA fuer die weit bessere Alternative. Die ALSA-Module installieren ist eigentlich nicht so schwer.
Zum einen ist da von nem Intel 810 noch überhaupt keine Rede. Und zum Anderen läuft meine Soundkarte ja, wenn ich modprobe von Hand aufrufe. Es geht also wirklich _nur_ darum dieses Modul beim booten laden zu lassen.
Also,in /usr/src/linux/Documentation/sound/README.modules findest Du doch neben vielem anderen auch die folgenden Zeilen: [...] Then, add to your /etc/modules.conf something like: alias char-major-14 sb post-install sb /sbin/modprobe "-k" "adlib_card" options sb io=0x220 irq=7 dma=1 dma16=5 mpu_io=0x330 options adlib_card io=0x388 # FM synthesizer [...] Replace 'sb' with the driver for your card, and give it the right options. [...] So wie ich das also hier lese (wobei ich momentan kein OSS benutze), brauchst Du in Deiner /etc/modules.conf also einen Eintrag "alias char-major-14 <module-name>", wobei Du <module-name> eben durch den Namen fuer das OSS Intel-Modul ersetzen musst. Mit ALSA funktioniert es anders!! In /usr/src/linux/Documentation/devices.txt findest Du auch zum Character Device mit der Major Nummer 14 die folgende Info: [...] 14 char Open Sound System (OSS) 0 = /dev/mixer Mixer control 1 = /dev/sequencer Audio sequencer 2 = /dev/midi00 First MIDI port [...] Soweit so gut. Obigen post-install Befehl kannst Du ja erst einmal weglassen, der laedt eben nach dem einen Modul noch ein anderes nach. Ebenso kannst Du es ja erst einmal ohne Optionen versuchen. In meiner /etc/modules.conf findet sich auch folgender Abschnitt: ######################################################################## # # Aliases for OSS # # These aliases will be changed by YaST2 sound configurator. # If you would like to configure OSS drivers by yourself, please # take a look at the files on /usr/src/linux/Documentation/sound. # ######################################################################## alias char-major-14 off alias sound off alias midi off [...] Hier kannst Du also Deine Aenderungen machen. Deine Anwendung muss natuerlich dann auch OSS verwenden, und ALSA solltest Du wohl auch nicht mehr aktivieren im Runlevel bzw. die entsprechenden Eintraege in /etc/modules.conf auskommentieren. Ob und wie sich da etwas ins Gehege kommt, weiss ich nicht, aber ich hoffe, Du kommst mit den Infos hier schon mal weiter... Kann das hier alles nicht testen. Ich halte aber die Nutzung von ALSA fuer die weit bessere Alternative. Ich wusste z.B. auch gar nicht, dass es einen OSS Treiber fuer diesen Intel-Chip gibt. Dachte, der wird nur von ALSA unterstuetzt. Aber da kennst Du Dich ja sicher besser aus als ich... Gruesse, Thomson
Hallo, Am Tue, 13 Jan 2004, Axel Heinrici schrieb:
Da finde ich nur Infos wie ich historische Karten zu konfigurieren habe. Zum einen ist da von nem Intel 810 noch überhaupt keine Rede. Und zum Anderen läuft meine Soundkarte ja, wenn ich modprobe von Hand aufrufe. Es geht also wirklich _nur_ darum dieses Modul beim booten laden zu lassen.
Versuch mal ein alias char-major-14 i810_audio in deiner modules.conf. -dnh -- For modern bandwidth requirements, of course, we would have to develop massively-parallel heliographs with thousands of mirrors, which could have impressive LART potential. "OK, everyone transmit to the spammer over there . . . now! <fizzle>" -- Steve VanDevender
Hallo On Tuesday 13 January 2004 16:06, David Haller wrote:
Am Tue, 13 Jan 2004, Axel Heinrici schrieb:
Hand aufrufe. Es geht also wirklich _nur_ darum dieses Modul beim booten laden zu lassen.
Versuch mal ein
alias char-major-14 i810_audio
in deiner modules.conf.
Erstmal vorweg, ich habe mich jetzt doch für alsa entschieden. War einfacher als ich dachte und YaST arbeitet auch nciht mehr gegen einen. Der obige Alias hat leider nichts gebracht. Ich würde diese Modul-Geschichte aber gerne noch etwas besser verstehen, um nich jedesmal bei einem ählichen Problem wieder nachfragen zu müssen. Wenn ich mir man 5 modules.conf durchlese, dann steht da ganz oben "...DESCRIPTION The behavior of modprobe(8) (and depmod(8) ) can be modified ... ". Für mich stellt sich da immernoch die Frage: "Welchen Mechanismus soll dieser Alias in Gang setzten? Wann soll dieses Modul denn nun von wem geladen werden?" Für alsa gibt es ja ein Skript in /etc/rc.d/ welches beim Hochfahren ausgeführt wird. Wäre hier für Aufklärung sehr dankbar. mfg Axel
Axel Heinrici wrote:
Erstmal vorweg, ich habe mich jetzt doch für alsa entschieden. War einfacher als ich dachte und YaST arbeitet auch nciht mehr gegen einen.
Hab' ich doch gesagt :-)
Ich würde diese Modul-Geschichte aber gerne noch etwas besser verstehen, um nich jedesmal bei einem ählichen Problem wieder nachfragen zu müssen. Wenn ich mir man 5 modules.conf durchlese, dann steht da ganz oben "...DESCRIPTION The behavior of modprobe(8) (and depmod(8) ) can be modified ... ". Für mich stellt sich da immernoch die Frage: "Welchen Mechanismus soll dieser Alias in Gang setzten? Wann soll dieses Modul denn nun von wem geladen werden?"
Sobald der Kernel ein Ereignis entdeckt, fuer das er selbst keine Unterstuetzung hat (z.B. die Unterstuetzung fuer ein Filesystem oder die Unterstuetzung fuer den Zugriff auf ein Device, den seriellen Port z.B.), dann wird der Kernel Module Loader (kmod) aktiv. Ueber einen modprobe-Befehl (oder genauer: ueber das Programm, was die Ausgabe von "cat /proc/sys/kernel/modprobe" bei Kernel 2.4 ergibt; in der Regel ist das /sbin/modprobe) wird versucht, ein Modul zu laden, was die angeforderte Unterstuetzung bereit stellt. Das Modul wird registriert und der Kernel kann nun die Aufgabe ausfuehren, die er urspruenglich erledigen sollte. Wird kein Modul "gefunden", das die angeforderte Unterstuetzung bereit stellt, so kann der Kernel logischerweise seine Aufgabe nicht erfuellen und es wird eine Fehlermeldung ausgegeben... Stellt sich die Frage, woher nun bekannt ist, welches Modul genau geladen werden soll, wenn o.a. Fall auftritt. Da gibt es verschiedene Moeglichkeiten und da kommt dann auch die Datei /etc/modules.conf (bei Kernel 2.4) ins Spiel, denn sie ist die Konfigurationsdatei fuer modprobe. Beim Zugriff auf ein Device mit der Major Number N (siehe dazu auch die Datei /usr/src/linux/Documentation/devices.txt) wird versucht, ein Modul mit dem Namen block-major-N bzw. char-major-N zu laden, je nachdem, ob es sich um den Zugriff auf ein Block oder Character Device handelt. Entsprechend gibt es Eintraege in /etc/modules.conf. Der NVIDIA-Treiber benutzt z.B. ein Device mit Major Number 195, wie Du leicht per "ls -l /dev/nvidia*" feststellen kannst (so Du eine NVIDIA-Karte hast): crw-rw-rw- 1 root root 195, 0 2004-01-14 18:09 /dev/nvidia0 crw-rw---- 1 root video 195, 0 2003-03-14 14:08 /dev/nvidia00 crw-rw---- 1 root video 195, 1 2003-03-14 14:08 /dev/nvidia01 crw-rw---- 1 root video 195, 2 2003-03-14 14:08 /dev/nvidia02 crw-rw---- 1 root video 195, 3 2003-03-14 14:08 /dev/nvidia03 crw-rw-rw- 1 root root 195, 1 2004-01-14 18:09 /dev/nvidia1 [...] Es handelt sich also alles um Character Devices (siehe das "c" zu Beginn der Zeile) mit Major Number 195. Entsprechend findest Du dann einen Eintrag alias char-major-195 nvidia in der /etc/modules.conf. Uebersetzt heisst das schlicht, "bei Zugriff auf ein Character Device mit der Major Number 195, lade das Modul nvidia.o". Dafuer steht der Alias. Beim Zugriff auf ein Netzwerkinterface, das bisher von keinem Treiber registriert wurde, wird schlicht ein Modul angefragt, das den Namen des Interfaces traegt. Beim Interface eth0 wird also versucht, ein Modul mit Namen eth0 zu laden (das gibt es aber physikalisch nicht). In der Datei /etc/modules.conf findest Du deswegen z.B. einen Eintrag wie "alias eth0 ne2k-pci" (so siehst das bei mir aus, bei Dir evtl. eben anders, wenn Du einen anderen Treiber fuer Deine Netzwerkkarte brauchst) - das bedeutet wie oben bereits beschrieben, dass das Anfordern eines Modules fuer eth0 in das Laden des Modules "ne2k-pc.o" umgesetzt wird. Sollte eigentlich einleuchten, oder? Beim Zugriff auf ein Socket in einer Protokollfamilie, fuer das bisher kein Treiber registriert wurde, wird das Modul net-pf-N angefordert, wobei N diesmal die Nummer der Protokollfamilie ist. Beispiel hierfuer waere "alias net-pf-5 appletalk". Die Nummer der Protokollfamilie findest Du z.B. in /usr/src/linux/include/linux/socket.h. Der ATA Device-Treiber (ide) laedt die Treiber fuer gewisse Klassen von Geraeten durch Namen: ide-disk, ide-cd, ide-floppy, ide-tape und, wenn man es etwas verallgemeinert, auch ide-scsi (siehe dazu Archiv der Liste; mit ide-scsi ist es etwas besonderes - das schreibe ich hier mal besser dazu, sonst widerspricht mir David wieder :-) Ein "alias <name> off" in /etc/modules.conf besagt, dass jegliche Anfrage, ein derartiges Modul zu laden, ignoriert wird. Kann kein geeignetes Modul gefunden werden, so bekommt man z.B. "modprobe: Can't locate module char-major-195" zu sehen (bzw. man findet es dann in /var/log/messages) - das bedeutet dann uebersetzt, siehe oben, dass das Modul nvidia.o nicht gefunden werden kann. Oft der Fall, wenn ein neuer Kernel (oder ein Update) installiert und dabei vergessen wurde, das Kernel-Modul des NVIDIA-Treibers neu zu erstellen fuer den neuen Kernel. Wird ein Modul korrekt geladen, obwohl kein entsprechender Eintrag in der Konfigurationsdatei /etc/modules.conf vorkommt, so darf man sich nicht wundern. Modprobe hat bereits einige Aliase fest einprogrammiert, die man in der Datei util/alias.h bei den modutils-Quellen nachlesen kann. Die Datei /etc/modules.conf ist also die zentrale Konfigurationsdatei fuer modprobe und damit zum automatischen Laden von Kernel-Modulen. Wie oben erklaert, wird dort geregelt, welches Modul wann zu laden ist. Aber es koennen auch gewisse Optionen zum Laden eines Modules angegeben werden (das sind dann die Zeilen, die mit "options" beginnen, z.B. "options eepro io=0x260 irq=10 mem=0x6000") oder es koennen beim Laden eines Modules automatisch weitere Module nachgeladen (oder auch vorher gelanden) werden. Ein Beispiel waere hier: pre-install radeon /sbin/modprobe "-k" "agpgart". Umgekehrt nennt man es dann post-install, z.B.: post-install bttv /sbin/modprobe "-k" tuner. Auch fuer das Entfernen von Modulen gibt es Regeln, u.v.m. All das steht in "man modules.conf" erklaert. Ueber "depmod" werden automatisch Abhaengigkeiten zwischen Modulen ermittelt, Du findest das dann in der Datei modules.dep in /lib/modules/`uname -r`. Wenn Du Dir die Datei anschaust, dann sieht das so aehnlich aus wie bei Abhaengigkeiten in einem Makefile (das wird Dir natuerlich nur bekannt vorkommen, wenn Du Dich auch mit Makefiles auskennst :-) Wenn depmod nicht in der Lage ist, ein Symbol zu finden, das fuer ein gewisses Modul gebraucht wird (dann wuerde das zu ladende Modul von einem anderen Modul abhaengen, was das Symbol bereit stellt), so bekommst Du die beruechtigte Meldung ueber "Unresolved symbols in <module-name>"... Ein derartiges Modul, was diese Meldung verursacht, kann nicht geladen werden, weil fuer dessen Funktionalitaet etwas fehlt. Ferner legt depmod noch einige Map-Dateien an, die sind dann fuer hotplug. Ich hoffe, dass diese Erklaerung Dich einigermassen zufrieden stellt. Gruesse, Thomson
Hi On Thursday 15 January 2004 14:26, Thomas Hertweck wrote:
[...enorm Ausführliche Erklärung ...]
Ich hoffe, dass diese Erklaerung Dich einigermassen zufrieden stellt.
In der Tat! Mit einer derartig ausführlichen Erklärung habe ich gar nicht gerechnet, danke (auch an Dieter). Ich glaube jetzt ist ist mir klar wie das funktionieren sollte. Der Alias bewirkt also, dass das Modul geladen wird, wenn irgendein Programm ein sound-device benutzt. Also hätte der Kernel mit dem Alias von char-major-14 auf i810_audio beim Öffnen des Mixers oder xmms o.ä. die Module automatisch laden sollen (Keine Sorge! -- warum das nicht ging ist mir jetzt auch egal). Und das Skript /etc/rc.d/alsasound, welches SuSE mitliefert ist gewissermaßen ein Luxus, um die Alsa-Module in jedem Fall zu laden und nicht irgendwann später von der langsamen Platte nachladen zu müssen. Zu SuSE7.x-Zeiten gab es so ein rc-Skript nämlich auch für OSS, deswegen dachte ich man bräuchte das. Keine weiteren Fragen mehr stellend und mit freundlichem Gruß Axel
Hallo, Am Thu, 15 Jan 2004, Axel Heinrici schrieb:
On Thursday 15 January 2004 14:26, Thomas Hertweck wrote:
[...enorm Ausführliche Erklärung ...]
Ich hoffe, dass diese Erklaerung Dich einigermassen zufrieden stellt.
In der Tat! Mit einer derartig ausführlichen Erklärung habe ich gar nicht gerechnet, danke (auch an Dieter). Ich glaube jetzt ist ist mir klar wie das funktionieren sollte. Der Alias bewirkt also, dass das Modul geladen wird, wenn irgendein Programm ein sound-device benutzt. Also hätte der Kernel mit dem Alias von char-major-14 auf i810_audio beim Öffnen des Mixers oder xmms o.ä. die Module automatisch laden sollen (Keine Sorge! -- warum das nicht ging ist mir jetzt auch egal).
Ich vermute, es braucht doch noch weitere aliase. Bei mir z.B. mit dem 'mad16'-Treiber: alias char-major-14 mad16 alias mixer0 mad16 alias audio0 mad16 alias midi0 mad16 alias synth0 opl3 options opl3 io=0x388 options mad16 io=0x530 irq=7 dma=0 dma16=1 mpu_io=0x330 mpu_irq=11 joystick=1 below mad16 opl3 mpu401 ad1848 post-install mad16 /sbin/ad1848_mixer_reroute 14 8 15 3 16 6 Welches Modul bei dir fuer synth0 zustaendig waere weiss ich aber nicht, ansonsten ist 'mad16' durch 'i810_audio' zu ersetzen. Die letzten 3 Zeilen sind bei dir vermutlich nicht noetig. Obiges steht uebrigens auch irgendwo in der Kernel-Doku.
Und das Skript /etc/rc.d/alsasound, welches SuSE mitliefert ist gewissermaßen ein Luxus, um die Alsa-Module in jedem Fall zu laden und nicht irgendwann später von der langsamen Platte nachladen zu müssen.
Genau. Wobei die Verzoegerung IMO irrelevant ist. Ok, bei Sound ist das automatisch laden wohl meistens "nur sauberer"[1], bei anderen Sachen, die man eben wirklich nicht immer braucht (ide-scsi, usb-storage z.B.) ist's IMO sinnvoll, v.a. wenn man nicht massig RAM hat. -dnh [1] bei mir wird der Sound-Kram geladen, wenn ich mich als User einlogge, da ich dann mit aumix -L die Mixereinstellungen lade ;) -- Well I wish you'd just tell me rather than try to engage my enthusiasm. -- Marvin
David Haller
[1] bei mir wird der Sound-Kram geladen, wenn ich mich als User einlogge, da ich dann mit aumix -L die Mixereinstellungen lade ;)
Woran man sieht, dass du OSS verwendest :) Bei ALSA würde das von /etc/init.d/alsasound automatisch erledigt (und würde mittels modules.conf nur schwierig hinzukriegen sein). Philipp
Hallo, Am Thu, 15 Jan 2004, Philipp Thomas schrieb:
David Haller
[15 Jan 2004 16:59:39 +0100]: [1] bei mir wird der Sound-Kram geladen, wenn ich mich als User einlogge, da ich dann mit aumix -L die Mixereinstellungen lade ;)
Woran man sieht, dass du OSS verwendest :)
Stimmt. Ich hab damals ALSA nicht zum laufen gebracht und IIRC gab's da auch keinen Alsa-Treiber fuer meine Soundkarte[2]
Bei ALSA würde das von /etc/init.d/alsasound automatisch erledigt (und würde mittels modules.conf nur schwierig hinzukriegen sein).
Ich hab mal das alsasound der 8.2 angeschaut: ==== function probe_module () { /sbin/modprobe $* test $? = 0 && return 0 return 1 } [..] drivers=`/sbin/modprobe -c | \ grep -E "^[[:space:]]*alias[[:space:]]+snd-card-[[:digit:]]" | sort |\ awk '{print $3}'` for i in $drivers; do if [ $i != off ]; then if [ x$c = x ]; then echo -n ": " c=1 fi echo -n " ${i##snd-}" probe_module $i && module_loaded=1 fi done ==== Das ist doch Unfug. Das ist nur ein gescriptetes "haendisches" Laden der Module. ==== alias char-major-116 snd alias sound-slot-0 snd-card-0 alias sound-service-0-0 snd-mixer-oss options snd snd_cards_limit=1 snd_major=116 # uniq.virtual:Mozart, OAK alias snd-card-0 snd-opti92x-ad1848 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-11 snd-mixer-oss alias sound-service-0-12 snd-pcm-oss ==== Ich sehe nicht, warum das nicht modprobe allein koennen soll, wobei u.U. eben noch Abhaengigkeiten fehlen, vermutlich: {below,above} snd snd-opti92x-ad1848 Also eine manuelle Abhaengigkeit von einem "allgemeinen" Treiber. Vergleiche: sg -> scsi_mod -> {ide-scsi,aic7xxx,scanner,...} sd_mod -> scsi_mod -> {aic7xxx,usb-storage} Und evtl. noch mehr Abhaengigkeiten, die kenne ich halt noch nicht, da ich Alsa bisher nicht verwendet habe. Hm. Muss ich mal testen[3]... Bei 2.6 muss man AFAIK das statt mit {above,below} dann eben wieder mit {post,pre}-{install,remove} loesen... Den Rest dessen, was alsasound macht gehoert in ein eigenes script nach /sbin/, das via post-install / pre-remove aufgerufen wird, also u.a. das alsactl {restore,store}. IMHO. -dn'*scnr*'h [2] Oak Technology Mozart Karte, mit Opti-Chip und nativem, SB und WSS Modi... [3] wenn allgemeines Interesse besteht (speziell von dir oder perex), dann mach ich das... Ansonsten ist das von mir nur ein "akademisches" Interesse... Naja, wenn ich dann mal die Voraussetzungen fuer 2.6.x habe, dann vielleicht auch ein eigenes *g* -- 102: Code Reuse (cat a.out_header; cat) > a.out (Enno Rehling)
Hallo,
Axel Heinrici
Hallo
On Tuesday 13 January 2004 16:06, David Haller wrote:
Am Tue, 13 Jan 2004, Axel Heinrici schrieb:
Hand aufrufe. Es geht also wirklich _nur_ darum dieses Modul beim booten laden zu lassen.
Versuch mal ein
alias char-major-14 i810_audio
in deiner modules.conf.
Erstmal vorweg, ich habe mich jetzt doch für alsa entschieden. War einfacher als ich dachte und YaST arbeitet auch nciht mehr gegen einen. Der obige Alias hat leider nichts gebracht. Ich würde diese Modul-Geschichte aber gerne noch etwas besser verstehen, um nich jedesmal bei einem ählichen Problem wieder nachfragen zu müssen. Wenn ich mir man 5 modules.conf durchlese, dann steht da ganz oben "...DESCRIPTION The behavior of modprobe(8) (and depmod(8) ) can be modified ... ". Für mich stellt sich da immernoch die Frage: "Welchen Mechanismus soll dieser Alias in Gang setzten? Wann soll dieses Modul denn nun von wem geladen werden?" Für alsa gibt es ja ein Skript in /etc/rc.d/ welches beim Hochfahren ausgeführt wird.
Für Kernelmodule brauchst du kein zusätzliches Startscript. Alle Module in /etc/modules.conf werden bei BEDARF durch den Kernel nachgeladen, nicht zur Bootzeit. Du kannst mit modprobe (oder insmod) Module manuell laden, mit depmod werden die Abhängigkeiten der Module geprüft und in Tabellen unterhalb /lib/modules geschrieben. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
Hallo,
Axel Heinrici
Hi
On Monday 12 January 2004 17:00, Thomas Hertweck wrote:
Lese bitte (bei installierten Kernel-Quellen, aber da Du Deinen Kernel selbst compiliert hast, sind die Quellen ja da) o /usr/src/linux/Documentation/sound/README.OSS o /usr/src/linux/Documentation/sound/README.modules da wirst Du die Antwort auf Deine Frage finden.
Habe ich jetzt nochmal gründlich gemacht. Hatte zuerst aufgrund der angabe "File edited 17.01.1999" bzw. "..information is current as of linux-2.1.85..." nur überflogen. Aber auch erneutes Lesen hilft mir momentan nicht weiter. Da finde ich nur Infos wie ich historische Karten zu konfigurieren habe. Zum einen ist da von nem Intel 810 noch überhaupt keine Rede. Und zum Anderen läuft meine Soundkarte ja, wenn ich modprobe von Hand aufrufe. Es geht also wirklich _nur_ darum dieses Modul beim booten laden zu lassen.
Wenn dein Sound von Hand läuft, dann trage doch einfach die Parameter in /etc/modules.conf ein, fertig. Etwa in der Form alias char-major-14 deinmodul options deinmodul dma=<Wert> dma2=<Wert> io=<port> irq=<Wert> Damit deine Logdateien nicht vollaufen, noch alias char-major-116 off alias-sound-slot-0 off alias-sound-service-0-0 off usw., alle sound-services und sound-slots auf 'off' setzen. -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter(at)dkluenter.de http://www.avci.de
participants (5)
-
Axel Heinrici
-
David Haller
-
Dieter Kluenter
-
Philipp Thomas
-
Thomas Hertweck