  Linux BootPrompt HOWTO
  Paul Gortmaker (Paul.Gortmaker@anu.edu.au) und Antje Faber
  (af@caldera.de)
  v1.13-2, 1. Februar 1998

  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.

  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.

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

  Man beachte, da die speziellen Bootprompt-Parameter fr Rechner, die
  keine i386 kompatible CPU enthalten (speziell Atari/Amiga), zur Zeit
  undokumentiert sind.



  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.  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.

  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. Das Verzeichnis linux
  findet sich normalerweise unter /usr/src/. 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.3.  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. 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.

  Allgemeine Fragen ber die Systemkonfiguration sollte man an die
  Newsgruppe


       de.comp.os.unix.linux.misc


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



  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





  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 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 als Bootparameter.


  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 ist und der Kernel /linuxrc auf
  diesem RAM-Image 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.
       Man sollte jedoch beachten, da einige Rechner den obersten
       Teil des Speichers als Cache fr das BIOS oder hnliches
       benutzen, so da man mglicherweise nicht wirklich die
       vollen 96 MB belegen kann.  Auch das Gegenteil trifft zu:
       Einige Chipstze werden den physikalischen Speicher, der vom
       BIOS belegt wird, auf den Bereich ber dem Speichermaximum
       abbilden; d.h. der maximale Speicher wird in Wirklichkeit
       z.B. 96 MB + 384 kB betragen. 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.  Die oben
  genannte Warnung hat insofern noch Gltigkeit, da ein 96 MB Rechner
  mit mem=97920k laufen mag, jedoch mit mem=98304k oder mem=96M versagt.


  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.

  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.



  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 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.4.  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.5.  Der Parameter no-scroll


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



  3.5.6.  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.7.  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.8.  Der Parameter reboot=


  Diese Option kontrolliert die Art des Reboots, die Linux beim Reset
  des Rechners ausfhrt. Seit den spten Kerneln der 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.9.  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.10.  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 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.


  4.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.




  4.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.



  4.1.2.  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.



  4.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.



  4.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.


  4.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.


  4.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.



  4.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.



  4.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






  4.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



  4.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.


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


  Bei v2.x Kerneln akzeptiert der BusLogic-Treiber viele Parameter.  Die
  folgende detaillierte Beschreibung ist direkt Leonard N. Zubkoffs
  Treiber in den v2.0 Kernels entnommen.

  Beim BusLogic-Treiber beginnt der Bootparameter mit dem Identifier
  BusLogic=, optional gefolgt von einer durch Komma getrennten
  Ganzzahlenfolge und darauf optional gefolgt von einer durch Komma
  getrennten Stringfolge. Jeder Bootparameter gilt fr einen BusLogic
  Host-Adapter. Bei Systemen, die mehrere BusLogic Host-Adapter
  enthalten, knnen mehrere Bootparameter verwendet werden.

  Die erste angegebene Ganzzahl ist die I/O-Adresse, unter der der Host-
  Adapter angesprochen werden kann. Fehlt diese Angabe, wird der
  Standardwert 0 benutzt. Das bedeutet, dieser Eintrag gilt fr den
  ersten BusLogic-Host-Adapter, der whrend der automatischen
  Hardwareerkennung gefunden wurde.  Wurden irgendwelche I/O-Adressen
  als Bootparameter angegeben, dann wird die automatische
  Hardwareerkennung ausgelassen.

  Die zweite angegebene Ganzzahl legt die Tagged Queue Depth fest, die
  fr Zielgerte, die Tagged Queuing untersttzen, zu verwenden ist.
  Unter der Queue Depth versteht man die Anzahl von SCSI-Kommandos,
  die gleichzeitig als auszufhrend angegeben werden drfen. Fehlt eine
  Angabe, wird standardmig 0 verwendet, d.h. es wird ein automatisch
  bestimmter Wert verwendet, basierend auf der maximalen Queue Depth
  des Host-Adapters und der Anzahl, dem Typ, der Geschwindigkeit und den
  Fhigkeiten der erkannten Zielgerte. Bei Host-Adaptern, die ISA
  Bounce Buffer bentigen, wird die Tagged Queue Depth automatisch
  auf BusLogic_TaggedQueueDepth_BB gesetzt, um ausschweifendes
  Allokieren von DMA Bounce Buffer-Speicher im voraus zu vermeiden.
  Zielgerte, die Tagged Queuing nicht untersttzen, verwenden eine
  Queue Depth von BusLogic_UntaggedQueueDepth.

  Die dritte angegebene Ganzzahl ist die Bus Settle Time in Sekunden.
  Diese gibt die Zeit an, die man zwischen einem Host-Adapter Hard
  Reset, der einen SCSI Bus Reset einleitet, und der Eingabe von SCSI-
  Kommandos wartet. Fehlt eine Angabe, dann wird standardmig 0
  verwendet, d.h. es wird der Wert von BusLogic_DefaultBusSettleTime
  verwendet.

  Die vierte angegebene Ganzzahl sind die Local Options.  Fehlt die
  Angabe, dann wird standardmig 0 verwendet. Man beachte, da Local
  Options nur fr einen bestimmten Host-Adapter gelten.

  Die fnfte angegebene Ganzzahl sind die Global Options. Fehlt die
  Angabe, wird standardmig 0 verwendet. Man beachte, da Global
  Options auf alle Host Adapter angewendet werden.

  Die String-Optionen dienen der Kontrolle ber Tagged Queuing, Error
  Recovery (Fehlerkorrektur) und Host-Adapter-berprfung.

  Die Tagged Queuing-Bestimmung beginnt mit TQ: und erlaubt die
  ausdrckliche Festlegung, ob Tagged Queuing auf Zielgerten, die
  dieses untersttzen, erlaubt ist.  Folgende Optionen zur Bestimmung
  stehen zur Verfgung:



     TQ:Default
        Ob Tagged Queuing erlaubt ist, hngt von der Firmware-Version
        des BusLogic Host-Adapters ab und davon, ob es der Tagged Queue
        Depth-Wert erlaubt, mehrere Kommandos in die Warteschlange zu
        stellen.


     TQ:Enable
        Tagged Queuing wird fr alle Zielgerte auf diesem Host-
        Adapter aktiviert, wobei jegliche Beschrnkungen bergangen
        werden, die ansonsten, basierend auf der Host Adapter Firmware-
        Version auferlegt werden wrden.


     TQ:Disable
        Tagged Queuing wird fr alle Zielgerte auf diesem Host-
        Adapter deaktiviert.


     TQ:<Per-Target-Spec>
        Tagged Queuing wird fr jedes einzelne Zielgert kontrolliert.
        <Per-Target-Spec> ist eine Sequenz aus Y-, N- und X-Zeichen.  Y
        aktiviert Tagged Queuing, N deaktiviert es und X akzeptiert
        den Standardwert, basierend auf der Firmware-Version. Das erste
        Zeichen bezieht sich auf Zielgert 0, das zweite auf Zielgert 1
        usw.; falls die Sequenz aus Y, N und X Zeichen nicht alle
        Zielgerte abdeckt, werden nicht spezifizierte Zeichen als X
        angenommen.

  Man beachte, da das ausdrckliche Verlangen nach Tagged Queuing zu
  Problemen fhren kann; diese Option dient primr dazu, das
  Deaktivieren von Tagged Queuing auf Zielgerten zu ermglichen, die
  es nicht korrekt durchfhren.

  Die Error Recovery Strategy-Spezifikation beginnt mit ER:. Diese
  Option ermglicht es, festzulegen, was fr eine Aktion als Error
  Recovery ausgefhrt werden soll, wenn ResetCommand ausgefhrt wird,
  weil ein SCSI-Kommando nicht erfolgreich beendet werden konnte.
  Folgende Optionen zur Bestimmung stehen zur Verfgung:


     ER:Default
        Ausgehend von der Empfehlung des SCSI-Subsystems wird Error
        Recovery zwischen einem Hard Reset und den Bus Device
        Reset-Optionen whlen.


     ER:HardReset
        Error Recovery wird einen Host-Adapter Hard Reset einleiten,
        was zustzlich einen SCSI Bus Reset verursacht.


     ER:BusDeviceReset
        Error Recovery wird eine Bus Device Reset-Mitteilung zu dem
        jeweiligen Zielgert schicken, das den Fehler verursacht hat.
        Wird noch einmal die Error Recovery fr dieses Zielgert
        eingeleitet und konnte kein SCSI-Kommando an dieses Zielgert
        erfolgreich ausgefhrt werden, seit die Bus Device
        Reset-Nachricht geschickt wurde, dann wird ein Hard Reset
        ausgelst.


     ER:None
        Error Recovery wird unterdrckt. Diese Option sollte nur dann
        gewhlt werden, wenn ein SCSI Bus-Reset oder Bus Device Reset
        das Zielgert veranlat, komplett und unwiderruflich zu
        versagen.


     ER:<Per-Target-Spec>
        Error Recovery wird fr jedes einzelne Zielgert kontrolliert.
        <Per-Target-Spec> ist eine Sequenz aus D-, H-, B- und N-Zeichen.
        Mit D wird das Standardverhalten gewhlt, H steht fr Hard
        Reset, B fr Bus Device Reset und mit N wird None gewhlt.
        Das erste Zeichen bezieht sich auf Zielgert 0, das zweite auf
        Zielgert 1 usw. Werden mit D, H, B und N nicht alle mglichen
        Zielgerte abgedeckt, dann werden undefinierte Zeichen als D
        angenommen.

  Die automatische Hardwareerkennung fr Host-Adapter umfat folgende
  Zeichenketten:



     NoProbe
        Es soll keine berprfung stattfinden; somit werden keine
        BusLogic-Host-Adapter erkannt.


     NoProbeISA
        Die Standard ISA I/O-Adressen werden nicht untersucht; somit
        werden nur PCI-Host-Adapter erkannt.


     NoSortPCI
        PCI-Host-Adapter werden in der vom PCI BIOS bereitgestellten
        Reihenfolge aufgezhlt, wobei die Einstellungen der Option
        AutoSCSI Use Bus And Device # For PCI Scanning Seq. ignoriert
        werden.



  4.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.



  4.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.


  4.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]





  4.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.


  4.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.


  4.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.


  4.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.


  4.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.




  4.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.


  4.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.


  4.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.

  4.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






  4.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)

    Qligic ISP (PCI)



  5.  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.



  5.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.



  5.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.


  5.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






  6.  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.


  6.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.



  6.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.



  6.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.



  6.4.  Die GoldStar-Schnittstelle (gscd=)


  Diese CD-ROM-Schnittstelle hat folgende Syntax:




  gscd=iobase






  6.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.



  6.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.



  6.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.



  6.8.  Die Optics Storage-Schnittstelle (optcd=)


  Dieser Kartentyp hat folgende Syntax:

       optcd=iobase






  6.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.



  6.10.  Die Sanyo-Schnittstelle (sjcd=)


  Diese Karte hat folgende Syntax:



       sjcd=iobase[,irq[,dma_channel]]






  6.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.





  7.  Andere Hardware-Gerte


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


  7.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.



  7.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 Informationen wurden
  direkt dieser Datei entnommen.


     floppy=mask,allowed_drive_mask
        Setzt die Bitmaske der mglichen Laufwerke auf mask.
        Standardmig sind nur die Einheiten 0 und 1 eines jeden Floppy-
        Controllers zugelassen. Dies liegt darin begrndet, da
        bestimmte ungewhnliche Hardware wie z.B. PCI-Motherboards von
        ASUS die Tastatur durch Zugriff auf die Einheiten 2 oder 3
        durcheinanderbringen. Diese Option ist durch die Option cmos
        etwas veraltet.


     floppy=all_drives
        Setzt die Bitmaske der mglichen Laufwerke auf alle Laufwerke.
        Man verwende diese Option, wenn man mehr als zwei Laufwerke an
        einem Floppy-Controller angeschlossen hat.


     floppy=asus_pci
        Die Bitmaske wird so eingestellt, da sie nur die Einheiten 0
        und 1 erlaubt. (Standard)


     floppy=daring
        Teilt den Floppy-Treiber mit, da man einen gut funktionierenden
        Floppy-Controller hat. Dies ermglicht ein effizienteres und
        glatteres Arbeiten, kann jedoch bei bestimmten Controllern
        versagen. Bestimmte Aktionen knnen dadurch beschleunigt werden.


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


     floppy=one_fdc
        Teilt dem Floppy-Treiber mit, da nur ein Floppy-Controller
        vorhanden ist. (Standard)


     floppy=two_fdc oder floppy=address,two_fdc
        Teilt dem Floppy-Treiber mit, da zwei Floppy-Controller
        vorhanden sind. Es wird angenomen, da sich der zweite Floppy-
        Controller auf der Adresse address befindet. Ist keine Adresse
        angegeben, wird 0x370 angenommen.


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


     floppy=0,thinkpad
        Teilt dem Floppy-Treiber mit, da kein Thinkpad vorhanden ist.


     floppy=drive,type,cmos
        Setzt den CMOS-Typ von drive auf type. Zustzlich ist dieses
        Laufwerk in der Bitmaske erlaubt. Dieses ist dann hilfreich,
        wenn mehr als zwei Floppy-Laufwerke vorhanden sind, da im CMOS-
        RAM des BIOSes lediglich die Werte fr zwei Diskettenlaufwerke
        gespeichert werden knnen. Ebenfalls ntzlich ist diese Option,
        wenn das BIOS nicht die Standardtypen benutzt. Wenn cmos fr die
        ersten beiden Laufwerke auf 0 gesetzt wird (Standard), dann wird
        der Floppy-Treiber den physikalischen CMOS-Speicher fr diese
        Laufwerke lesen.


     floppy=unexpected_interrupts
        Gibt einen Warnhinweis aus, wenn ein unerwarteter Interrupt
        erhalten wird. (Standardverhalten)


     floppy=no_unexpected_interrupts oder floppy=L40SX
        Gibt keine Nachricht aus, wenn ein unerwarteter Interrupt
        erhalten wird. Dieses wird auf IBM L40SX Laptops in bestimmten
        Grafikmodi bentigt. Es scheint eine Interaktion zwischen
        Grafikkarte und Floppy zu bestehen. Die unerwarteten Interrupts
        betreffen nur die Performance und knnen beruhigt ignoriert
        werden.



  7.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. Es ist bzw. war in der Datei
  Readme.Linux unter linux/drivers/sound beschrieben. Ein Bootparameter
  folgender Form wird akzeptiert



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




  wobei jeder deviceN Wert von folgendem Format ist: 0xTaaaId, und die
  Bytes folgendermaen verwendet werden:


    T: Gerte-Typ: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16 und
     7=SB16-MPU401

    aaa: I/O-Adresse in hex.

    I: Interrupt in hex (i.e 10=a, 11=b, ...)

    d: DMA-Kanal.

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



  7.4.  Der Bus-Maus-Treiber (bmouse=)


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



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


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



  7.6.  Der Druckertreiber (lp=)


  Bei den Kernelversionen nach 1.3.75 kann man dem Druckertreiber
  mitteilen, 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.



  7.7.  Der ICN ISDN-Treiber (icn=)


  Dieser ISDN-Treiber erwartet einen Bootparameter folgender Form:



       icn=iobase,membase,icn_id1,icn_id2




  wobei iobase die I/O Port-Adresse der Karte ist, membase die
  Startadresse des Shared Memory Speichers ist und die zwei icn_id
  einmalige ASCII-Zeichenketten-Identifier sind.


  7.8.  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 die
  Interrupt-Einstellung der Nten Karte. Standard ist IRQ 5 und ein
  eingeblendeter Speicher ab 0xD0000.



  7.9.  Der Teles ISDN-Treiber (teles=)


  Dieser ISDN-Treiber erwartet einen Bootparameter folgender Form:



       teles=iobase,irq,membase,protocol,teles_id




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


  7.10.  Der DigiBoard-Treiber (digi=)


  Der DigiBoard-Treiber akzeptiert eine Zeichenkette von 6 durch Kommas
  getrennten Bezeichnern oder Ganzzahlen. Hier die 6 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 (in hex, falls
     String-Bezeichner verwendet werden)

  6. Basisadresse des Speicher-Fensters (in hex, 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.



  7.11.  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.



  7.12.  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.



  8.  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 macht nicht viel Mhe, den Text
  durchzugehen.

  Danke,

  Paul Gortmaker (gpg109@rsphy1.anu.edu.au)









