hier meine Konfiguration:
1 # SOUND
2 alias sound sb
3 alias char-major-14 sb
4 options sb esstype=0 io=0x220 irq=5 dma=0 dma16=1 &&
/etc/init.d/sound.init start
5 #options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
6 options mpu401 io=0x300
7 options opl3 io=0x388
8 options sound dmabuf=1 # enables DMA-Buffer allocation in
the first 16 MB during first module start
Zeilen 2 und 3 sind identisch, Zeile 4 sagt dem sb-Modul, wie es zu
initialisieren hat und startet (nach dem &&) ein spezielles Skript von
mir, um die Lautstärke etwas flexibler einzustellen, als es der
DLD-Standard vorsieht. Zeile 5 war mal 'nen Test von mir, Zeilen 6 und 7
sagen dem MPU- und dem OPL-Modul, wie sie zu initialisieren haben und
Zeile 8 sorgt für den Buffer! Natürlich kann diese Zeile auch irgendwo
anders stehen, da die Moduleinitinalisierung im Kernel immer das ganze
Skript liest, und sich die Parameter zusammensucht.
> >
> > > Wie kann ich das im Nachhinein kontrollieren, das das Modul auch echt
> > > diesen Parameter geschluckt hat ?
> > > Bei falschen IRQs/DMAs merk ichs, aber bei dem Modul ja nicht.
> > > Oder gibts da nen Trick ?
> > Du kannnst Sachen fragen. Vielleicht steht's im /proc. Eventuell die
> > Sourcen lesen oder ein klog einpatchen, in dem die verwendeten Parameter
> > drinstehen, dann kannst du's mit dmsg oder tail /var/log/messages
> > nachlesen.
NEIN, leider steht es nirgendwo, zumindest habe ich noch keine Stelle
gefunden. Theoretisch steht's natürlich im Kernel-Memory. Aber wenn man
mehr als 64MB Ram hat, dann merkt man nach mehrtägigem Betrieb schnell,
ob's geklappt hat (mein Laptop befindet sich Wochen sozusagen im
"Dauerbetrieb", dank VMware ist ein Neubooten jetzt auch nicht mehr
notwendig).
>
> Jo, das ist nämlich echt nen Problem. Weil wenns nicht klappt, merk ich
> das ja nicht sofort. Ich denk da z.b. an Kunden-Rechner, bei denen ich
> halt ned mal schnell 14 Tage testen kann...deshalb die Frage.
>
> Deshalb mein Vorschlag, das in die DLD 6.2 fest reinzunehmen.
>
Da bin ich ganz und gar dafür, zumal der Sound ja eh diesen Buffer haben
will, also kein zusätzlicher Speicher dadurch reserviert wird. Um Geräte
mit mehr als 64MB werden langsam zum Normalfall.
> > > Ist mir bekannt.
> > > Deshalb hab ich ja nach einer besseren Lösung gefragt.
> > > Trotzdem versuch ich halt, erst selber ne Lösung zu finden, und dann
> > > erst in die Liste zu gehen...
> > > (IMHO kann ich nicht unbedingt schlechtes dabei finden, wenn man im
> > > Startup-Script "sound" auch wirklich den Sound lädt...dazu ist das
> > > Script doch schließlich da, hihi)
> > Nee, dazu ist der module-daemon da. Wenn Du module haendisch mit
> > modprobe laedst, weiss der kmod nicht, ob er das modul wieder entsorgen
> > darf und deshalb bleibt es bis zum haendischen rmmod drin. Wenn Du einfach
> > auf eines der sound-devices zugreifst, poppen die Module von alleine in
> > den Kernel und verschwinden irgendwann dann auch wieder.
>
> Das ist nen Argument, wußte ich ned, das der dann die Module nimmer
> entsorgt.
> (Ok, bei Sound entsorgt er eh nie, da ja KDE dauernd rumsoundet)
> Aber bei andren Sachen sicher ein Argument.
>
Na ja, kein ganz richtiges Argument mehr. Seit Kernel 2.2.x ist der
Kernel-Daemon überflüssig, da der Kernel ja nun selbst gelernt hat, wie
man Module lädt (siehe auch /proc/sys/kernel/*). Seit dem kann er aber
das Entladen nicht mehr richtig. In den Kernelsourcen schlägt man 'nen
Cron-Job vor, der die Module, die gerade nicht gebraucht werden,
entlädt. Fehlt auch in der DLD, z.B in /etc/crontab:
# remove unused modules frequently
5,10,15,20,25,30,35,40,45,50,55,0 * * * * root /sbin/rmmod -a
> Solong..
> mfg Frank.
>
> --
> Frank Schneider, <SPATZ1@T-ONLINE.DE>.
> -Linux, because: Who needs Gates in a fenceless World ??
> ... -.-
Mit freundlichen Grüßen/Sincerely
Joachim von Thadden
"Never run a touching system!"
-------------------------------------------------------------------
Call-a-Server LINUX-Systempartner
Netzwerkbetreuung . Sicherheitskonzepte . Softwareerstellung
www.call-a-server.de fax (030) 801 74 23
thadden@call-a-server.de phone (0177) 717 08 96