  Linux BootPrompt HOWTO
  Paul Gortmaker (p_gortmaker@yahoo.com) und Marco Budde
  (Budde@tu-harburg.de)
  v1.2, 20. Mrz 2000

  Dies ist das BootPrompt HOWTO, welches eine Zusammenstellung aller
  mglichen Bootparameter enthlt, die whrend des Bootvorgangs an den
  Linux-Kernel geschickt werden knnen. Hierbei sind alle Kernel- und
  Gerteparameter eingeschlossen. Es wird diskutiert, wie der Kernel
  Bootparameter sortiert und man erhlt einen berblick ber die bekan
  nteste Software, die zum Booten von Linux-Kerneln verwendet wird.


  1.  Einfhrung


  Der Kernel verfgt ber eine begrenzte Fhigkeit, whrend des
  Bootvorgangs Informationen in Form einer Kommandozeile anzunehmen,
  hnlich einer Parameterliste, die man einem Programm bergeben wrde.
  Dies dient im allgemeinen dazu, den Kernel mit Informationen ber
  Hardwareparameter zu versorgen, die der Kernel alleine nicht bestimmen
  knnte oder die Werte zu vermeiden/bergehen, die der Kernel
  anderenfalls erkennen wrde.

  Will man jedoch lediglich ein Kernelimage direkt auf Diskette kopieren
  (z.B. cp zImage /dev/fd0), dann erhlt man nicht die Mglichkeit,
  einen Parameter fr diesen Kernel festzulegen.  Deshalb werden die
  meisten Linux-Anwender Software wie LILO oder loadlin verwenden, die
  diese Parameter an den Kernel weiterleitet und ihn anschlieend
  bootet.

  Die derzeitige Ausgabe dieses Textes behandelt Kernel bis
  einschlielich Version 2.2.9. Es werden ebenfalls einige Eigenschaften
  dokumentiert, die ausschlielich bei den Entwicklerversionen des
  Kernels (bis Version 2.3.2) vorkommen.



  1.1.

  Ablehnungshinweise und Copyright


  Dieses Dokument ist kein Evangelium. Es bietet jedoch mglicherweise
  die aktuellste Information, die man finden kann.  Jeder ist selbst
  dafr verantwortlich, was mit der eigenen Hardware geschieht. Falls
  die Hardware in Rauch und Flammen aufgeht, was eigentlich unmglich
  ist, bernehme ich dafr keine Verantwortung.

  Falls Sie beabsichtigen, dieses Dokument in eine Verffentlichung
  aufzunehmen, nehmen Sie bitte Kontakt mit mir auf. Ich werde dann mein
  Mglichstes tun, Ihnen die aktuellsten Informationen zur Verfgung zu
  stellen. In der Vergangenheit wurden lngst berholte Versionen der
  Linux-HOWTO-Dokumente verffentlicht, was den Entwicklern stndigen
  Kummer bereitete, da sie mit Fragen geqult wurden, die in den neueren
  Versionen bereits beantwortet waren.


  Dieses Dokument ist urheberrechtlich geschtzt. Das Copyright fr die
  englische BootPrompt HOWTO, auf der dieses Dokument basiert, liegt bei
  Paul Gortmaker. Das Copyright fr die deutsche Version liegt bei
  Caldera GmbH (Antje Faber) und Marco Budde.


  Das Dokument darf gem der GNU General Public License verbreitet
  werden. Insbesondere bedeutet dies, da der Text sowohl ber
  elektronische wie auch physikalische Medien ohne die Zahlung von
  Lizenzgebhren verbreitet werden darf, solange dieser Copyright-
  Hinweis nicht entfernt wird. Eine kommerzielle Verbreitung ist erlaubt
  und ausdrcklich erwnscht. Bei einer Publikation in Papierform ist
  das Deutsche Linux HOWTO Projekt hierber zu informieren.



  1.2.  Fr wen ist dieses Dokument gedacht?

  Die meisten Anwender werden dieses Dokument nicht bentigen, da Linux
  seine Aufgabe, die vorhandene Hardware zu erkennen und passende
  Standardwerte fr die meisten Parameter auszuwhlen, sehr gut
  erledigt. Gedacht ist diese HOWTO fr diejenigen Anwender, die
  eventuell einige Standardeinstellung ndern mchten, um den Kernel fr
  den jeweiligen Rechner zu optimieren. Auch Anwender, die sich selbst
  einen eigenen Kernel gebacken haben, um Untersttzung fr eine nicht
  so weit verbreitete Hardware hinzuzufgen, bei der eine automatische
  Erkennung noch nicht funktioniert, sollten diesen Text gelesen haben.

  Wichtiger Hinweis fr die Verwendung von Modulen: Ein Kennzeichen von
  Bootprompt-Parametern ist die ausschlieliche Anwendung auf Hardware-
  Treiber, die direkt in den Kernel einkompiliert sind. Sie haben keine
  Auswirkung auf Treiber, die als Module geladen werden. Die meisten
  Distributionen verwenden Module. Sollten Zweifel bestehen, sollte man
  man depmod und man modprobe zusammen mit /etc/conf.modules anschauen.



  1.3.


  Weitere Dokumentationen


  Die aktuellsten Dokumentationen werden immer die Kernel-Quelldateien
  selbst sein. Aber keine Angst, man bentigt keine
  Programmierkenntnisse zum Lesen der Anmerkungen in den Quelldateien.
  Will man zum Beispiel wissen, welche Parameter vom AHA1542 SCSI-
  Treiber erkannt werden, dann geht man ins Verzeichnis
  linux/drivers/scsi und wirft einen Blick auf die Datei aha1542.c. Dort
  findet man bereits in den ersten 100 Zeilen eine einfache Beschreibung
  (auf Englisch) der Bootparameter, die der 1542-Treiber erkennt.

  Das Verzeichnis linux findet sich normalerweise unter /usr/src/. Bei
  allen Verweisen auf andere Dateien in diesem Dokument, die Bestandteil
  der Kernel Sourcen sind, wird deren kompletter Pfadname mit linux/
  abgekrzt. Um den kompletten Pfad zu erhalten, mu /usr/src oder was
  fr das jeweilige System passend ist am Anfang hinzugefgt werden.
  Falls Sie eine Datei garnicht finden knnen, machen Sie von den
  Befehlen find und locate Gebrauch.

  Die nchstbeste Informationsquelle sind die Dokumentationsdateien, die
  mit dem Kernel selbst ausgeliefert werden. Es gibt bereits einige
  davon und die meisten knnen im Verzeichnis linux/Documentation und
  seinen Unterverzeichnissen gefunden werden. Es existieren einige
  README.foo-Dateien, die sich in dem jeweiligen Treiber-Verzeichnis
  befinden (z.B. linux/drivers/XXX/, wobei XXX scsi, char oder net ist).

  Hat man sich fr bestimmte Bootparameter entschieden und will nun
  herausfinden, wie man die Information an den Kernel weitergibt, sollte
  man einen Blick auf die Dokumentation der Software, wie z.B. LILO oder
  loadlin werfen, die zum Booten des Kernels verwendet wird. Nachfolgend
  wird ein kurzer berblick gegeben, der jedoch keinen Ersatz fr die
  mit der Bootsoftware ausgelieferte Dokumentation darstellt.



  1.4.

  Linux Newsgruppen


  Bei Fragen ber die Weitergabe von Bootparametern an den Kernel sollte
  zuerst dieses Dokument gelesen werden.  Falls dieses Dokument und die
  oben genannte Dokumentation die Fragen nicht klren knnen, dann kann
  man sich an die Linux-Newsgruppen wenden.

  Allgemeine Fragen ber die Systemkonfiguration sollte man an die
  Newsgruppe


       de.comp.os.unix.linux.misc


  richten. Wir bitten darum, sich an die allgemeinen Richtlinien zu
  halten und vor allem eine Frage nicht gleichzeitig in mehreren Gruppen
  zu stellen.

  Natrlich sollte man zuerst die lteren Artikel der Newsgruppe lesen,
  anstatt blindlings eine Frage zu stellen. Es ist nmlich gut mglich,
  da dieselbe Frage bereits gestellt wurde oder mglicherweise sogar zu
  den Frequently Asked Questions (hufig gestellte Fragen) gehrt.  Ein
  schneller Blick auf die Linux-FAQs ist eine gute Idee.  Die FAQ sollte
  man in der Nhe der Ursprungsseite dieses Dokuments finden.



  2.

  bersicht ber die BootPrompt-Parameter


  In diesem Abschnitt werden einige Programme vorgestellt, die zur
  Weiterleitung von Kernel-Bootparametern zum Kernel selbst verwendet
  werden knnen. Es wird ebenfalls erklrt, wie die Parameter
  verarbeitet werden, welchen Beschrnkungen sie unterliegen und wie sie
  zu jedem passenden Gert, fr das sie bestimmt sind, weitergeleitet
  werden.

  Man sollte unbedingt beachten, da innerhalb eines Bootparameters
  keine Leerstellen verwendet werden sollten, nur zwischen getrennten
  Parametern. Mehrere Werte fr einen Parameter mssen durch ein Komma
  getrennt werden und zwar wiederum ohne Leerstellen. Richtig wre z.B.
  dieses Beispiel:



       ether=9,0x300,0xd0000,0xd4000,eth0  root=/dev/hda1




  Nachfolgendes Beispiel ist hingegen falsch:



       ether = 9, 0x300, 0xd0000, 0xd4000, eth0  root = /dev/hda1


  Sobald der Kernel erst einmal luft, kann man jederzeit mit dem Befehl



       cat /proc/cmdline




  nachschauen, welche Parameter an den Kernel bergeben wurden.



  2.1.


  LILO (LInux LOader)


  LILO (LInux LOader) von Werner Almesberger ist das am hufigsten
  verwendete Programm zur bergabe der Parameter.  Das Programm hat die
  Fhigkeit, verschiedene Kernel bzw.  Betriebssysteme zu booten. Die
  meisten Distributionen verwenden standardmig LILO, um Linux und z.B.
  auch Windows zu starten. LILO kann DOS, Windows, OS/2, Linux, FreeBSD,
  etc. ohne Schwierigkeiten booten und ist zudem uerst flexibel.

  Nach dem Einschalten des Computers wird bei den meisten Installationen
  LILO gestartet. Drckt der Anwender nach der Meldung LILO die TAB-
  Taste, so gelangt er zum Prompt von LILO. Ansonsten wird nach eine
  festgelegten Zeit automatisch das Standardsystem gestartet. In der
  Regel wird hier durch die Eingabe eines label-Eintrages aus
  /etc/lilo.conf das zu startende Betriebssystem bzw. Linux Kernel
  ausgewhlt.  Typisch sind Labels wie linux, backup und msdos.  Falls
  ein Bootparameter an den Kernel bergeben werden soll, kann man dies
  an dieser Stelle tun. Der Parameter wird einfach, durch ein
  Leerzeichen getrennt, an das Label angehngt.  Folgendes Beispiel soll
  dies verdeutlichen:



       LILO: linux root=/dev/hda1




  In der Regel mchte man natrlich nicht bei jedem Booten die Parameter
  per Hand eingeben mssen. Hier hilft die Option append=, die der
  Konfigurationsdatei von LILO hinzugefgt werden kann und deren
  Parameter dann automatisch an den Kernel bergeben werden. Man mu
  einfach nur etwas wie



       append = "foo=bar"




  in die Datei /etc/lilo.conf einfgen. Dieses kann entweder am Anfang
  der Datei eingefgt werden, so da die Parameter fr alle Abschnitte
  der Datei gltig sind, oder in den Abschnitt eines bestimmten Kernels,
  so da nur diesem die Parameter bergeben werden. Eine ausfhrliche
  Beschreibung ist in der ausgezeichneten Dokumentation von LILO zu
  finden.


  2.2.


  loadlin


  Ein anderer weitverbreiteter Linux-Loader ist loadlin. Dies ist ein
  DOS-Programm, das die Fhigkeit besitzt, einen Linux-Kernel vom DOS-
  Prompt aus zu starten, wobei Bootparameter bergeben werden knnen.

  Sehr ntzlich ist die Mglichkeit, Linux von DOS aus zu starten, wenn
  man bestimmte Hardware besitzt, die von Linux erst dann untersttzt
  wird, wenn sie von dem der Hardware beiliegenden DOS-Treiber in einen
  bestimmten Zustand versetzt worden ist.  Ein gutes Beispiel sind die
  Soundblaster-kompatiblen Soundkarten, welche den DOS-Treiber
  bentigen, um ein paar geheimnisvolle Register ziehen zu knnen, um
  die Karte in einen SB-kompatiblen Modus zu bringen. Das Booten von DOS
  mit dem zur Verfgung stehenden Treiber und das anschlieende Laden
  von Linux mit LOADLIN.EXE vom DOS-Prompt aus verhindert das
  Zurckschalten der Karte in den vorherigen Zustand, was beim erneuten
  Booten der Fall wre. So jedoch bleibt die Karte in einem SB-
  kompatiblen Modus und ist somit unter Linux verwendbar.  Auch
  Plug&Play Hardware kann auf diese Art und Weise initialisiert werden.

  Es gibt auch noch andere Programme, die zum Booten von Linux verwendet
  werden knnen. Auf dem lokalen Linux-FTP-Server erhlt man unter
  system/Linux-boot/ die komplette Liste aller verfgbaren Programme.



  2.3.




  Das Hilfsprogramm rdev


  Es gibt einige Kernel-Bootparameter, deren Standardwerte an bestimmten
  Stellen im Kernel-Image selbst gespeichert sind. Es gibt ein
  Hilfsprogramm namens rdev, das auf den meisten Systemen installiert
  ist und das wei, wo sich diese Werte befinden und wie sie gendert
  werden knnen. Dieses Hilfsprogramm kann auch Dinge ndern, die kein
  Kernel-Bootparameter-quivalent besitzen, wie z.B. der standardmig
  verwendete Grafik-Modus.

  Das Hilfsprogramm rdev ist gewhnlich auch unter den Namen swapdev,
  ramsize, vidmode und rootflags aufrufbar. Diese Namen zeigen die fnf
  nderungsmglichkeiten durch rdev an: das Root-Device, das Swap-
  Device, die RAM-Disk-Parameter, der Standard-Grafik-Modus sowie die
  readonly/readwrite-Einstellung vom Root-Device.

  Weitere Informationen ber rdev erhlt man nach Eingabe von rdev -h
  oder durch die Lektre der bereitgestellten Manpage (man rdev).



  2.4.  Sortierung der Parameter durch den Kernel


  Die meisten Bootparameter sind folgendermaen strukturiert:



       name[=wert_1][,wert_2]...[,wert_11]

  name ist hierbei ein einzigartiges Schlsselwort, das Aufschlu
  darber gibt, fr welchen Teil des Kernels die entsprechenden Werte
  bestimmt sind.  Mehrere Bootparameter werden als Liste nach obigem
  Format an den Kernel bergeben, wobei die einzelnen Parameter durch
  Leerzeichen getrennt werden.  Man beachte das tatschliche Limit von
  11 Parametern. Der bestehende Code kann nur 11 durch Kommas getrennte
  Parameter pro Schlsselwort verarbeiten. In ungewhnlich komplizierten
  Fllen kann man jedoch dasselbe Schlsselwort mit 11 zustzlichen
  Parametern erneut benutzen, vorausgesetzt, die Setup-Funktion
  untersttzt dies. Man beachte auch, da der Kernel die Liste in
  maximal zehn Ganzzahlen-Parameter und eine anschlieende Zeichenfolge
  unterteilt. Das heit, man kann nicht wirklich 11 Ganzzahlen
  bereitstellen; dies ist hchstens durch Konvertierung des 11ten
  Parameters von einer Zeichenkette in eine Ganzzahl im Treiber selbst
  mglich.

  Die Sortierung findet hauptschlich in linux/init/main.c statt. Zuerst
  berprft der Kernel, ob der Parameter zu einem der speziellen
  Parameter wie root=, ro, rw oder debug gehrt. Die Bedeutung dieser
  speziellen Parameter wird im weiteren Verlauf dieser Dokumentation
  beschrieben.

  Der Kernel durchsucht dann eine Liste von Setup-Funktionen, die im
  bootsetups-Array gespeichert ist, um zu sehen, ob ein Treiber oder ein
  Teil des Kernels fr die entsprechende Zeichenkette, wie z.B. foo,
  eine Setup-Funktion setup_foo() registriert hat. Wrde man dem Kernel
  die Zeile foo=3,4,5,6,bar bergeben, dann wrde dieser den bootsetups-
  Array durchgehen, um herauszufinden, ob foo registriert ist. Falls
  dies der Fall wre, wrde der Kernel die Setup-Funktion, die mit foo
  verbunden ist, aufrufen und dieser die Ganzzahlen-Parameter 3, 4, 5
  und 6 bergeben, wie sie auf der Kernel-Kommandozeile angegeben
  wurden. Auerdem wrde er ebenfalls die Zeichenkette bar bergeben.



  2.5.

  Umgebungsvariablen setzen


  Alles, was aussieht wie foo=bar und nicht als Setup-Funktion
  akzeptiert wird, wie oben beschrieben, wird dann als zu setzende
  Umgebungsvariable interpretiert. Ein Beispiel wre die Verwendung von
  TERM=vt100 oder BOOT_IMAGE=vmlinuz.bak als Bootparameter.  Diese
  Umgebungsvariablen werden typischerweise in Initialisierungsskripts
  abgefragt, um ein groe Anzahl von verschiedenen Dingen ein- oder
  auszuschalten.



  2.6.


  Weitergabe von Parametern zum init-Programm


  Alle verbleibenden Parameter, die der Kernel nicht selbst verwendet
  und nicht als Umgebungsvariablen interpretiert, werden zum ersten
  Proze weitergeleitet. Dieser ist normalerweise das init-Programm.
  Meistens wird dem init-Programm per Bootparameter mitgeteilt, mit
  welchem Runlevel Linux gebootet werden soll. So kann init angewiesen
  werden, den Rechner im Ein-Benutzer-Modus zu booten und die blichen
  Dmonen nicht zu starten. Um herauszufinden, welche Parameter von der
  auf Ihrem System installierten Version von init akzeptiert werden,
  lesen Sie bitte die entsprechende Manual Page.

  3.

  Allgemeine, gerteunabhngige Bootparameter


  Hierbei handelt es sich um Bootparameter, die mit keinem speziellen
  Hardware-Treiber verknpft sind. Statt dessen beeinflussen sie einige
  bestimmte intere Kernel-Parameter wie z.B. den Umgang mit dem
  Speicher, mit der RAM-Disk, dem Root-Dateisystem und anderen.



  3.1.  Root-Dateisystem Optionen


  Folgende Optionen beziehen sich alle auf das Vorgehen des Kernels bei
  der Auswahl und dem Umgang mit dem Root-Dateisystem.



  3.1.1.  Der Parameter root=


  Dieser Parameter teilt dem Kernel mit, welches Device beim Booten als
  Root-Dateisystem benutzt werden soll. Als Standardeinstellung benutzt
  der Kernel das Device, das auf dem System, auf dem der Kernel erzeugt
  wurde, das Root-Dateisystem enthielt. Wurde der fragliche Kernel z.B.
  auf einem System kompiliert, das /dev/hda1 als Root-Partition
  verwendete, dann geht der Kernel davon aus, da sich das Root-
  Dateisystem auf /dev/hda1 befindet. Will man diesen Standardwert auer
  Kraft setzen und z.B. das zweite Diskettenlaufwerk als Root-Device
  verwenden, wrde man root=/dev/fd1 whlen.

  Gltige Root-Devices sind:


    /dev/hdaN bis /dev/hddN: Partition N auf der ST-506-kompatiblen
     (IDE) Festplatte a bis d

    /dev/sdaN bis /dev/sdeN: Partition N auf der SCSI-kompatiblen
     Festplatte a bis e

    /dev/xdaN bis /dev/xdbN: Partition N auf der XT-kompatiblen
     Festplatte a bis b

    /dev/fdN: Diskettenlaufwerk mit der Nummer N.  N=0 wre das DOS-
     Laufwerk A: und N=1 wre B:.

    /dev/nfs: Dieses ist nicht wirklich ein Device, sondern teilt dem
     Kernel lediglich mit, da das Root-Dateisystem ber das Netzwerk
     geholt werden soll.

  Die schwierigere und weniger portable numerische Bestimmung der oben
  genannten, mglichen Devices fr Festplatten im Major-/Minor-Format
  wird auch akzeptiert. So entspricht z.B.  Major 8, Minor 3 der
  Partition /dev/sda3, so da man alternativ root=0x803 verwenden
  knnte.

  Dies ist einer der wenigen Kernel-Bootparameter, dessen Standard im
  Kernelimage gespeichert ist, und welcher deshalb mit dem Hilfsprogramm
  rdev gendert werden kann.





  3.1.2.  Der Parameter ro


  Wenn der Kernel bootet, wird dabei ein Root-Dateisystem bentigt, um
  grundlegende Dinge davon abzulesen. Dies ist das Root-Dateisystem, das
  beim Booten gemountet wird. Wird das Root-Dateisystem jedoch mit
  Schreibrecht gemountet, kann keine verlliche berprfung der
  Integritt des Dateisystems vorgenommen werden, weil z.B. gleichzeitig
  ein anderer Proze eine Datei bearbeitet und damit das zu prfende
  Dateisystem verndert. Mit der Option ro wird der Kernel aufgefordert,
  das Root-Dateisystem nur mit Leserecht (engl. readonly) zu mounten, so
  da Programme zur Konsistenzprfung des Dateisystems (fsck) mit
  Sicherheit annehmen knnen, da keinerlei halb geschriebene Dateien
  existieren, whrend die berprfung stattfindet. Kein Programm oder
  Proze kann Dateien des fraglichen Dateisystems verndern, bis es
  nicht mit Lese-/Schreibrecht wieder gemountet ist.

  Auch diese Einstellung ist im Kernelimage gespeichert und kann deshalb
  mit dem Programm rdev verndert werden.



  3.1.3.  Der Paramater rw


  Dieser Parameter ist das exakte Gegenteil vom eben Genannten.  Hier
  wird der Kernel nmlich aufgefordert, das Root-Dateisystem mit
  Lese-/Schreibrecht zu mounten. Die Standardeinstellung ist sowieso das
  Mounten des Root-Dateisystems mit Lese-/Schreibrecht. Man sollte auf
  keinen Fall Programme vom Typ fsck auf einem Dateisystem laufen
  lassen, das mit Lese-/Schreibrecht gemountet wurde.

  Der bereits oben erwhnte, in der Image-Datei gespeicherte Wert ist
  der gleiche, der auch fr diesen Parameter verwendet wird. Der Zugriff
  darauf erfolgt ber rdev.



  3.2.

  Optionen der RAM-Disk-Verwaltung


  Folgende Optionen beziehen sich alle auf den Umgang des Kernels mit
  dem RAM-Disk-Device. Eine RAM-Disk wird hauptschlich whrend der
  Installation einer Linux Distribution verwendet.  Auerdem ist die
  RAM-Disk auch sehr ntzlich, wenn der Kernel fr den Zugriff auf das
  Root-Dateisystem zuerst Treiber laden mu, die als Modul kompiliert
  worden sind.



  3.2.1.  Das Kommando ramdisk_start=

  Damit ein Kernel-Image zusammen mit dem komprimierten Image einer RAM-
  Disk auf einer Diskette gespeichert werden kann, existiert der
  Parameter ramdisk_start=<offset>.  Der Kernel kann nicht in das
  komprimierte Image des RAM-Disk Dateisystems aufgenommen werden, weil
  der Kernel beginnend mit Block Null auf der Diskette gespeichert
  werden mu, so da das BIOS den Bootsektor laden kann. Dann kann der
  Kernel sich selbst erstmalig booten und damit zum Laufen bringen.

  Benutzt man ein unkomprimiertes Image einer RAM-Disk, dann kann der
  Kernel Teil dieses Images sein, das in die RAM-Disk geladen wird. Die
  Diskette kann mit LILO gebootet werden. Die beiden knnen auch
  getrennt sein wie bei den komprimierten Images.
  Verwendet man zwei Disketten, wobei sich auf der ersten der Kernel und
  auf der zweiten das Image einer RAM-Disk befindet, dann startet die
  RAM-Disk bei Block Null und es wird ein Offset von Null verwendet. Da
  dies der Standardwert ist, braucht man das Kommando in Wirklichkeit
  gar nicht benutzen.


  3.2.2.  Das Kommando load_ramdisk=


  Dieser Parameter teilt dem Kernel mit, ob ein Image einer RAM-Disk
  geladen werden soll oder nicht. Durch die Angabe von load_ramdisk=1
  wird der Kernel veranlat, eine Diskette in die RAM-Disk zu laden. Der
  Standardwert ist Null, was bedeutet, da der Kernel nicht versuchen
  soll, eine RAM-Disk zu laden.

  Eine komplette Beschreibung der neuen Bootparameter und deren
  Verwendung findet man in der Datei linux/Documentation/ramdisk.txt. Es
  wird auch beschrieben, wie dieser Parameter mit rdev im Kernel-Image
  gespeichert werden kann.


  3.2.3.  Das Kommando prompt_ramdisk=


  Dieser Parameter teilt dem Kernel mit, ob der Anwender aufgefordert
  werden soll, die Diskette mit dem Image der RAM-Disk einzulegen. Bei
  einer Konfiguration mit einer Diskette befindet sich das Image der
  RAM-Disk auf der gleichen Diskette wie der Kernel, der gerade den
  Lade-/Bootvorgang beendet hat. Somit wird eine Nachfrage nicht
  bentigt. In diesem Fall kann man prompt_ramdisk=0 verwenden. Bei
  einer Konfiguration mit zwei Disketten wird man die Mglichkeit des
  Diskettentauschs bentigen. Somit kann prompt_ramdisk=1 verwendet
  werden. Da dies der Standardwert ist, mu er eigentlich nicht
  angegeben werden. Frher haben raffinierte Anwender die Option vga=ask
  von LILO verwendet, um den Bootproze zeitweilig zu stoppen und ein
  Wechsel von der Boot- zur Rootdiskette zu ermglichen.

  Eine komplette Beschreibung der neuen Bootparameter und deren
  Benutzung findet man in der Datei linux/Documentation/ramdisk.txt Es
  wird auch beschrieben, wie dieser Parameter bestimmt und via rdev im
  Kernel-Image gespeichert werden kann.


  3.2.4.  Das Kommando ramdisk_size=


  Zwar stimmt es, da die RAM-Disk je nach Bedarf dynamisch wchst,
  jedoch gibt es eine Obergrenze fr ihre Gre, so da nicht der
  gesamte Speicher verbraucht wird und es zu Problemen kommt. Der
  Standardwert ist 4096 (4 MB), was den meisten Ansprchen gengen
  sollte. Mit diesem Bootparameter kann man den Standardwert verringern
  oder vergrern.

  Eine komplette Beschreibung der neuen Bootparameter und deren
  Benutzung findet man in der Datei linux/Documentation/ramdisk.txt Es
  wird auch beschrieben, wie dieser Parameter bestimmt und via rdev im
  Kernel-Image gespeichert werden kann.


  3.2.5.  Das Kommando ramdisk= (veraltet)


  Dieser Parameter ist veraltet und sollte nicht verwendet werden, es
  sei denn fr die Kernelversion v1.3.47 oder ltere.  Die Parameter,
  die heute fr das RAM-Disk-Device verwendet werden sollten, sind oben
  beschrieben.

  Mit dem Parameter wird die Gre RAM-Disk-Devices in KByte angeben.
  Wrde man z.B. ein Root-Dateisystem auf einer 1,44 MB Diskette in ein
  RAM-Disk-Device laden wollen, wrde man folgendes Kommando verwenden:



       ramdisk=1440




  Dies ist einer der wenigen Kernel-Bootparameter, dessen Standardwert
  im Kernel-Image gespeichert ist und der somit mit dem Hilfsprogramm
  rdev verndert werden kann.



  3.2.6.  Das Kommando noinitrd


  Kernel v2.x und neuere verfgen ber ein Feature, bei dem das Root-
  Dateisystem anfangs eine RAM-Disk sein kann und der Kernel auf diesem
  RAM-Image /linuxrc ausfhrt. Dieses Feature wird typischerweise dazu
  verwendet, das Laden von Modulen zu ermglichen, die zum Mounten des
  eigentlichen Root-Dateisystems bentigt werden. So knnen z.B. die
  Module des SCSI-Treibers von dem Image der RAM-Disk geladen werden und
  anschlieend wird das eigentliche Root-Dateisystem auf einer SCSI-
  Festplatte gemountet.

  Der eigentliche noinitrd-Parameter bestimmt, was mit den initrd-Daten
  passiert, nachdem der Kernel gebootet wurde. Wenn dieser Parameter
  gesetzt wird, werden die Daten nicht auf eine RAM-Disk konvertiert,
  sondern es kann auf diese Daten unter /dev/initrd zugegriffen werden.
  Dieser Zugriff ist nur einmal mglich, bevor der Speicher an das
  System zurckgegeben wird. Umfassende Informationen ber die Benutzung
  der initial RAM-Disk erhlt man unter linux/Documentation/initrd.txt.
  Zustzlich sollten die neuesten Versionen von LILO und loadlin weitere
  ntzliche Informationen enthalten.



  3.3.

  Bootparameter fr den Umgang mit dem Speicher


  Folgende Parameter ndern sich je nachdem, wie Linux den
  physikalischen oder virtuellen Systemspeicher erkennt oder mit ihm
  umgeht.



  3.3.1.  Der Parameter mem=


  Dieser Parameter dient zwei verschiedenen Zwecken: Der ursprngliche
  Zweck war, die Gre des installierten Speichers oder einen kleineren
  Wert, falls man die Gre des fr Linux verfgbaren Speichers
  verringern wollte, zu spezifizieren.  Der andere, kaum verwendete
  Zweck ist die Bestimmung von mem=nopentium, was den Linux-Kernel
  auffordert, das 4 MB Seitentabellen-Performance-Feature nicht zu
  verwenden.


  Whrend des Bootvorganges ermittelt Linux durch einen BIOS-Aufruf die
  Gre des installierten Speichers. Leider ist die Gre, die dieser
  Aufruf zurckliefern kann, auf 64 MB begrenzt. Erinnert uns das
  irgendwie an das 1024 Zylinder Limit von IDE-Festplatten?  Sind mehr
  als 64 MB RAM installiert, kann man Linux mit diesem Bootparameter
  mitteilen, wieviel Speicherplatz vorhanden ist. Hier ein Zitat von
  Linus ber die Verwendung des mem= Parameters:


       Der Kernel wird alle mem=xx Parameter akzeptieren, die man
       ihm bergibt. Falls sich allerdings herausstellt, da man
       gelogen hat, wird der Kernel frher oder spter schrecklich
       abstrzen. Der Parameter legt die hchste ansprechbare RAM-
       Adresse fest, so da z.B. mem=0x1000000 bedeutet, da man
       16 MB Speicher besitzt. Fr einen Rechner mit 96 MB wre der
       Bootparameter mem=0x6000000.  Teilt man Linux mit, da es
       ber mehr als den tatschlich vorhandenen Speicherplatz
       verfgt, dann wird dies schlimme Folgen haben; vielleicht
       nicht sofort, aber irgendwann mit Sicherheit.


  Man beachte, da der bergebene Wert keine Hexadezimalzahl sein mu
  und da die Endungen k bzw. M zur Bestimmung von Kilobytes bzw.
  Megabytes verwendet werden knnen, wobei Gro- oder Kleinschreibung
  keine Rolle spielen.  k verursacht eine Verschiebung des Wertes um
  10 Bit, whrend M eine Verschiebung um 20 Bit bewirkt. Fr einen
  Rechner mit z.B. 128 MB RAM wrde man mem=128m verwenden.



  3.3.2.  Der Parameter swap=


  Hier wird dem Anwender die Feineinstellung eines Teils der virtuellen
  Speicherparameter ermglicht, die mit Diskswapping zu tun haben.
  Folgende acht Parameter werden akzeptiert:



       MAX_PAGE_AGE
       PAGE_ADVANCE
       PAGE_DECLINE
       PAGE_INITIAL_AGE
       AGE_CLUSTER_FRACT
       AGE_CLUSTER_MIN
       PAGEOUT_WEIGHT
       BUFFEROUT_WEIGHT




  Interessierten Hackern sei die Lektre von linux/mm/swap.c empfohlen.
  Auch sollten sie einen Blick in /proc/sys/vm werfen. Das Kernel
  enthlt ntzliche Dokumentationen zu diesem Thema im Verzeichnis
  linux/Documentation/vm/.



  3.3.3.  Der Parameter buff=



  hnlich dem swap=-Parameter wird dem Anwender die Feineinstellung
  einiger der Parameter fr die Buffer-Speicherverwaltung ermglicht.
  Folgende sechs Parameter werden akzeptiert:

       MAX_BUFF_AGE
       BUFF_ADVANCE
       BUFF_DECLINE
       BUFF_INITIAL_AGE
       BUFFEROUT_WEIGHT
       BUFFERMEM_GRACE




  Interessierten Hackern sei die Lektre von linux/mm/swap.c empfohlen.
  Auch sollten sie einen Blick in /proc/sys/vm werfen. Das Kernel
  enthlt ntzliche Dokumentationen zu diesem Thema im Verzeichnis
  linux/Documentation/vm/.



  3.4.


  Bootparameter fr das NFS-Root-Dateisystem


  Linux untersttzt Systeme wie laufwerkslose Workstations, die ihr
  Root-Dateisystem per NFS (Network FileSystem) beziehen.  Diese
  Parameter werden dazu verwendet, der laufwerkslosen Workstation
  mitzuteilen, von welchem Rechner sie ihr System erhlt. Man beachte,
  da der Parameter root=/dev/nfs bentigt wird. Detaillierte
  Informationen ber die Verwendung eines NFS-Root-Dateisystems findet
  man in der Datei linux/Documentation/nfsroot.txt. Es wird empfohlen,
  diese Datei zu lesen, da folgende Informationen lediglich aus einer
  Zusammenfassung dieser Datei bestehen.


  3.4.1.  Der Parameter nfsroot=


  Dieser Parameter teilt dem Kernel mit, welcher Rechner, welches
  Verzeichnis und welche NFS-Optionen fr das Root-Dateisystem verwendet
  werden sollen. Der Parameter ist folgendermaen aufgebaut:



       nfsroot=[<server-ip>:]<root-verz>[,<nfs-optionen>]




  Wird der nfsroot-Parameter nicht auf der Kommandozeile angegeben, dann
  wird standardmig /tftpboot/%s verwendet. Andere mgliche Optionen
  sind:


     <server-ip>
        Bestimmt die IP-Adresse des NFS-Servers. Fehlt dieses Feld, dann
        wird die von der nfsaddrs-Variablen (siehe unten) bestimmte
        Default-Adresse verwendet. Dieser Parameter wird z.B. dazu
        verwendet, die Benutzung mehrerer Server fr RARP und NFS zu
        ermglichen. Normalerweise kann dieses Feld leer bleiben.


     <root-verz>
        Name des Verzeichnisses auf dem Server, das als root gemountet
        werden mu. Ist in der Zeichenkette ein %s-Token enthalten, dann
        wird der Token durch die ASCII-Darstellung der IP-Adresse des
        Clients ersetzt.
     <nfs-optionen>
        Standard-NFS-Optionen. Alle Optionen sind durch Kommas getrennt.
        Fehlt das Optionen-Feld, werden folgende Standardwerte
        verwendet:



          port            = wie vom Portmap-Daemon angegeben
          rsize           = 1024
          wsize           = 1024
          timeo           = 7
          retrans         = 3
          acregmin        = 3
          acregmax        = 60
          acdirmin        = 30
          acdirmax        = 60
          flags           = hard, nointr, noposix, cto, ac







  3.4.2.  Der Parameter nfsaddrs=


  Dieser Bootparameter bestimmt die verschiedenen Adressen der
  Netzwerkschnittstellen, die zur Kommunikation ber's Netzwerk bentigt
  werden. Wird dieser Parameter nicht angegeben, dann versucht der
  Kernel unter Verwendung von RARP und/oder BOOTP, diese Parameter
  herauszufinden. Der Syntax sieht folgendermaen aus:



       nfsaddrs=<meine-ip>:<serv-ip>:<gw-ip>:<netmask>:<name>:<dev>:<auto>





     <meine-ip>
        IP-Adresse des Clients. Ist dieses Feld leer, wird die Adresse
        entweder durch RARP oder durch BOOTP bestimmt. Welches Protokoll
        verwendet wird, hngt von dem <auto> Parameter ab und davon, was
        whrend der Kernelkonfiguration aktiviert wurde. Ist dieser
        Parameter nicht leer, dann wird weder RARP noch BOOTP benutzt.


     <serv-ip>
        IP-Adresse des NFS-Servers. Wird RARP zur Bestimmung der Client-
        Adresse verwendet und ist dieser Parameter nicht leer, dann
        werden nur Antworten vom festgelegten Server akzeptiert. Zur
        Verwendung verschiedener RARP- und NFS-Server bestimmt man hier
        den RARP-Server oder lt das Feld leer und legt den NFS-Server
        mit dem nfsroot-Parameter fest (siehe oben). Bleibt dieser
        Eintrag aus, dann wird die Adresse des Servers verwendet,
        welcher auf die RARP- oder BOOTP-Anfrage geantwortet hat.


     <gw-ip>
        IP-Adresse eines Gateways, falls der Server sich in einem
        anderen Subnetz befindet. Ist dieser Eintrag leer, dann wird
        kein Gateway verwendet und es wird angenommen, da sich der
        Server im lokalen Netzwerk befindet, auer wenn durch BOOTP ein
        Wert empfangen wird.
     <netmask>
        Netmask fr die lokale Netzwerkschnittstelle.  Ist dieser
        Eintrag leer, dann wird die Netmask von der Client-IP-Adresse
        abgeleitet, wenn nicht durch BOOTP ein Wert empfangen wird.


     <name>
        Name des Clients. Bleibt dieses Feld leer, dann wird die Client-
        IP-Adresse in ASCII-Notation verwendet oder der durch BOOTP
        empfangene Wert.


     <dev>
        Name des zu verwendenden Netzwerk-Devices. Ist dieses Feld leer,
        dann werden alle Devices fr RARP-Anfragen verwendet und das
        erste Device fr BOOTP. Fr NFS wird das Device benutzt, von dem
        entweder RARP- oder BOOTP-Antworten empfangen wurden. Besitzt
        man nur ein Device, kann man dieses Feld getrost leer lassen.


     <auto>
        Zu verwendende Methode fr die automatische Konfiguration. Ist
        dieses entweder rarp oder bootp, dann wird das angegebene
        Protokoll verwendet. Ist der Wert both oder leer, dann werden
        beide Protokolle in dem Umfang verwendet, wie es ihnen whrend
        der Kernelkonfiguration ermglicht wurde. Der Eintrag none
        schliet die automatische Konfiguration aus.  In diesem Fall
        mssen alle notwendigen Werte in den vorherigen Feldern bestimmt
        werden.


  Der Parameter <auto> kann alleine als Wert fr den Parameter nfsaddrs
  erscheinen, wobei die ganzen :-Zeichen davor entfallen.  In diesem
  Fall wird die automatische Konfiguration verwendet. Jedoch ist der
  Wert none in diesem Fall nicht verfgbar.



  3.5.  Weitere verschiedene Kernel-Bootparameter


  Diese verschiedenen Bootparameter erlauben dem Benutzer die
  Feineinstellung bestimmter interner Parameter.


  3.5.1.  Der Parameter debug


  Mittels der Funktion printk() schickt der Kernel wichtige und weniger
  wichtige Nachrichten an den Administrator. Wird die Nachricht als
  wichtig angesehen, dann wird die Funktion printk() eine Kopie auf der
  aktuellen Konsole ausgeben und sie an klogd() bergeben, so da sie
  auf Festplatte gespeichert wird. Der Grund fr die Ausgabe wichtiger
  Nachrichten auf der Konsole und gleichzeitiger Protokollierung auf der
  Festplatte liegt darin, da unter unglcklichen Umstnden wie z.B.
  einem Plattenausfall die Nachricht nicht zur Festplatte gelangt und
  somit verloren geht.

  Der Grenzwert dafr, was als wichtig oder nicht wichtig betrachtet
  wird, wird von der Variablen console_loglevel festgelegt.
  Standardmig wird alles, was wichtiger ist als DEBUG (Level 7), auf
  der Konsole ausgegeben. Die verschiedenen Level sind in der Include-
  Datei kernel.h definiert. Das Festlegen von debug als Bootparameter
  setzt den Grenzwert der Konsole auf 10, so da alle Mitteilungen des
  Kernels auf der Konsole erscheinen.

  Der Grenzwert der Konsole kann normalerweise auch bei der Ausfhrung
  mittels einer Option des Programmes klogd festgelegt werden.
  Informationen darber kann man der Manpage zu der auf dem System
  installierten Version entnehmen.



  3.5.2.

  Der Parameter init=


  Der Kernel wird beim Booten immer das init-Programm starten, welches
  getty-Programme startet, rc-Skripts laufen lt, u.. und somit den
  Rechner fr die Benutzer einrichtet.  Der Kernel schaut zuerst nach
  /sbin/init, dann nach /etc/init und als letzte Mglichkeit wird er
  versuchen, /bin/sh zu verwenden (mglicherweise auf /etc/rc). Wurde
  z.B. das init-Programm verflscht und somit das Booten unmglich
  gemacht, dann kann man einfach am Bootprompt init=/bin/sh verwenden,
  was beim Booten direkt eine Shell ffnet und somit ein Ersetzen des
  verflschten Programms ermglicht.



  3.5.3.


  Der Parameter kbd-reset


  Normalerweise wird bei i386 basierten Rechnern der Tastaturkontroller
  vom Linux Kernel beim Booten nicht initialisiert, da diese Aufgabe vom
  BIOS bernommen wird.  Aber, wie es nicht anders zu erwarten war,
  machen dieses nicht alle Rechner standardmig. Die Verwendung dieses
  Parameters kann helfen, wenn es Probleme mit der Tastatur gibt. Der
  Parameter fhrt einfach dazu, da beim Booten der Kontroller
  initialisiert wird.



  3.5.4.


  Der Parameter maxcpus=


  Die mit dem Parameter bergebene Zahl limitiert die maximale Anzahl
  von CPUs, die im SMP-Modus aktiviert werden. Die Verwendung der Zahl
  0 hat die gleiche Funktion wie der nosmp Parameter.



  3.5.5.


  Der Parameter mca-pentium


  Die IBM Model 95 Microchannel Rechner scheinen sich beim dem Test
  aufzuhngen, den Linux durchfhrt, um den Typ der Kopplung des
  mathematischen Koprozessors mit der CPU zu ermitteln. Da alle Pentium
  CPUs einen eingebauten Koprozessor besitzen, kann dieser Test und
  damit das beschriebene Probleme durch die Verwendung dieses Parameter
  unterdrckt werden.


  3.5.6.


  Der Parameter md=


  Wenn sich das Root-Dateisystem sich auf einem Multiple Device
  befindet, kann dieser Parameter verwendet werden, um dem Kernel das
  Layout des Multiple Devices mitzuteilen.  Hierfr mu natrlich die
  Bootuntersttzung einkompiliert sein. Das Format dieses Parameter
  sieht so aus:



       md=md_device_num,raid_level,chunk_size_factor,fault_level,dev0,dev1,...,devN




  Siehe auch die Datei linux/Documentation/md.txt.  Hierbei ist
  md_device_num die Nummer des md Devices; 0 wrde fr md0, 1 fr md1
  usw. stehen.  Fr raid_level kann -1 (Linearer Modus) oder 0 (Striped
  Modus) verwendet werden. Andere Modi werden zur Zeit nicht
  untersttzt. Die Option chunk_size_factor kann nur fr RAID-0 und
  RAID-1 benutzt werden. Mit ihr wird die Chunk Size gesetzt; aus dem
  bergebenen Wert wird die Chunk Size berechnet, in dem die PAGE_SIZE
  um den angegebenen Wert nach links geshiftet wird. Mit fault_level
  wird die maximale Anzahl von Fehlern bei RAID-1 festgelegt; da von
  RAID-1 zur Zeit nicht gebootet werden kann, hat diese Option keine
  Funktion. dev0,dev1,...,devN ist eine durch Kommata getrennte Liste
  von Devices, aus denen das md Device gebildet wird, z.B.
  /dev/hda1,/dev/hdc1,/dev/sda1.



  3.5.7.


  Der Parameter no387


  Einige i387 Koprozessoren haben Fehler, die sich bei der Verwendung im
  32 Bit Protected Mode zeigen. Einige der frhen i387 Koprozessoren von
  ULSI verursachen z.B. massive Totalsperren whrend der Ausfhrung von
  Fliekomma-Berechnungen, was offensichtlich ein Bug in den
  FRSAV/FRRESTOR Anweisungen ist.  Die Verwendung des Bootparameters
  no387 veranlat Linux, den mathematischen Koprozessor zu ignorieren,
  sogar wenn einer vorhanden ist. Natrlich mu der Kernel dann so
  kompiliert werden, da sich die Emulation eines Koprozessors im Kernel
  befindet.  Dies ist mglicherweise auch dann sinnvoll, wenn man einen
  dieser wirklich alten i386er hat, die einen 80287 FPU verwenden
  knnen, da Linux keine 80287 FPUs unterstzt.



  3.5.8.  Der Parameter no-hlt


  Die Familie der i386 CPUs und deren Nachfolger verfgen ber die
  Anweisung hlt, die der CPU mitteilt, da nichts geschehen wird,
  solange nicht ein externes Gert (Tastatur, Modem, Platte, etc.) die
  CPU auffordert, eine Aufgabe auszufhren. Dieses erlaubt der CPU in
  einen Modus zu schalten, in dem weniger Energie verbraucht wird. In
  diesem Modus verharrt sie wie ein Zombie, bis sie von einem externen
  Gert, gewhnlich durch einen Interrupt, geweckt wird.  Einige der
  frhen i486DX-100 CPUs hatten insofern ein Problem mit der Anweisung
  hlt, da sie nach deren Ausfhrung nicht mehr verllich in den
  Betriebsmodus zurckkehren konnten. Durch die Benutzung der Anweisung
  no-hlt wird Linux mitgeteilt, einfach eine Endlosschleife zu
  durchlaufen, wenn es nichts anderes zu tun gibt und die CPU nicht zu
  stoppen, wenn es keine aktiven Prozesse gibt.  Dieses ermglicht
  Benutzern mit solchen defekten CPUs die Verwendung von Linux, obwohl
  sie gut beraten wren, sich durch eine mglicherweise noch vorhandene
  Garantie einen Ersatz zu suchen.


  3.5.9.

  Der Parameter no-scroll


  Die Angabe dieses Parameters beim Booten setzt Bildlauf-Features auer
  Kraft, die die Verwendung von Braille-Terminals erschweren.



  3.5.10.



  Der Parameter noapic


  Durch die Verwendung dieses Parameters wird einem SMP-Kernel
  mitgeteilt, nicht die erweiterten Funktionen des Interrupt Kontrollers
  eines Mehrprozessorrechners zu benutzen. Weitere Informationen hierzu
  sind in der Datei linux/Documentation/IO-APIC.txt zu finden.



  3.5.11.  Der Parameter nosmp


  Mittels dieses Parameters kann ein SMP-Kernel angewiesen werden, auf
  einem SMP-Rechner nur einen Prozessor zu verwenden.  Typischerweise
  wird dieser Parameter nur frs Debugging benutzt oder um
  herauszufinden, ob ein bestimmtes Problem durch SMP verursacht wird.



  3.5.12.

  Der Parameter panic=


  Fr den unwahrscheinlichen Fall einer Kernel-Panik wird fr gewhnlich
  gewartet, bis jemand vorbeikommt, die Nachricht der Panik auf dem
  Bildschirm entdeckt und den Rechner neu bootet. Bei einer Kernel-Panik
  handelt es sich um einen internen Fehler, der von Kernel erkannt und
  als ernst genug erachtet wurde, um sich laut zu beschweren und dann
  alles zu stoppen. Falls sich ein Rechner jedoch unbewacht in einer
  abgelegenen Ecke befindet, mag es wnschenswert sein, da automatisch
  ein Reset stattfindet, so da der Rechner wieder zum normalen Betrieb
  zurckkehrt. Die Angabe von panic=30 beim Booten htte z.B. zur Folge,
  da der Kernel 30 Sekunden nach der Kernel-Panik versuchen wrde, sich
  selbst zu booten. Der Standardwert ist Null und fhrt zum
  Standardverhalten, das darin besteht, endlos zu warten.

  Man beachte, da dieser Zeitlimit-Wert auch durch die
  /proc/sys/kernel/panic sysctl-Schnittstelle gelesen und gesetzt werden
  kann.

  3.5.13.


  Der Parameter pirq=


  Diese Parameter dient dazu, einem SMP-Kernel Informationen ber die
  Interrupts der PCI-Steckpltze fr unbekannte oder sich auf der
  schwarzen Liste befindliche SMP Motherboards zu bergeben. Weitere
  Informationen hierzu sind in der Datei linux/Documentation/IO-APIC.txt
  zu finden.



  3.5.14.

  Der Parameter profile=


  Kernel-Entwickler knnen eine Option aktivieren, die es ihnen erlaubt,
  herauszufinden, wie und wo der Kernel seine CPU-Zyklen einsetzt, um
  das uerste an Effizienz und Leistung herauszuholen. Mit dieser
  Option kann man die Profil-Verschiebungszhlung beim Booten bestimmen.
  Normalerweise wird diese auf 2 gesetzt. Man kann den Kernel auch mit
  automatisch aktivierter Profiling kompilieren. In jedem Fall braucht
  man ein Tool wie readprofile.c, das die Ausgabe von /proc/profile
  verwenden kann.



  3.5.15.

  Der Parameter reboot=


  Diese Option kontrolliert die Art des Reboots, die Linux beim Reset
  des Rechners ausfhrt. Seit Version 2.0.x ist der Standard ein
  kalter Neustart (kompletter Reset, BIOS macht einen Speicher-Check,
  etc.) statt eines warmen Neustarts (kein kompletter Reset, kein
  Speicher-Check). Die Voreinstellung wurde in einen Kaltstart gendert,
  da dieser bei billiger/kaputter Hardware, die es nicht schafft, neu zu
  booten, wenn ein Warmstart erforderlich wre, normalerweise
  funktioniert. Zum Wiederherstellen des alten Zustands, nmlich der
  Verwendung eines Warmstarts, verwendet man reboot=w.  Tatschlich
  funktioniert auch jedes beliebige Wort, das mit w beginnt.

  Warum sollte man sich darum kmmern? Einige Platten-Kontroller mit
  eingebautem Cache-Speicher knnen einen Warmstart erkennen und Daten
  aus dem Cache auf die Festplatte schreiben. Nach einem Kaltstart wrde
  der Kontroller eventuell zurckgesetzt werden und die noch auf die
  Festplatte zu schreibenden Daten im Cache wrden verloren gehen.
  Andere Anwender haben Systeme, die recht lange fr den Speicher-Check
  brauchen oder die ein SCSI BIOS enthalten, das nach einem Kaltstart
  lnger fr die Initialisierung braucht.



  3.5.16.

  Der Parameter reserve=


  Dieser wird dazu benutzt, Teile der I/O Ports vor der berprfung zu
  schtzen. Das Kommando ist folgendermaen aufgebaut:


       reserve=iobase,extent[,iobase,extent]...




  Bei einigen Rechnern mag es notwendig sein, die automatische
  Hardwareerkennung der Gertetreiber davon abzuhalten, in einer
  bestimmten Region nach Gerten zu suchen. Der Grund dafr kann z.B.
  schlecht entwickelte Hardware sein, die den Bootvorgang stoppt (wie
  z.B. einige Ethernetkarten), irrtmlicherweise erkannte Hardware,
  Hardware, deren Zustand durch eine frhere Erkennung gendert wurde
  oder einfach Hardware, die vom Kernel nicht initialisiert werden soll.

  Der Bootparameter reserve geht dieses Problem dadurch an, da er einen
  I/O Port-Bereich angibt, der nicht geprft werden soll. Diese Region
  wird in der Registrationstabelle des Kernels fr Ports so behandelt,
  als ob unter der Adresse bereits ein Gert mit dem Namen reserved
  gefunden wurde. Man beachte, da dieser Mechanismus fr die meisten
  Rechner nicht notwendig sein drfte. Er ist nur bei Problemen und in
  besonderen Fllen erforderlich.

  Die I/O Ports in dem angegebenen Bereich sind gegen eine
  Gerteerkennung geschtzt, bei der zuerst die Funktion check_region()
  ausgefhrt wird, statt blind einen I/O Bereich zu prfen. Dieses wird
  dann eingesetzt, wenn Treiber bei der Erkennung z.B. durch eine
  NE2000-Karte hngenbleiben oder irrtmlich andere Gerte als eigene
  erkannt werden. Ein korrekter Gertetreiber sollte keine reservierten
  Bereiche prfen, wenn nicht ein anderer Bootparameter dieses
  ausdrcklich verlangt. Das bedeutet, da reserve meistens zusammmen
  mit einem anderen Bootparameter verwendet wird. Wenn man also einen
  reservierten Bereich festlegt, der ein bestimmtes Gert schtzen soll,
  dann mu man im allgemeinen explizit eine Erkennung dieses Gertes
  erzwingen. Die meisten Treiber ignorieren die Registrierungstabelle
  fr Ports, wenn ihnen eine bestimmte Adresse genannt wird.

  Die Bootzeile



       reserve=0x300,32  blah=0x300




  hlt z.B. alle Gertetreiber, mit Ausnahme des Treibers fr blah
  davon ab, 0x300-0x31f zu prfen.

  Wie blich bei Boot-Argumenten gibt es ein Limit von elf Parametern,
  d.h. man kann nur fnf reservierte Bereiche pro reserve Schlsselwort
  bestimmen. Bei ungewhnlich komplizierten Anfragen sind jedoch mehrere
  reserve Argumente mglich.



  3.5.17.

  Der Parameter vga=


  Man beachte, da es sich hierbei nicht um einen wirklichen
  Bootparameter handelt. Es ist vielmehr eine Option, die von LILO
  interpretiert wird und nicht vom Kernel wie all die anderen
  Bootparameter. Sie wird jedoch so hufig verwendet, da sie an dieser
  Stelle eine Erwhnung verdient. Sie kann auch durch die Verwendung von
  rdev -v festgelegt werden und ebenso durch vidmode auf der Datei
  vmlinuz. Dieses ermglicht dem Setup-Code die Benutzung des Video-BIOS
  zur nderung des Standard-Anzeige-Modus vor dem tatschlichen Booten
  des Linux-Kernels. Typische Modi sind 80x50, 132x44 usw. Man verwendet
  diese Option am besten, indem man mit vga=ask beginnt, worauf man eine
  Liste verschiedener Modi erhlt, die man mit dem Grafik-Adapter
  benutzen kann, bevor man den Kernel bootet. Hat man einmal eine Nummer
  aus obiger Liste gewhlt, kann man sie spter anstelle von ask setzen.
  Weitere Informationen findet man in der Datei
  linux/Documentation/svga.txt, die mit allen neueren Kernel-Versionen
  ausgeliefert wird.

  Man beachte, da neuere Kernelversionen (v2.1 und hher) den Setup-
  Code, der den Grafik-Modus ndert, als Option enthalten. Diese ist
  aufgelistet als Video mode selection support, d.h. man mu diese
  Option aktivieren, um dieses Feature verwenden zu knnen.



  4.


  Bootparameter fr die Kontrolle des PCI-Bus Verhaltens


  Der Parameter pci=, der in v2.0 Kernel noch nicht verfgbar war,
  kann benutzt werden, um das Verhalten beim Testen der PCI Devices und
  der PCI Devices selbst zu verndern. In der Sourcedatei
  linux/drivers/pci/pci.c werden zuerst die von der Computerarchitektur
  unabhngigen pci=-Parameter ausgewertet. Die brig gebliebenen
  Parameter werden dann von linux/arch/xxx/kernel/bios32.c behandelt,
  wobei xxx fr die Architektur des Rechners steht. Die folgenden
  Optionen beziehen sich auf die i386-Architektur.



  4.1.  Die Parameter pci=bios und pci=nobios


  Standardmig wird der PCI-Bus und seine Devices vom BIOS des
  Motherboars getestet und konfiguriert. Mit diesem Parameter kann
  festgelegt werden, ob das BIOS diese Aufgabe bernehmen soll oder
  nicht.



  4.2.  Die Parameter pci=conf1 und pci=conf2


  Wenn der PCI Direct Modus eingeschaltet ist, kann durch die Verwendung
  dieser Parameter entweder die Konfiguration Typ 1 oder Typ 2
  eingeschaltet werden. Hierdurch wird implizit die Option pci=nobios
  aktiviert.



  4.3.  Der Parameter pci=io=


  Falls Sie eine Meldung wie PCI: Unassigned IO space for ... erhalten
  sollten, mssen Sie eventuell einen I/O-Wert mit diesem Parameter
  setzen. Im Source des Linux Kernels ist zu diesem Parameter zu lesen:


       Mehrere BIOSe vergessen, I/O-Bereichen Adressen zuzuweisen.
       Wir versuchen, dieses hiermit zu beheben, wobei wir davon
       ausgehen, das beginnend mit 0x5800 freie Adressen
       existieren.  Dies ist keine gut Lsung; aber bis wir ein
  besseres Ressourcenmanagement integriert haben, ist dieses
  die einzige einfache Lsung.




  4.4.  Der Parameter pci=nopeer


  Hiermit wird die standardmige Peer Bridge Fehlerbehebung
  abgeschaltet, die gem dem Kernel Source folgendes macht:


       Fr den Fall, da Peer Host Bridges existieren, scanne den
       Bus hinter ihnen. Obwohl verschiedene Quellen behaupten, da
       eine Host Bridge den Header Typ 1 haben und eine Bus Nummer
       wie fr eine PCI2PCI Bridge zugewiesen bekommen haben soll
       ten, stimmt dieses in der Realitt nicht. Die Bus Nummer
       wird vom BIOS meistens auf den ersten freien Wert gesetzt.



  4.5.  Der Parameter pci=nosort

  Durch die Verwendung dieses Parameters wird der Kernel aufgefordert,
  die PCI Devices whrend der Testphase nicht zu sortieren.


  4.6.  Der Parameter pci=off

  Smtliche PCI-Tests werden mit diesem Parameter abgeschaltet.  Jeder
  Gertetreiber, der Gebrauch von den PCI-Funktionen macht, um die
  Hardware zu finden und zu initialisieren, wird mit groer
  Wahrscheinlichkeit nicht mehr funktionieren.


  4.7.  Der Parameter pci=reverse

  Hiermit wird die Reihenfolge der PCI Devices umgekehrt.



  5.


  Bootparameter fr Video Frame Buffer Treiber

  Der Parameter video=, der in v2.0.x Kerneln noch nicht verfgbar
  war, kann benutzt werden, wenn im Kernel die Frame Buffer Device
  Abstraktionsschicht einkompiliert worden ist. Wenn dieses auch
  kompliziert zu sein scheint, es ist garnicht so schlimm.

  Im Prinzip bedeutet dieses, da Programme wie ein X11-Server, die den
  Grafikmodus einer Grafikkarte nutzen, nicht fr jede Grafikkarte
  speziell angepat werden mssen.  Statt dessen enthlt der Kernel fr
  jede Grafikkarte einen passenden Treiber und bietet den Anwendungen
  eine einheitliche Programmierschnittstelle. Man bentigt dann z.B.
  nicht mehr fr jede Grafikkarte einen eigenen X11-Server (XF86_S3,
  XF86_SVGA usw.) sondern nur noch einen einzigen fr die Schnittstelle
  des Kernels (XF_FBDev).

  Vergleichbar ist dieses Vorgehen z.B. mit den Netzwerkkartentreibern.
  Auch hier enthlt der Kernel fr alle untersttzten Netzwerkkarten
  einen Treiber und bietet den Anwendungen eine einheitliche
  Programmierschnittstelle, so da ein Programm automatisch mit allen
  untersttzten Netzwerkkarten funktioniert. Welche Netzwerkkarte in
  einem speziellen System Verwendung findet, ist fr die Anwendung
  unwichtig.

  Typischerweise ist das Format dieses Parameters:



       video=name:option1,option2,...




  Hierbei ist name der Name einer allgemeinen Option oder eines Frame
  Buffer Treibers. Der video= Parameter wird zur weiteren Verarbeitung
  von linux/init/main.c an linux/drivers/video/fbmem.c weitergegeben.
  Hier wird der Parameter zuerst auf einige allgemeine Optionen
  untersucht, bevor versucht wird, ein Treiber mit diesem Namen zu
  finden.  Ist erst einmal ein passender Name eines Treiber gefunden
  worden, wird die durch Kommata getrennte Liste von Optionen an diesen
  Treiber zur weiteren Verarbeitung bergeben. Eine Liste von gltigen
  Namen von Treiber kann in dem Array fb_drivers in der oben erwhnten
  Datei fbmem.c gefunden werden.

  Informationen ber die Optionen, die die einzelnen Treiber
  untersttzen, knnen in dem Verzeichnis linux/Documentation/fb/
  gefunden werden. Zur Zeit (v2.2) werden dort nur einige wenige
  beschrieben.  Unglcklicherweise ist die Anzahl von Grafiktreibern und
  die Anzahl von Optionen, die diese untersttzen, so gro, da sie hier
  nicht aufgelistet werden knnen.

  Falls es fr Ihre Grafikkarte keine Dokumentation gibt, mssen Sie die
  Informationen der verfgbaren Optionen direkt aus dem entsprechenden
  Treiber gewinnen. Wechseln Sie dazu in das Verzeichnis
  linux/drivers/video/ und schauen Sie sich die passende xxxfb.c Datei
  an, wobei Sie xxx durch den Namen Ihrer Grafikkarte ersetzen mssen.
  In dieser Datei sollten Sie dann nach einer Funktion suchen, deren
  Name _setup enthlt. In dieser Funktion sollten die Optionen
  aufgelistet sein, die der Treiber untersttzt.


  5.1.  Der Parameter video=map:...

  Mit diesem Parameter kann das Konsole - Frame Buffer Device Mapping
  gesetzt bzw. gendert werden. Eine durch Kommata getrennte Liste von
  Zahlen setzt das Mapping. Der Wert von Option (n) wird als Frame
  Buffer Device Nummer fr Konsole (n) verwendet.


  5.2.  Der Parameter video=scrollback:...

  Eine Zahl, die hinter dem Doppelpunkt angegeben werden mu, legt die
  Gre des Speichers fest, der fr den Scrollback Buffer reserviert
  wird. Durch diesen Scrollback Buffer kann der Anwender mittels Shift
  und Page Up oder Page Down den Bildschirminhalt zurckblttern.
  Durch das Anhngen des Buchstabens k oder K ans Ende der Zahl wird
  dem Treiber mitgeteilt, da die bergebene Zahl die Gre in Kilobytes
  und nicht in Bytes angibt.


  5.3.  Der Parameter video=vc:...

  Eine Zahl bzw. ein Zahlenbereich (z.B. video=vc:2-5) spezifiziert die
  erste bzw. die ersten und die letzte Frame Buffer Virtual Console. Die
  Verwendung dieses Parameters hat auerdem den Effekt, da die Frame
  Buffer Konsole nicht die Standardkonsole ist.

  6.

  Bootparameter fr SCSI-Peripheriegerte


  Dieser Abschnitt enthlt eine Beschreibung der Bootparameter, die zur
  Weitergabe von Informationen ber die installierten SCSI-Host-Adapter
  und SCSI-Gerte verwendet werden.


  6.1.  Parameter fr Mid-Level-Treiber

  Das SCSI-System von Linux gliedert sich in zwei Teile.  Fr jeden
  SCSI-Adapter gibt es einen speziellen Low-Level-Treiber, der dessen
  Funktionalitt ber eine definierte Schnittstelle den Mid-Level-
  Treibern zugnglich macht. Fr jeden SCSI-Gertetyp wie z.B.
  Festplatten, CD-ROMs oder Streamer gibt es einen speziellen Mid-Level-
  Treiber.


  6.1.1.

  Maximale Anzahl berprfter LUNs (max_scsi_luns=)


  Jedes SCSI-Gert kann eine Reihe von Sub-Gerten enthalten. Das
  beste Beispiel dafr sind die CD-ROM-Wechsler.  Jede CD in diesem
  Wechsler wird als Logical Unit Number (LUN) dieses bestimmten
  Gertes angesprochen. Die meisten Gerte jedoch, wie z.B.
  Festplatten, Bandlaufwerke u.. bestehen nur aus einer Gerteeinheit
  und erhalten LUN Null.

  Ein Problem ergibt sich bei einigen Gerten mit einer einzigen LUN.
  Diese Gerte, alte, aber leider auch neue, besitzen eine schlechte
  Firmware, die mit der berprfung fr LUNs ungleich null nicht umgehen
  kann. Als Reaktion auf die berprfung hngen sich die Gerte auf und
  blockieren im schlimmsten Fall sogar den gesamten SCSI-Bus, so da
  auch andere Gerte nicht mehr angesprochen werden knnen.

  Neuere Kernel verfgen ber eine Konfigurations-Option, die es
  ermglicht, die maximale Anzahl von geprften LUNs festzulegen.
  Standardmig untersucht man nur LUN Null, um das oben erwhnte
  Problem zu vermeiden.

  Zur Bestimmung der Anzahl von geprften LUNs beim Booten gibt man
  max_scsi_luns=n als Bootparameter ein, wobei n eine Zahl zwischen 1
  und 8 ist. Um oben genannte Probleme zu vermeiden, wrde man n=1
  verwenden, um solche defekten Gerte nicht zu verwirren.


  6.1.2.

  SCSI Logging (scsi_logging=)

  Durch bergabe eines von Null verschiedenen Wertes an diesen Parameter
  wird das Logging von allen SCSI-Ereignissen (error, scan, mlqueue,
  mlcomplete, llqueue, llcomplete, hlqueue und hlcomplete)
  eingeschaltet. Hierbei sollte man beachten, da ber das
  /proc/scsi/scsi Interface besser kontrollieren werden kann, welche
  Ereignisse protokolliert werden sollen. Diese zweite Lsung kann
  allerdings nur Ereignisse protokollieren, die nach dem Mounten des
  /proc Dateisystems auftreten.




  6.1.3.

  Parameter fr den SCSI-Tape-Treiber (st=)


  Ein Teil der Boot-Konfiguration des Treibers fr SCSI-Bandlaufwerke
  kann mit folgendem Kommando erfolgen:



       st=buf_gre[,schreib_grenzwert[,max_bufs]]




  Die ersten zwei Zahlen werden in kB-Einheiten angegeben. Der
  Standardwert fr buf_gre ist 32 kB und die maximal zu bestimmende
  Gre sind lcherliche 16384 kB. schreib_grenzwert ist der Grenzwert,
  bei dem der Puffer an das Laufwerk weitergegeben wird. Standardwert
  hierbei sind 30 kB. Die maximale Anzahl von Puffern ndert sich je
  nach der Zahl der erkannten Laufwerke. Standardwert ist 2. Hier eine
  Beispielverwendung:



       st=32,30,2




  Umfassende Details findet man in der Datei README.st im Verzeichnis
  scsi des Kernel-Quell-Baums.



  6.2.


  Parameter fr SCSI-Host-Adapter


  Allgemeine Anmerkungen zu diesem Abschnitt:


     iobase
        Der erste I/O Port, der vom SCSI-Host belegt wird.  Er wird in
        der Hexadezimalschreibweise angegeben und liegt fr gewhnlich
        zwischen 0x200 und 0x3ff.


     irq
        Der Hardware-Interrupt, den die Karte per Konfiguration
        verwendet. Die gltigen Werte sind abhngig von der fraglichen
        Karte. Normalerweise gelten die Werte 5, 7, 9, 10, 11, 12 und
        15. Die anderen Werte werden normalerweise fr bliche
        Peripheriegerte wie IDE-Festplatten, Disketten, serielle
        Anschlsse etc. verwendet.


     dma
        Der von der Karte verwendete DMA-Kanal (Direct Memory Access).
        Dies gilt typischerweise nur fr Busmaster-Karten. PCI und VLB
        Karten bentigen keinen ISA-DMA-Kanal.



     scsi-id
        Die ID, die der Host-Adapter verwendet, um sich auf dem SCSI-Bus
        zu identifizieren. Nur einige Host-Adapter erlauben die nderung
        dieses Werts, da er bei den meisten intern fest eingestellt ist.
        Gewhnlich ist der Standardwert ID 7. Die Seagate und Future
        Domain TMC-950-Boards jedoch verwenden ID 6.


     parity
        Legt fest, ob der SCSI Host-Adapter von den angeschlossenen
        Gerten erwartet, da sie fr alle ausgetauschten Informationen
        einen Parittswert zur Verfgung stellen. Der Wert 1 aktiviert
        den Paritts-Check und 0 schaltet ihn ab. Auch hier gilt, da
        nicht alle Adapter die Auswahl eines Parittsverhaltens als
        Bootparameter untersttzen.



  6.2.1.


  Adaptec aha151x, aha152x, aic6260, aic6360, SB16-SCSI (aha152x=)


  Die aha-Zahlen beziehen sich auf Karten und die aic-Zahlen beziehen
  sich auf den tatschlichen SCSI-Chip auf diesem Kartentyp,
  Soundblaster-16 SCSI eingeschlossen.

  Die automatische Hardwareerkennung des Treibers fr diesen SCSI Host
  schaut nach einem installierten BIOS. Falls keines vorhanden ist, wird
  die Karte nicht gefunden. Fr diesen Fall wird man einen Bootparameter
  folgender Form verwenden mssen:



       aha152x=iobase[,irq[,scsi-id[,reconnect[,parity]]]]




  Wurde der Treiber mit aktiviertem Debugging kompiliert, dann kann ein
  sechster Wert zur Bestimmung des Debug-Levels gesetzt werden.

  Alle Parameter verhalten sich wie eingangs dieses Abschnitts
  beschrieben. Ein reconnect Wert ungleich null erlaubt Gerten die
  Verwendung von Disconnect/Reconnect.  Hier eine Beispielverwendung:



       aha152x=0x340,11,7,1




  Man beachte, da die Angabe der Parameter einer bestimmten Reihenfolge
  folgen mu, d.h. wenn man eine Parittseinstellung angeben will, dann
  mu man auch einen iobase-, einen irq-, einen scsi-id- und einen
  reconnect-Wert angeben.


  6.2.2.  Adaptec aha154x (aha1542=)


  Dies sind die Karten aus der aha154x-Serie. Die Karten aus der
  aha1542-Serie verfgen ber einen i82077 Floppy-Kontroller, die Karten
  der Serie aha1540 hingegen nicht. Diese sind Busmaster-Karten und
  haben Parameter zur Festlegung der Fairness, die dazu verwendet
  wird, den Bus mit anderen Gerten zu teilen. Der Bootparameter sieht
  folgendermaen aus:



       aha1542=iobase[,buson,busoff[,dmaspeed]]




  Gewhnlich ist einer der folgenden iobase Werte gltig: 0x130, 0x134,
  0x230, 0x234, 0x330 oder 0x334.  Clone-Karten lassen mglicherweise
  andere Werte zu.

  Die buson, busoff Werte beziehen sich auf die Anzahl von
  Mikrosekunden, in denen die Karte den ISA-Bus beherrscht. Die
  Standardwerte sind 11 s an und 4 s aus, so da andere Karten wie
  z.B. eine ISA LANCE Ethernetkarte eine Chance haben, auf den ISA-Bus
  zuzugreifen.

  Der Wert dmaspeed bezieht sich auf die Geschwindigkeit (in MB/s) in
  der der DMA-Transfer erfolgt. Der Standardwert ist 5 MB/s. Karten
  einer neueren Revision ermglichen die Auswahl dieses Werts als Teil
  der Konfiguration per Software, ltere Karten verwenden Jumper. Man
  kann Werte bis 10 MB/s benutzen, vorausgesetzt, das Motherboard kann
  damit umgehen. Bei der Verwendung von Werten ber 5 MB/s sollte man
  vorsichtig vorgehen.


  6.2.3.  Adaptec aha274x, aha284x, aic7xxx (aic7xxx=)


  Diese Boards knnen einen Parameter folgender Form annehmen:



       aic7xxx=extended,no_reset




  Der Wert extended, falls ungleich Null, besagt, da die erweiterte
  bersetzung fr groe Platten eingeschaltet ist. Der Wert no_reset,
  falls ungleich Null, teilt dem Treiber mit, keinen Reset auf dem SCSI-
  Bus auszufhren, wenn der Host-Adapter beim Booten initialisiert wird.



  6.2.4.


  AdvanSys SCSI Host-Adapter (advansys=)


  Der AdvanSys-Treiber akzeptiert bis zu 4 I/O Adressen, unter denen der
  Treiber eine AdvanSys SCSI-Karte sucht.  Man beachte, da diese Werte
  berhaupt keinen Einflu auf die EISA- oder PCI-Karten haben. Sie
  werden nur fr die berprfung von ISA- und VLB-Karten eingesetzt.
  Wurde der Treiber mit eingeschaltetem Debugging kompiliert, kann durch
  Hinzufgen des Parameters 0xdeb[0-f] bestimmt werden, bis zu welchem
  Grad Debugging-Meldungen ausgegeben werden sollen. 0-f ermglicht die
  Festlegung des Levels der Debugging-Meldungen auf jeden der 16 Level.



  6.2.5.


  Always IN2000-Host-Adapter (in2000=)


  Im Gegensatz zu den Bootparametern der anderen SCSI Host-Adapter
  verwendet der IN2000-Treiber fr die meisten seiner Integer-Parameter
  ASCII-Strings als Prfix.  Hier eine Liste von untersttzten
  Parametern:


     ioport:addr
        Wobei addr die I/O-Adresse einer Karte ist, die gewhnlich kein
        ROM besitzt.


     noreset
        Verhindert einen Reset des SCSI-Busses beim Booten.  Diesem
        Parameter knnen keine optionalen Argumente bergeben werden.


     nosync:x
        x ist eine Bitmaske, wobei die ersten 7 Bit mit den 7 mglichen
        SCSI-Gerten bereinstimmen (Bit 0 fr das Gert mit ID0, etc).
        Um die Sync-bertragung auf ein Gert zu verhindern, setzt man
        dessen Bit. Standardmig ist Sync fr alle Gerte
        ausgeschaltet.


     period:ns
        ns ist die minimale # von Nanosekunden fr einen SCSI-
        Datentransfer. Standard ist 500; erlaubte Werte sind 250 bis
        1000.


     disconnect:x
        x = 0 verhindert grundstzlich Disconnects; x = 2 erlaubt immer
        Disconnects.  x = 1 fhrt adaptive Disconnects durch. Dieses
        ist der Standard und wohl allgemein die beste Wahl.


     debug:x
        Ist DEBUGGING_ON angegeben, dann ist x eine Bitmaske, durch
        die verschiedene Arten von Debug-Ausgaben ein- oder
        ausgeschaltet werden; siehe hierzu die Definition der DB_xxx
        Konstanten in in2000.h.


     proc:x
        Ist PROC_INTERFACE angegeben, dann ist x eine Bitmaske, die
        festlegt, wie die /proc-Schnittstelle funktioniert und was sie
        macht; siehe hierzu die Definition der PR_xxx Konstanten in
        in2000.h.


  Hier einige Anwendungs-Beispiele :



       in2000=ioport:0x220,noreset
       in2000=period:250,disconnect:2,nosync:0x03
       in2000=debug:0x1e
       in2000=proc:3


  6.2.6.


  AMD AM53C974-basierte Hardware (AM53C974=)


  Im Gegensatz zu anderen Treibern verwendet dieser keine Bootparameter,
  um I/O-, IRQ- oder DMA-Kanle festzulegen.  Da der AM53C974 ein PCI-
  Gert ist, sollte dafr auch kein Grund bestehen. Statt dessen teilen
  die Parameter fr gewhnlich die Transfermodi und Transferraten mit,
  die zwischen dem Host- und dem Zielgert verwendet werden sollen. Dies
  lt sich am besten anhand eines Beispiels beschreiben:



       AM53C974=7,2,8,15




  Dies wrde folgendermaen interpretiert werden: Fr die Kommunikation
  zwischen dem SCSI-Kontroller mit ID7 und dem SCSI-Gert mit ID2 soll
  eine Transferrate von 8 MHz im Synchronmodus mit max. 15 Bytes Offset
  ausgehandelt werden. Weitere Informationen findet man in der Datei
  linux/drivers/scsi/README.AM53C974


  6.2.7.

  BusLogic SCSI-Hosts mit v1.2.x Kerneln (buslogic=)


  In lteren Kerneln akzeptiert der buslogic-Treiber nur einen
  Parameter, und zwar die iobase. Folgende Werte sind zulssig: 0x130,
  0x134, 0x230, 0x234, 0x330 und 0x334.


  6.2.8.  BusLogic SCSI-Hosts mit v2.x Kerneln (BusLogic=)

  Bei v2.x Kerneln akzeptiert der BusLogic-Treiber viele Parameter.  Man
  beachte die neue Schreibweise des Parameters im Vergleich zu den alten
  Kernels. Dieser Parameter kennt zu viele Option, als das man diese
  hier alle auflisten knnte. Eine komplette Beschreibung der Optionen
  ist in der Datei linux/drivers/scsi/BusLogic.c zu finden, wenn man
  nach der Zeichenkette BusLogic= sucht.


  6.2.9.


  EATA SCSI-Karten (eata=)


  Seit den spten Kernelversionen v2.0 akzeptieren die EATA-Treiber die
  berprfung eines Bootparameters, der die iobase(s) bestimmt. Dieses
  sieht folgendermaen aus:



       eata=iobase1[,iobase2][,iobase3]...[,iobaseN]




  Der Treiber berprft die Adressen in der Reihenfolge, in der sie
  aufgelistet sind.
  6.2.10.


  Future Domain TMC-8xx, TMC-950 (tmc8xx=)


  Der berprfungscode fr diese SCSI-Hosts schaut nach einem
  installierten BIOS; falls keines vorhanden ist, wird die Karte nicht
  gefunden werden. Auch wenn der Signatur-String des BIOS nicht erkannt
  wurde, wird die Karte nicht gefunden. In jedem der beiden Flle wird
  man dann einen Bootparameter folgender Form verwenden:



       tmc8xx=mem_base,irq




  Der Wert mem_base ist der Wert des in den Speicher eingeblendeten I/O-
  Bereichs, den die Karte verwendet. Dieser ist fr gewhnlich einer der
  folgenden Werte: 0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000 oder
  0xde000.


  6.2.11.


  Future Domain TMC-16xx, TMC-3260, AHA-2920 (fdomain=)


  Der Treiber erkennt diese Karten entsprechend einer Liste von
  bekannten BIOS ROM-Signaturen. Eine komplette Liste bekannter BIOS-
  Ausgaben erhlt man in der Datei linux/drivers/scsi/fdomain.c. Diese
  wird mit einer Flle von Informationen eingeleitet. Ist das BIOS dem
  Treiber nicht bekannt, dann kann man dies folgendermaen berbrcken:



       fdomain=iobase,irq[,scsi_id]





  6.2.12.


  IOMEGA Parallel Port ZIP-Laufwerk (ppa=)


  Dieses ist ein Treiber fr den IOMEGA Parallel Port SCSI Adapter,
  welcher in den IOMEGA ZIP-Laufwerken enthalten ist.  Er knnte auch
  mit dem original IOMEGA PPA3-Gert funktionieren. Der Bootparameter
  fr diesen Treiber sieht folgendermaen aus:



       ppa=iobase,speed_high,speed_low,nybble




  Alle auer iobase sind optional festlegbare Werte. Will man einen der
  optionalen Parameter verndern, dann sollte man einen Blick in die
  Datei linux/drivers/scsi/README.ppa werfen. Dort findet man genaue
  Informationen darber, was von diesen Parametern kontrolliert wird.


  6.2.13.


  NCR5380-basierte Kontroller (ncr5380=)


  Je nach Board kann der 5380 entweder ber I/O-Ports oder einen
  eingeblendeten Speicherbereich angesprochen werden.  Eine Adresse
  unter 0x400 ist fr gewhnlich ein I/O-Port.  PCI- und EISA-Hardware
  verwenden jedoch I/O-Adressen ber 0x3ff. In jedem Fall gibt man die
  Adresse, den Wert des Interrupts und des DMA-Kanals an. Hier ein
  Beispiel einer I/O-Karte: ncr5380=0x350,5,3. Verwendet die Karte keine
  Interrupts, dann knnen mit einem IRQ-Wert von 255 (0xff) Interrupts
  deaktiviert werden. Ein IRQ-Wert von 254 bedeutet eine automatische
  Hardwareerkennung. Weitere Informationen findet man in der Datei
  linux/drivers/scsi/README.g_NCR5380.


  6.2.14.  NCR53c400-basierte Kontroller (ncr53c400=)


  Die generische 53c400-Untersttzung erfolgt mit demselben Treiber wie
  fr die oben erwhnte generische 5380-Untersttzung. Der Bootparameter
  ist identisch zum obig genannten, mit der Ausnahme, da vom 53c400
  kein DMA-Kanal verwendet wird.


  6.2.15.  NCR53c406a-basierte Kontroller (ncr53c406a=)


  Dieser Treiber verwendet einen Bootparameter folgender Form



       ncr53c406a=PORTBASE,IRQ,FASTPIO




  wobei die IRQ- und FASTPIO-Parameter optional sind. Ein Interrupt-Wert
  von 0 schaltet die Verwendung von Interrupts aus.  Der Wert 1 fr den
  FASTPIO-Parameter aktiviert die Verwendung von insl- und outsl-
  Anweisungen statt den aus einem einzigen Byte bestehenden inb- und
  outb-Anweisungen.  Whrend der Kompilierung eines neuen Kernels steht
  DMA als Option zur Verfgung.


  6.2.16.


  Pro Audio Spectrum (pas16=)


  PAS16 verwendet einen NCR5380 SCSI-Chip und neuere Modelle
  untersttzen die Konfiguration ohne Jumper. Der Bootparameter sieht
  folgendermaen aus:



       pas16=iobase,irq



  Der einzige Unterschied besteht darin, da man einen IRQ-Wert von 255
  verwenden kann, welcher dem Treiber mitteilt, ohne die Verwendung von
  Interrupts zu arbeiten, was jedoch Geschwindigkeitsverluste mit sich
  bringt.  Die iobase ist gewhnlich 0x388.


  6.2.17.


  Seagate ST-0x (st0x=)


  Der Code zur berprfung fr diese SCSI-Hosts sucht nach einem
  installierten BIOS. Ist keines vorhanden, wird die Karte nicht
  gefunden. Auch wenn die Signatur-Zeichenkette des BIOS nicht erkannt
  wird, wird die Karte nicht gefunden. In jedem Fall wird man einen
  Bootparameter folgender Form verwenden:



       st0x=mem_base,irq




  Der Wert mem_base ist der Wert der in den Speicher eingeblendeten I/O-
  Region, den die Karte verwendet. Dieser wird fr gewhnlich einer der
  folgenden Werte sein: 0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000 oder
  0xde000.


  6.2.18.


  Trantor T128 (t128=)


  Diese Karten basieren ebenfalls auf dem NCR5380-Chip und verstehen
  folgende Optionen:



       t128=mem_base,irq




  Gltige Werte fr mem_base sind: 0xcc000, 0xc8000, 0xdc000 und
  0xd8000.


  6.2.19.


  Ultrastor SCSI-Karten (u14-34f=)


  Man beachte, da es anscheinend zwei unabhngige Treiber fr diese
  Karte gibt, nmlich CONFIG_SCSI_U14_34F, der u14-34f.c benutzt, und
  CONFIG_SCSI_ULTRASTOR, der ultrastor.c verwendet. u14-34f ist
  derjenige, der seit den spten Kernelversionen v2.0 einen
  Bootparameter folgender Form akzeptiert:




  u14-34f=iobase1[,iobase2][,iobase3]...[,iobaseN]




  Der Treiber berprft die Adressen in der Reihenfolge, wie sie
  aufgelistet sind.


  6.2.20.


  Western Digital WD7000-Karten (wd7000=)


  Die automatische Erkennung fr wd7000 sucht nach einer bekannten BIOS
  ROM-Zeichenkette und kennt einige Standardeinstellungen. Werden die
  korrekten Werte fr die eigene Karte nicht geliefert oder hat man eine
  nicht erkannte BIOS-Version, dann kann man einen Bootparameter
  folgender Form verwenden:



       wd7000=irq,dma,iobase






  6.3.  SCSI-Host-Adapter, die keine Bootparameter akzeptieren


  Zur Zeit verwenden die Treiber folgender SCSI-Karten keine
  Bootparameter.  In einigen Fllen kann man Werte hartkodieren, indem
  man, falls ntig, den Treiber selbst editiert.


    Adaptec aha1740 (EISA-berprfung)

    NCR53c7xx,8xx (PCI, beide Treiber)

    Qlogic Fast (0x230, 0x330)

    Qlogic ISP (PCI)



  7.


  Festplatten


  In diesem Abschnitt werden alle Bootparameter aufgelistet, die mit
  Standard-MFM/RLL-, ST-506-, XT- und (E)IDE-Laufwerken verbunden sind.
  Man beachte, da sowohl der IDE- als auch der generische ST-506 HD-
  Treiber die Option hd= akzeptieren.



  7.1.

  IDE Disk-/CD-ROM-Treiber-Parameter


  Der IDE-Treiber akzeptiert eine Reihe von Parametern, die von
  Spezifikationen der Plattengeometrie bis zur Untersttzung fr hher
  entwickelte oder kaputte Kontroller-Chips reichen. Es folgt eine
  Zusammenfassung aller mglichen Bootparameter. Bentigt man weitere
  Informationen, sollte man unbedingt einen Blick in die Datei ide.txt
  im Verzeichnis linux/Documentation werfen, dem diese Zusammenfassung
  entnommen wurde.

  Bei dem Parameter hdx= knnen fr x Werte von a bis h verwendet
  werden. Fr x bei dem Parameter idex= knnen Werte von 0 bis 3
  Verwendung finden. Beispielsweise wrde Linux hdc= und ide1= erkennen.



     hdx=noprobe
        Laufwerk mag vorhanden sein, aber es soll nicht automatisch nach
        ihm gesucht werden.


     hdx=none
        Das Laufwerk ist nicht vorhanden. Die CMOS-Einstellungen sollen
        ignoriert und das Laufwerk nicht erkannt werden.


     hdx=nowerr
        Das WRERR_STAT-Bit soll bei diesem Laufwerk ignoriert werden.


     hdx=cdrom
        Das Laufwerk ist vorhanden und es handelt sich um ein CD-ROM-
        Laufwerk.


     hdx=cyl,head,sect
        Ein Plattenlaufwerk mit angegebener Geometrie ist vorhanden.


     hdx=autotune
        Der Treiber soll versuchen, die Geschwindigkeit der
        Schnittstelle auf den schnellsten untersttzten PIO-Modus
        einzustellen.  Wenn mglich, soll nur der Modus dieses
        Laufwerkes verndert werden.  Diese Option wird nicht von allen
        Chipstzen voll untersttzt.  Kann zu Problemen mit bestimmten
        IDE-Laufwerken fhren.


     idex=noprobe
        Es soll nicht versucht werden, auf diese Schnittstelle
        zuzugreifen oder sie zu verwenden.


     idex=base
        Die IDE-Schnittstelle soll unter der angegebenen Adresse gesucht
        werden, wobei base normalerweise 0x1f0 oder 0x170 ist und
        angenommen wird, da ctl base+0x206 ist.


     idex=base,ctl
        Es wird sowohl base als auch ctl bestimmt.


     idex=base,ctl,irq
        Legt base, ctl und irq fest.



     idex=autotune
        Hat die gleiche Funktion wie hdx=autotune, bezieht sich
        allerdings auf alle Laufwerke an einer Schnittstelle.


     idex=noautotune
        Der Treiber versucht nicht, die Geschwindigkeit der
        Schnittstelle einzustellen. Dies ist der Standard fr die
        meisten Chipstze mit Ausnahme des cmd640.


     idex=serialize
        Es wird nicht gleichzeitig auf idex und eine weitere IDE-
        Schnittstelle zugegriffen. Dies ist fr einige fehlerhafte
        Chipstze sehr ntzlich.


  Das Folgende gilt nur auf ide0, und die Standardwerte fr die base und
  ctl Ports drfen nicht gendert werden.



     ide0=dtc2278
        Prfe und untersttze die DTC2278-Schnittstelle.


     ide0=ht6560b
        Prfe und untersttze die HT6560B-Schnittstelle.


     ide0=cmd640_vlb
        Ist nur fr VLB-Karten mit dem CMD640-Chip notwendig. Die PCI-
        Version wird automatisch erkannt.


     ide0=qd6580
        Prfe und untersttze die qd6580-Schnittstelle.


     ide0=ali14xx
        Prfe und untersttze die ali14xx-Chipstze (ALI M1439/M1445).


     ide0=umc8672
        Prfe und untersttze die umc8672-Chipstze.


  Alles brige wird mit der Nachricht BAD OPTION abgewiesen.



  7.2.  Standard ST-506-Platten-Treiber-Optionen (hd=)


  Der Standard-Plattentreiber kann, hnlich wie der IDE-Treiber,
  Parameter fr die Geometrie von Platten akzeptieren. Man beachte
  jedoch, da er nur drei Werte (C/H/S) erwartet; nur einer mehr oder
  weniger, und der Parameter wird einfach von ihm ignoriert. Er
  akzeptiert auch nur hd= als Argument, d.h. hda=, hdb= usw. sind hier
  nicht gltig.  Das Format sieht folgendermaen aus:



       hd=cyls,heads,sects


  Wenn zwei Platten installiert sind, wird das Obenstehende mit den
  Geometrie-Parametern der zweiten Platte wiederholt.


  7.3.  XT-Platten-Treiber-Optionen (xd=)


  Sollten Sie zu den Unglcklichen gehren, die eine dieser alten 8 Bit-
  Karten verwenden, die Daten keuchend mit 125 kB/s verschieben, dann
  kommt hier der Knller. Der berprfungscode fr diese Karten schaut
  nach einem installierten BIOS. Falls keines vorhanden ist, dann wird
  die Karte nicht erkannt werden. Wenn der Signatur-String Ihres BIOS
  nicht erkannt wurde, wird sie ebenfalls nicht gefunden. In jedem Fall
  wird man dann einen Bootparameter folgender Form verwenden mssen:



       xd=type,irq,iobase,dma_chan




  Der Wert type bestimmt den einzelnen Hersteller der Karte, und zwar
  wie folgt:

    0: generic

    1; DTC

    2, 3, 4: Western Digital

    5, 6, 7: Seagate

    8: OMTI

     Der einzige Unterschied zwischen den verschiedenen Typen desselben
     Herstellers liegt in dem BIOS-String, der fr die Erkennung
     verwendet wird. Dieser wird nicht benutzt, wenn der Typ angegeben
     wurde.

  Die xd_setup()-Funktion berprft die Werte nicht und nimmt an, da
  alle vier Werte eingetragen wurden. Man sollte sie nicht enttuschen.
  Hier ist eine beispielhafte Verwendung fr einen WD1002-Kontroller mit
  ausgeschaltetem bzw. entferntem BIOS, wobei die standardmigen
  Parameter vom XT-Kontroller verwendet werden:



       xd=2,5,0x320,3






  8.  CD-ROMs (nicht-SCSI/-ATAPI/-IDE)


  In diesem Abschnitt werden alle mglichen Bootparameter aufgelistet,
  die zu den CD-ROM-Gerten gehren. Man beachte, da dies nicht fr
  SCSI- oder IDE-/ATAPI-CD-ROMs gilt. Informationen ber diese CD-ROM-
  Typen findet man in den entsprechenden Abschnitten.

  Man beachte, da es fr die meisten dieser CD-ROM-Laufwerke
  Dokumentationsdateien gibt, die man lesen sollte. Sie alle sind
  gnstig plaziert: linux/Documentation/cdrom.
  8.1.

  Die Aztech-Schnittstelle (aztcd=)


  Dieser Kartentyp hat folgende Syntax:



       aztcd=iobase[,magic_number]




  Setzt man magic_number auf 0x79, dann wird der Treiber einen Versuch
  starten und im Falle einer unbekannten Firmware irgendwie laufen. Alle
  brigen Werte werden ignoriert.



  8.2.

  Die CDU-31A- und CDU-33A-Sony-Schnittstelle (cdu31a=)


  Diese CD-ROM-Schnittstelle kann auf einigen der Pro Audio Spectrum
  Soundkarten gefunden werden und auf anderen Schnittstellen-Karten von
  Sony. Die Syntax ist folgendermaen:



       cdu31a=iobase,[irq[,is_pas_card]]




  Setzt man einen IRQ-Wert auf Null, dann wird dem Treiber damit
  mitgeteilt, da die Hardware Interrupts nicht untersttzt, was bei
  einigen PAS-Karten der Fall ist. Untersttzt die eigene Karte
  Interrupts, dann sollte man diese nutzen, da diese die CPU-Last des
  Treibers verringern.

  Falls eine Pro Audio Spectrum verwendet werden soll, mu fr
  is_pas_card die Zeichenkette PAS eingetragen werden.  Andernfalls
  sollte die Option berhaupt nicht bestimmt werden.



  8.3.  Die CDU-535-Sony-Schnittstelle (sonycd535=)


  Diese CD-ROM-Schnittstelle hat folgende Syntax:



       sonycd535=iobase[,irq]




  Fr die iobase kann eine Null als Platzhalter verwendet werden,
  falls man einen IRQ-Wert bestimmen will.




  8.4.

  Die GoldStar-Schnittstelle (gscd=)


  Diese CD-ROM-Schnittstelle hat folgende Syntax:



       gscd=iobase






  8.5.

  Die ISP16-Schnittstelle (isp16=)



  Diese CD-ROM-Schnittstelle hat folgende Syntax:



       isp16=[port[,irq[,dma]]][[,]drive_type]




  Der Wert Null fr irq oder dma besagt, da sie nicht benutzt werden.
  Erlaubte Werte fr drive_type sind noisp16, Sanyo, Panasonic, Sony und
  Mitsumi.  Die Verwendung von noisp16 deaktiviert den gesamten Treiber.



  8.6.

  Die Mitsumi Standard-Schnittstelle (mcd=)


  Diese CD-ROM-Schnittstelle hat folgende Syntax:



       mcd=iobase,[irq[,wait_value]]




  wait_value wird als interner Timeout-Wert fr diejenigen verwendet,
  die Probleme mit ihrem Laufwerk haben. Ob diese Option vorhanden ist,
  kann whrend der Kompilierung des Kernels festgelegt werden.



  8.7.  Die Mitsumi XA-/MultiSession-Schnittstelle (mcdx=)


  Zur Zeit verfgt dieser experimentelle Treiber ber eine Setup-
  Funktion, jedoch sind bis jetzt (seit 1.3.15) keine Parameter
  implementiert. Dieser Treiber ist fr die gleichen Laufwerke wie der
  vorher beschriebene gedacht, allerdings bietet dieser weitere
  Mglichkeiten.

  8.8.

  Die Optics Storage-Schnittstelle (optcd=)


  Dieser Kartentyp hat folgende Syntax:



       optcd=iobase






  8.9.

  Die Philips CM206-Schnittstelle (cm206=)


  Dieser Kartentyp hat folgende Syntax:



       cm206=[iobase][,irq]




  Zahlen zwischen 3 und 11 werden vom Treiber als IRQ-Werte
  interpretiert und Zahlen zwischen 0x300 und 0x370 als I/O Ports, so
  da man eine oder beide Zahlen in beliebiger Reihenfolge angeben kann.
  Der Treiber akzeptiert auch cm206=auto zum Aktivieren der
  automatischen Hardwareerkennung.



  8.10.  Die Sanyo-Schnittstelle (sjcd=)


  Diese Karte hat folgende Syntax:



       sjcd=iobase[,irq[,dma_channel]]






  8.11.

  Die SoundBlaster Pro-Schnittstelle (sbpcd=)


  Diese Karte hat folgende Syntax



       sbpcd=iobase,type




  wobei type einer der folgenden Zeichenketten ist: SoundBlaster,
  LaserMate oder SPEA. Gro- oder Kleinschreibung spielt keine Rolle.
  Die I/O-Basisadresse ist die der CD-ROM-Schnittstelle und nicht die
  des Teils der Karte, der den Sound produziert.



  9.  Serielle Schnittstellen und ISDN

  9.1.



  Der ICN ISDN-Treiber (icn=)


  Dieser ISDN-Treiber erwartet einen Bootparameter folgender Form:



       icn=iobase,membase,icn_id1,icn_id2




  Hierbei ist iobase die Adresse des I/O Ports der Karte und.  membase
  die Startadresse des Shared Memory Bereiches.  Die beiden icn_id Werte
  sind einmalige ASCII-Zeichenketten zur Identifizierung der Karte.



  9.2.


  Der PCBIT ISDN-Treiber (pcbit=)


  Dieser Bootparameter verwendet Paare von Ganzzahlen-Argumenten, z.B.:



       pcbit=membase1,irq1[,membase2,irq2]




  Hierbei ist membaseN die Shared Memory-Basisadresse und irqN der
  Interrup der Nten Karte. Standard ist IRQ 5 und ein eingeblendeter
  Speicher ab Adresse 0xD0000.



  9.3.


  Der Teles ISDN-Treiber (teles=)


  Dieser ISDN-Treiber erwartet einen Bootparameter folgender Form:



       teles=iobase,irq,membase,protocol,teles_id



  iobase ist hierbei die I/O Port Adresse und membase die Shared Memory-
  Basisadresse der Karte; irq ist der von der Karte verwendete Interrupt
  und teles_id ist ein eindeutiger ASCII-String-Bezeichner.


  9.4.


  Der DigiBoard-Treiber (digi=)


  Der DigiBoard-Treiber akzeptiert eine Zeichenkette von sechs durch
  Kommas getrennten Bezeichnern oder Ganzzahlen. Hier die sechs Werte in
  Reihenfolge:


  1. Aktivieren (E) oder Deaktivieren (D) der Karte

  2. Kartentyp: PC/Xi (0), PC/Xe (1), PC/Xeve (2) oder PC/Xem (3)

  3. Aktivieren (E) oder Deaktivieren (D) der wechselnden Pin-Anordnung

  4. Anzahl der I/O-Ports dieser Karte

  5. I/O-Port, ber den die Karte konfiguriert wird (hexadezimal, falls
     String-Bezeichner verwendet werden)

  6. Basisadresse des Speicher-Fensters (hexadezimal, falls String-
     Bezeichner verwendet werden)

  Hier ein Beispiel eines korrekten Bootparameters sowohl in Bezeichner-
  als auch in Ganzzahlen-Form:



       digi=E,PC/Xi,D,16,200,D0000
       digi=1,0,0,16,512,851968




  Man beachte, da der Treiber standardmig den I/O-Port 0x200 und die
  Shared Memory-Basisadresse 0xD0000 voreingestellt hat, falls kein
  digi= Bootparameter angegeben wurde. Es wird keine automatische
  Hardwareerkennung durchgefhrt. Weitere Informationen findet man in
  der Datei linux/Documentation/digiboard.txt.



  9.5.


  Der RISCom/8 Multiport Seriell-Treiber (riscom8=)


  Bis zu vier Karten werden untersttzt, indem man vier eindeutige I/O
  Port-Werte fr jede einzelne Karte angibt. Weitere Informationen
  findet man in der Datei linux/Documentation/riscom8.txt.



  9.6.



  Das Baycom Seriell/Parallel Radio Modem (baycom=)
  Der Bootparameter fr diese Gerte hat folgendes Format:



       baycom=modem,io,irq,options[,modem,io,irq,options]




  Die Verwendung von modem=1 bedeutet, da man das ser12-Gert hat,
  modem=2 bedeutet, man hat das par96-Gert. options=0 bedeutet die
  Verwendung von Hardware-DCD, und options=1 bedeutet die Verwendung von
  Software-DCD. io und irq sind wie gewhnlich die I/O Port-Basisadresse
  und der Interrupt.  Weitere Informationen findet man in der Datei
  README.baycom, die sich zur Zeit im Verzeichnis /linux/drivers/char/
  befindet.



  10.  Andere Hardware-Gerte


  Alle brigen Gerte, die nicht in eine der oben erwhnten Kategorien
  passen, wurden hier zusammengefat.


  10.1.

  Ethernet-Gerte (ether=)


  Unterschiedliche Treiber verwenden unterschiedliche Parameter.  Ihnen
  allen gemeinsam ist, da sie alle ber einen IRQ-Wert, einen Wert der
  I/O Port-Basisadresse und einen Namen verfgen. In seiner
  allgemeinsten Form schaut dies in etwa so aus:



       ether=irq,iobase[,param_1[,param_2,...param_8]]],name




  Das erste, nicht numerische Argument wird als Name verwendet.  Die
  param_n Werte haben normalerweise fr jede(n) einzelne Karte bzw.
  Treiber eine unterschiedliche Bedeutung. Typische param_n Werte werden
  zur Bestimmung von Dingen wie der Shared Memory-Adresse, der Auswahl
  der Schnittstelle, der Bestimmung des DMA-Kanal u.. verwendet.

  Dieser Parameter wird am hufigsten dafr eingesetzt, die automatische
  Hardwareerkennung fr eine zweite Ethernetkarte zu erzwingen, da
  standardmig nur nach einer gesucht wird. Dieses erreicht man mit
  einem einfachen Befehl:



       ether=0,0,eth1




  Man beachte, da im obigen Beispiel der Wert Null fr den Interrupt
  und die I/O-Basisadresse den oder die Treiber auffordert, eine
  automatische Hardwareerkennung durchzufhren.


  Falls Sie Module verwenden, sollten sie folgendes bedenken: Oben
  genanntes Kommando wird keine berprfung nach einer zweiten Karte
  erzwingen, wenn der Treiber fr diese Karte zur Laufzeit als Modul
  geladen wird, weil er nicht im Kernel einkompiliert ist. Die meisten
  Linux-Distributionen verwenden ein bloes Kernel-Gerst zusammen mit
  einer groen Auswahl an Treibern in Modulform.

  Das Ethernet HOWTO verfgt ber eine komplette und ausfhrliche
  Dokumentation ber die Verwendung mehrerer Karten und ber die
  spezifische Implementation der param_n Werte bei den jeweiligen
  Treibern.  Interessierten Lesern sei empfohlen, sich in dem
  entsprechenden Abschnitt dieses Dokuments komplette Informationen ber
  ihre spezielle Karte zu holen.



  10.2.


  Der Disketten-Treiber (floppy=)


  Es gibt eine Flle von Optionen fr den Treiber der
  Diskettenlaufwerke, die in der Datei README.fd unter
  linux/drivers/block aufgelistet sind. Diese Datei enthlt zu viele
  Optionen, um sie hier alle nher zu beschreiben. Statt dessen wird nur
  auf die Optionen eingegangen, die eventuell whrend der Installation
  von Linux auf Systemen mit nicht ganz alltglicher Hardware bentigt
  werden.


     floppy=0,daring
        Teilt dem Disketten-Treiber mit, da der Disketten-Controller
        mit Vorsicht behandelt werden soll.


     floppy=thinkpad
        Teilt dem Disketten-Treiber mit, da ein Thinkpad verwendet
        wird.  Thinkpads verwenden eine umgekehrte Konvention fr die
        Leitung, die einen Wechsel der Diskette anzeigt.


     floppy=nodma
        Mit dieser Option wird dem Disketten-Treiber mitgeteilt, da fr
        Datentransfers kein DMA verwendet werden soll. Dieses wird fr
        HP Omnibooks bentigt, die keinen funktionsfhigen DMA-Kanal fr
        den Disketten-Treiber besitzen. Auerdem ist diese Option
        hilfreich, wenn man regelmig die Meldung unable to allocate
        DMA memory erhlt. Von der Verwendung dieser Option mu
        abgeraten werden, falls ein Disketten-Controller ohne einen FIFO
        zum Einsatz kommt. Hierzu zhlen z.B. die Typen 8272A und 82072;
        82072A und sptere Versionen haben hingegen einen FIFO. Der Typ
        des Controllers wird beim Bootvorgang angezeigt. Auerdem wird
        wenigstens ein 486er bentigt, um diese Option verwenden zu
        knnen.


     floppy=broken_dcl
        Die Leitung, die einen Diskettenwechsel anzeigt, soll nicht
        verwendet werden. Statt dessen wird angenommen, da die Diskette
        gewechselt wurde, wenn das Device des Laufwerkes neu geffnet
        wird. Diese Option wird bei einigen Systemen bentigt, bei den
        diese Leitung nicht funktioniert oder nicht vorhanden ist.

        Diese Option sollte jedoch als Notlsung angesehen werden, da
        hierdurch Zugriffe auf das Diskettenlaufwerk nicht zu effizient
        durchgefhrt werden knnen, da der Cache unntigerweise geleert
        werden mu. Auch sind Zugriffe dann nicht ganz so zuverlssig.
        Falls irgendwelche Probleme mit der DCL (Disk Change Line)
        auftauchen, sollte man zuerst immer die Kabelverbindung und die
        Stellung der entsprechenden Jumper berprfen. Allerdings sind
        einige ltere Laufwerke und Notebooks dafr bekannt, da sie
        keine DCL besitzen.


     floppy=debug
        Durch diese Option werden einige zustzliche Meldungen vom
        Kernel ausgegeben, die bei der Fehlersuche ntzlich sein knnen.


     floppy=messages
        Mittels dieser Option werden Meldungen von Kernel ber bestimmte
        Operationen ausgegeben: Wechsel der Diskette, berlufe und
        automatische Erkennung.




  10.3.


  Der Sound-Treiber (sound=)


  Der Treiber fr Soundkarten kann auch Bootparameter annehmen, um die
  hineinkompilierten Werte zu bergehen. Dies wird jedoch nicht
  empfohlen, da es ziemlich komplex ist und die Dokumentation hierzu im
  Kernel auf mysterise Weise verschwunden ist.  Statt dessen sollten
  die Treiber fr die Soundkarten besser als Modul genutzt werden oder
  der Kernel mit den eigenen Werten neu bersetzt werden.

  Falls Sie trotzdem alle dem diesen Parameter benutzen mchten, der vom
  Kernel in der Datei dev_table.c im Verzeichnis linux/drivers/sound
  verarbeitet wird, so sieht der Syntax des Parameters so aus:



       sound=device1[,device2[,device3...[,device11]]]




  Hierbei ist jeder deviceN Wert von folgendem Format ist: 0xDTaaaId.
  Die Bytes werden folgendermaen verwendet:


    D: zweiter DMA-Kanal (Null, wenn nicht vorhanden)

    T: Gerte-Typ: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16,
     7=SB16-MIDI usw. Eine komplette Liste der ersten 26 Typen ist in
     der Datei linux/include/linux/soundcard.h zu finden. Die weiteren
     Typen sind in der Datei linux/drivers/sound/dev_table.h
     nachzulesen.  Bitte vergessen Sie nicht, diese Werte in
     Hexadezimalzahlen umzuwandeln.

    aaa: I/O-Adresse als Hexadezimalzahl

    I: Interrupt als Hexadezimalzahl (i.e 10=a, 11=b, ...)

    d: erster DMA-Kanal


  Wie man sieht, ein ganz schnes Durcheinander. Man ist wohl besser
  beraten, sich, wie empfohlen, Module zu verwenden oder seine eigenen,
  persnlichen Werte hineinzukompilieren. Die Verwendung des
  Bootparameters sound=0 deaktiviert den gesamten Sound-Treiber.


  10.4.



  Der Bus-Maus-Treiber (bmouse=)


  Der Bus-Maus-Treiber akzeptiert nur einen Parameter, und zwar den Wert
  des zu verwendenden Interrupts.



  10.5.  Der MS-Bus-Maus-Treiber (msmouse=)


  Der MS-Maustreiber akzeptiert nur einen Parameter, und zwar den zu
  verwendenden Hardware IRQ-Wert.



  10.6.


  Der Druckertreiber (lp=)


  Mit diesem Parameter kann dem Drucktreiber mitteilen werden, welche
  Ports verwendet werden sollen und welche nicht. Letzteres ist dann
  praktisch, wenn man verhindern will, da der Druckertreiber alle zur
  Verfgung stehenden parallelen Ports beansprucht, so da andere
  Treiber wie z.B. PLIP oder PPA sie statt dessen verwenden knnen.

  Das Argument besteht aus mehreren Paaren von I/O-Adressen und
  Interrupts.  lp=0x3bc,0,0x378,7 verwendet z.B. den Port auf 0x3bc im
  IRQ-losen Polling-Modus, und benutzt IRQ 7 fr den Port auf 0x378. Der
  Port unter 0x278 wrde, falls vorhanden, nicht berprft werden, da
  die automatische Hardwareerkennung nur ohne ein lp=-Argument
  stattfindet. Zum kompletten Deaktivieren des Druckertreibers kann man
  lp=0 verwenden.





  11.  Schlubemerkung


  Sollten Ihnen irgendwelche Tippfehler ins Auge gesprungen sein, oder
  haben Sie veraltete Informationen in diesem Dokument gefunden, dann
  lassen Sie es mich bitte wissen. Es kann schnell mal passieren, da
  etwas bersehen wurde, da der Kernel im Laufe der Jahre doch stark
  gewachsen ist.


  Danke,

  Paul Gortmaker (p_gortmaker@yahoo.com)



