  The Linux BootPrompt-HOWTO
  Par Paul Gortmaker.
  v1.14, 1er Fevrier 1998

  Ce  document  est le BootPrompt-Howto, qui est un condense de tous les
  parametres de boot qui peuvent etre transmis au noyau de LLiinnuuxx lors de
  la  sequence  de  boot. Ceci inclut tous les parametres concernant les
  peripheriques. Une partie traitant de la facon dont le noyau trie  les
  parametres  de  demarrage ainsi qu'un tour d'horizon des logiciels les
  plus repandus pour demarrer le noyau de LLiinnuuxx    sont  aussi  inclues.
  CCeettttee vveerrssiioonn ffrraannccaaiissee aa eettee rreeaalliisseeee ppaarr
   _L_a_u_r_e_n_t _R_E_N_A_U_D (lrenaud@hol.fr).

  11..  IInnttrroodduuccttiioonn

  Le  noyau  a  une  capacite  limitee pour accepter des informations au
  moment du demarrage sous la forme d'une ligne de commande, semblable a
  une  liste  d'arguments  que  vous  pouvez  passer  a un programme. En
  general, ceci est  utilise  pour  donner  au  noyau  des  informations
  concernant  les  parametres du materiel que le noyau n'est pas capable
  de determiner tout seul, ou pour se substituer/ecraser les valeurs que
  le noyau pourrait detecter.

  Cependant, si vous avez juste copie une image du noyau directement sur
  une disquette, (c.a.d  cp zImage /dev/fd0) alors  vous  n'avez  aucune
  chance  de  pouvoir specifier quelque argument que ce soit a ce noyau.
  C'est  pourquoi  beaucoup  d'utilisateurs  de  LLiinnuuxx   utilisent   des
  logiciels  comme  _L_I_L_O  ou  _l_o_a_d_l_i_n qui se chargent de transmettre ces
  arguments au noyau, et de le faire alors demarrer.

  _N_O_T_E _I_M_P_O_R_T_A_N_T_E _P_O_U_R _L_E_S _U_T_I_L_I_S_A_T_E_U_R_S _D_E _M_O_D_U_L_E_S _: Les  parametres  de
  demarrage  en  general, ne s'appliquent qu'aux pilotes de materiel qui
  sont compiles directement dans le noyau.  Ils n'ont  _a_u_c_u_n  _e_f_f_e_t  sur
  les  pilotes  qui  sont  charges  en  tant que modules. La plupart des
  distributions utilisent des modules. Si vous ne  savez  pas,  regardez
  dans   man   depmod   et   man  modprobe  en  suivant  le  contenu  de
  /etc/conf.modules.

  Cette version couvre les distributions du  noyau  jusqu'a  la  v2.0.33
  incluse.  Des informations qui font partie des noyaux en developpement
  jusqu'a la version 2.1.84 sont aussi documentees.

  Le BootPrompt-Howto est edite et mis a jour par :

       Paul Gortmaker, gpg109@rsphy1.anu.edu.au

  [Notez que les parametres de demarrage qui sont specifiques aux  ports
  et  peripheriques non-i386 (ex : Atari/Amiga) ne sont actuellement pas
  documentes.]

  11..11..  RReessppoonnssaabbiilliittee eett CCooppyyrriigghhtt

  Ce document _n_'_e_s_t _p_a_s l'evangile ! Bien que ce  soit  probablement  la
  source  d'information  la  plus  a  jour  que  vous  puissiez trouver.
  Personne n'est responsable de ce qui peut arriver a votre  materiel  a
  part  vous.  Si  votre  materiel  s'enflamme  brusquement  (ce qui est
  quasiment impossible ! ) je ne suis pas responsable. C'est a dire  QUE
  L'AUTEUR  N'EST PAS RESPONSABLE DES DOMMAGES QUI PEUVENT ETRE PRODUITS
  PAR DES ACTIONS RESULTANT D'INFORMATIONS CONTENUES DANS CE DOCUMENT.

  Ce document est soumis au Copyright (c) 1995-1998 de Paul Gortmaker.

  Ce document peut etre copie en respectant les termes de la GNU General
  Public  Licence,  version  2, ci-incluse en reference. Voir le fichier
  linux/COPYING fourni avec le noyau Linux pour plus de details.

  Si vous avez  l'intention  d'incorporer  ce  document  au  sein  d'une
  publication,  merci  de  me  contacter,  et  je  ferai  un effort pour
  m'assurer que vous avez les informations les plus a jour  disponibles.
  Par  le passe, des versions perimees de HOWTO ont ete publiees, ce qui
  a  attriste  les  developpeurs  qui  ont  ete  harceles  de  questions
  auxquelles ils avaient deja repondu dans des versions plus recentes.

  11..22..  DDooccuummeennttaattiioonn AAssssoocciieeee

  Les  documentations  les  plus  a  jour seront toujours les sources du
  noyau. Pas si vite ! Ne soyez pas effrayes. Vous n'avez pas besoin  de
  connaitre  la  programmation  pour  lire  les  commentaires  dans  les
  fichiers source. Par exemple, si vous recherchez un argument qui  peut
  etre  transmis  au pilote AHA1542 SCSI, il vous suffit d'aller dans le
  repertoire  linux/drivers/scsi,  et  de  regarder  dans   le   fichier
  aha1542.c  et dans les cent premieres lignes vous trouverez en anglais
  une description simple et complete des parametres de demarrage que  le
  pilote 1542 peut recevoir.

  Une autre bonne chose seront les fichiers de documentation livres avec
  le noyau lui-meme. Il y en  a  aujourd'hui  pas  mal,  et  la  plupart
  d'entre     eux    peuvent-etre    trouves    dans    le    repertoire
  linux/Documentation   et tous  ses  sous  repertoires.  Le  repertoire
  linux  se  trouve  generalement  dans  /usr/src/. Parfois des fichiers
  README.foo peuvent se trouver dans le repertoire associe  aux  pilotes
  (c.a.d. linux/drivers/XXX/, ou XXX sera scsi, char, ou net.

  Si   vous  avez  trouve  quels  sont  les  parametres  que  vous  avez
  l'intention d'utiliser, et que vous voulez savoir comment  transmettre
  ces  informations  au  noyau,  alors  regardez  la  documentation  qui
  correspond au logiciel que vous utilisez pour demarrer le  noyau  (par
  exemple : LILO ou loadlin). Un bref survol est fourni ci-dessous, mais
  il ne remplace pas  la  documentation  fournie  avec  le  logiciel  de
  demarrage.

  11..33..  LLee ggrroouuppee ddee ddiissccuussssiioonn LLiinnuuxx

  Si  vous  avez  des  questions  sur  la transmission des parametres au
  noyau, s'il vous plait, LISEZ D'ABORD ce document. Si ce  document  et
  les  documents associes qui sont mentionnes ci-dessus ne repondent pas
  a votre (vos) question(s), alors vous pouvez essayer de la (les) poser
  dans  le groupe de discussion LLiinnuuxx (fr.comp.os.linux pour la France).
  Bien sur, il serait bon de lire les messages du groupe avant de  poser
  aveuglement  vos  questions, il se peut que quelqu'un d'autre ait deja
  pose la meme question, ou peut-etre est-ce  une  question  frequemment
  posee  (FAQ).   Un  coup d'oeuil rapide a la FAQ linux avant de poster
  est une _b_o_n_n_e idee. On pourra trouver les FAQ quelque  part,  dans  un
  repertoire proche de celui ou vous avez trouve ce document.

  Les  questions  generales concernant la configuration de votre systeme
  peuvent etre directement posees dans  le  groupe  comp.os.linux.setup.
  Nous  vous  demandons  _s_'_i_l  _v_o_u_s  _p_l_a_i_t  de  respecter  ces  quelques
  recommandations, et de ne pas cross-poster vos demandes dans  d'autres
  groupes.

  11..44..  NNoouuvveelllleess VVeerrssiioonnss ddee ccee DDooccuummeenntt

  Les  nouvelles  versions  (en  anglais)  de  ce  document peuvent etre
  recuperees par FTP  anonyme  sur  le  site  sunsite.unc.edu,  dans  le
  repertoire  /pub/Linux/docs/HOWTO/.  Notez  que  _S_u_n_S_I_T_E  est  souvent
  surcharge, donc il vaudrait mieux aller chercher ce  document  sur  un
  des sites ftp miroir de Linux.

  Ces  documents en langue francaise se trouvent sur le site ftp.lip6.fr
  dans de repertoire /pub/linux/french/docs/HOWTO.

  Des  mises  a  jour  seront  faites  chaque  fois  que  de   nouvelles
  informations  /  pilotes seront disponibles. Si la copie que vous etes
  en train de lire date de plus de  quelques  mois,  il  serait  bon  de
  verifier qu'il n'en existe pas une version plus recente.

  Ce  document  est  produit  en  utilisant le systeme SGML specialement
  concu pour le projet LLiinnuuxx Howto, et il existe differents  formats  de
  sortie disponibles : postscript, dvi, ascii, html, et bientot TeXinfo.

  Je vous recommande de visualiser ce document en HTML (via un  logiciel
  de  navigation  WWW  )  ou  dans  le format PostScript/dvi.  Tous deux
  contiennent  les  references  croisees  qui  sont  perdues  dans   les
  conversions en ASCII.

  Si vous voulez obtenir la copie officielle de sunsite, voici l'URL.

  BootPrompt-HOWTO         <http://sunsite.unc.edu/mdw/HOWTO/BootPrompt-
  HOWTO.html>

  22..  VVuuee dd''EEnnsseemmbbllee ddeess PPaarraammeettrreess ddee DDeemmaarrrraaggee

  Cette partie donne un  certain  nombre  d'exemples  de  logiciels  qui
  peuvent  etre utilises pour transmettre les parametres de demarrage au
  noyau. Elle donne aussi une idee de la facon dont les parametres  sont
  traites,  quelles sont les limitations des parametres de demarrage, et
  la facon dont ils sont repartis vers chaque peripherique pour lesquels
  ils ont ete concus.

  Il est _i_m_p_o_r_t_a_n_t de noter que l'on _n_e _p_e_u_t _p_a_s utiliser d'espaces dans
  un  parametre  de  demarrage,  mais  seulement  entre  des  parametres
  differents.  Une  liste  de  valeurs correspondant a un seul parametre
  doit utiliser des virgules  comme  separateur  entre  les  differentes
  valeurs, la aussi, sans aucun espace. Voir les exemples ci-dessous.

  ______________________________________________________________________
          ether=9,0x300,0xd0000,0xd4000,eth0  root=/dev/hda1            *BON*
          ether = 9, 0x300, 0xd0000, 0xd4000, eth0  root = /dev/hda1    *MAUVAIS*
  ______________________________________________________________________

  22..11..  LLIILLOO ((LLIInnuuxx LLOOaaddeerr))

  Le  programme  LILO (LInux LOader) ecrit par Werner Almesberger est le
  plus couramment utilise. Il  a  la  capacite  de  demarrer  differents
  noyaux,  et  stocke  les informations de configuration dans un fichier
  contenant  exclusivement  du   texte.    Beaucoup   de   distributions
  fournissent  LILO  comme "boot-loader" (chargeur de noyau) par defaut.
  LILO  peut  demarrer  DOS,  OS/2,  LLiinnuuxx,  FreeBSD,  etc.  sans  aucun
  probleme, et il est tres souple.

  Une  configuration  classique est d'avoir LILO qui arrete le demarrage
  et affiche LILO: peu  de  temps  apres  que  vous  ayez  allume  votre
  ordinateur.   Il   attendra  alors  quelques  instants  en  vue  d'une
  eventuelle saisie de  l'utilisateur,  faute  de  quoi  il  lancera  le
  systeme d'exploitation par defaut. Les etiquettes couramment utilisees
  dans les fichiers de configuration de LILO  sont  linux  ,  backup  et
  msdos.  Si  vous  desirez  entrer  un  parametre de demarrage, vous le
  taperez ici, apres avoir entre l'etiquette du systeme que vous  voulez
  que LILO lance, comme indique dans l'exemple ci-dessous.

  ______________________________________________________________________
          LILO: linux root=/dev/hda1
  ______________________________________________________________________

  LILO  est  fourni  avec  une  documentation  excellente,  et  pour les
  parametres de demarrage dont nous parlons ici, la commande append=  de
  LILO  est  d'une  tres  grande importance lorsque l'on veut ajouter un
  parametre  de  demarrage  de  facon  permanente  dans  le  fichier  de
  configuration  de  LILO.  Vous  ajoutez  tout simplement quelque chose
  comme append = "foo=bar"  dans  le  fichier  /etc/lilo.conf.  On  peut
  l'ajouter  soit  en  haut  du  fichier  de  configuration,  afin qu'il
  s'applique a toutes les sections, ou dans une section correspondant  a
  un  systeme  particulier en le mettant dans une section image=.  Voyez
  la documentation de LILO pour une description plus complete.

  22..22..  LLooaaddLLiinn

  L'autre chargeur de noyau couramment utilise est `LoadLin' qui est  un
  programme  DOS  qui  est  capable de lancer un noyau LLiinnuuxx a partir du
  prompt du dos (avec des parametres  de  demarrage)  en  supposant  que
  certaines  ressources  sont  disponibles.  Ceci est tres bien pour les
  gens qui utilisent le DOS et qui veulent basculer sur LLiinnuuxx  a  partir
  du DOS.

  C'est  aussi  tres  pratique  si  vous  possedez  du  materiel qui est
  dependant du pilote fourni pour le DOS afin de mettre le materiel dans
  un  etat  donne.  Un  exemple  frequent : les cartes son `SoundBlaster
  Compatible' qui requierent un pilote DOS pour positioner  un  ensemble
  de   registres  proprietaires  pour  mettre  la  carte  dans  un  mode
  compatible SoundBlaster. Demarrez le DOS avec  le  pilote  requis,  et
  maintenant chargez LLiinnuuxx a partir du prompt du DOS avec LOADLIN.EXE en
  esquivant la remise a zero de la carte qui intervient si on  redemarre
  completement  la machine. De cette facon, la carte est laissee dans le
  mode compatible SB et par consequent est utilisable sous LLiinnuuxx.

  Il y a aussi  d'autres  programmes  qui  peuvent  etre  utilises  pour
  demarrer LLiinnuuxx. Pour une liste complete, regardez sur votre miroir ftp
  LLiinnuuxx  local,  les   programmes   disponibles   dans   le   repertoire
  system/Linux-boot/.

  22..33..  LL''uuttiilliittaaiirree ````rrddeevv''''

  Un  certain  nombre  des  parametres  de  demarrage du noyau ont leurs
  valeurs par defaut stockees  dans  differents  octets  de  l'image  du
  noyau.  Il  existe  un utilitaire baptise rdev qui est installe sur la
  plupart des systemes et qui sait ou sont ces valeurs, et  comment  les
  changer.  Il  peut  aussi  modifier un certain nombre de choses qui ne
  possedent pas de parametre de  demarrage  equivalent,  comme  le  mode
  video utilise par defaut.

  L'utilitaire  rdev  est couramment associe a swapdev, ramsize, vidmode
  et rootflags. Les cinq parametres que rdev peut  modifier  sont  :  le
  peripherique  de demarrage, le peripherique de swap, les parametres du
  disque RAM, le mode video par defaut, et  l'autorisation  de  lecture-
  seule/lecture-ecriture sur le peripherique racine.

  Des  informations  plus  completes  sur  rdev peuvent etre obtenues en
  tapant rdev -h ou en lisant la page correspondante  du  manuel  fourni
  (man rdev).

  22..44..  CCoommmmeenntt llee nnooyyaauu ggeerree tt--iill lleess ppaarraammeettrreess ??

  La plupart des parametres de demarrage utilisent la syntaxe suivante :

  ______________________________________________________________________
          nom[=valeur_1][,valeur_2]...[,valeur_11]
  ______________________________________________________________________

  ou `nom' est un mot cle unique qui  est  utilise  pour  reconnaitre  a
  quelle  partie  du noyau sont destinees les valeurs associees (si il y
  en a). Plusieurs parametres de demarrage peuvent  etre  transmis  sous
  forme d'une liste d'elements, comme celle situe ci-dessus, separes par
  des espaces. Notez que la limite de 11 parametres  est  reelle,  c'est
  pourquoi  le  code ci-dessus ne comporte que 11 parametres separes par
  des virgules pour un mot cle. Toutefois,  vous  pouvez  reutiliser  le
  meme  mot  cle  avec  11  parametres  de plus dans des situations tres
  complexes, en  sachant  que  ceci  est  accepte  par  la  fonction  de
  configuration. Notez aussi que le noyau partage la liste en un maximum
  de 10 parametres entiers, et une chaine de caracteres accompagnatrice,
  donc vous pouvez reellement fournir 11 entiers, dans la mesure ou vous
  assurez la conversion du 11eme parametre, de chaine en entier, dans le
  pilote lui meme.

  La  plupart  sont pris en charge par linux/init/main.c.  Tout d'abord,
  le noyau cherche a voir si le parametre  fait  partie  des  parametres
  speciaux  comme  `root=', `ro', `rw', ou `debug'.  La signification de
  ces parametres speciaux est decrite plus loin dans ce document.

  Il parcourt alors une liste de fonctions de  configuration  (contenues
  dans le tableau bootsetups) pour voir si la chaine parametre specifiee
  (comme  par  exemple  `foo')  a  ete  associee  a  une   fonction   de
  configuration  (foo_setup())  pour  un peripherique particulier ou une
  partie du noyau. Si vous passez  au  noyau  la  ligne  foo=3,4,5,6,bar
  alors,  il  cherchera  dans le tableau bootsetups pour voir si `foo' y
  figure.  S'il  y  est,  alors  il  pourra  appeler  la   fonction   de
  configuration  associee a `foo' (foo_setup()) et prendra en charge les
  parametres 3, 4, 5 et 6 tels qu'ils  sont  donnes  dans  la  ligne  de
  commande  adressee  au  noyau,  et traitera aussi le parametre de type
  chaine bar.

  22..55..  PPoossiittiioonnnneemmeenntt ddeess VVaarriiaabblleess dd''EEnnvviirroonnnneemmeenntt..

  Quelque chose du type `foo=bar',  qui  n'est  pas  accepte  comme  une
  fonction  de  configuration  telle  qu'elle est decrite ci-dessus, est
  interpretee comme une  variable  d'environnement  a  positionner.   Un
  exemple  (inutile ?) serait d'utiliser `TERM=vt100' comme parametre de
  demarrage.

  22..66..  PPaasssseerr ddeess ppaarraammeettrreess aauu pprrooggrraammmmee ``iinniitt''

  Tous les parametres restants qui ne sont pas pris par le noyau et  qui
  ne  sont pas consideres comme etant des variables d'environnement sont
  transmis au processus initial, qui est generalement le programme init.
  Le  parametre  le  plus  couramment passe au processus init est le mot
  _s_i_n_g_l_e qui demande a init  de  demarrer  l'ordinateur  en  mode  mono-
  utilisateur,  et  de  ne  pas lancer les "daemons" (demons) habituels.
  Regardez la  page  du  manuel  correspondant  a  la  version  de  init
  installee   sur  votre  systeme,  afin  de  connaitre  les  parametres
  acceptes.

  33..  PPaarraammeettrreess GGeenneerraauuxx nnoonn ssppeecciiffiiqquueess aa uunn PPeerriipphheerriiqquuee

  Voici des  parametres  qui  ne  sont  pas  lies  a  des  peripheriques
  particuliers.  Ils  sont  simplement  lies  a  un  certain  nombre  de
  parametres internes au noyau,  comme  la  gestion  memoire,  celle  du
  disque RAM, celle du systeme de fichiers racine, etc.

  33..11..  OOppttiioonnss dduu ssyysstteemmee ddee ffiicchhiieerrss rraacciinnee

  Les  options  suivantes  determinent  toutes  la  facon  dont le noyau
  selectionne et manipule le systeme de fichiers racine.

  33..11..11..  LLee ppaarraammeettrree ``rroooott==''

  Ce parametre indique au noyau  quel  peripherique  doit  etre  utilise
  comme  "root  filesystem"  (racine  du systeme de fichiers) pendant le
  demarrage. Par defaut, c'est le peripherique  racine  du  systeme  sur
  lequel le noyau a ete construit.  Par exemple, si le noyau en question
  a ete construit sur un systeme qui utilise `/dev/hda1' comme partition
  racine, alors le peripherique racine par defaut sera `/dev/hda1'. Pour
  outrepasser  cette  valeur  et  selectionner  le  second  lecteur   de
  disquette comme peripherique racine, il faut utiliser `root=/dev/fd1'.
  Les peripheriques racine valides sont un des peripheriques suivants :

  (1) /dev/hdaN a /dev/hddN, ou N est la partition pour les disques `a a
  d' compatibles ST-506.

  (2) /dev/sdaN a /dev/sdeN, ou N est la partition pour les disques `a a
  e' compatibles SCSI.

  (3) /dev/xdaN a /dev/xdbN, ou N est la partition pour les disques `a a
  b' compatibles XT.

  (4)  /dev/fdN,  ou  N est le numero du lecteur de disquette. La valeur
  N=0 correspond au disque DOS `A:', et N=1 correspond a `B:'.

  (5) /dev/nfs, qui n'est pas vraiement un peripherique, mais plutot  un
  indicateur  pour  dire  au  noyau de rechercher le systeme de fichiers
  racine via le reseau.

  La plus maladroite et  la  moins  compatible  des  specifications  des
  peripheriques disque ci-dessus, qui est le format nombre majeur/nombre
  mineur est aussi acceptee (par exemple /dev/sda3 a pour  major  8,  et
  pour minor 3, vous pouvez donc utiliser root=0x803 comme alternative).

  C'est un des parametres de  demarrage  qui  a  sa  valeur  par  defaut
  stockee  dans  l'image  du  noyau, et qui peut etre aussi modifiee par
  l'utilitaire rdev.

  33..11..22..  LLee ppaarraammeettrree ``rroo''

  Quand le noyau demarre, il a besoin du  systeme  de  fichiers  racine,
  pour  enumerer  les elements de base de celui-ci.  C'est le systeme de
  fichiers racine qui est monte au demarrage.  Cependant, si le  systeme
  de  fichiers  racine  est  monte  avec  un  acces en ecriture, vous ne
  pourrez pas controler  de  facon  fiable  l'integrite  du  systeme  de
  fichiers,  car  il  peut  y  avoir  des  fichiers en cours d'ecriture.
  L'option `ro' indique au noyau de monter le systeme de fichiers racine
  en lecture seule, de facon que les programmes de controle de coherence
  du systeme de fichiers (fsck) puissent etre certain qu'il  n'y  a  pas
  d'ecritures  en  cours  pendant  la  duree du test. Aucun programme ou
  processus ne peut ecrire dans les fichiers situes sur  le  systeme  de
  fichiers  en question jusqu'a ce qu'il ait ete `remonte' avec un acces
  en lecture/ecriture.

  C'est un des parametres de  demarrage  qui  a  sa  valeur  par  defaut
  stockee  dans  l'image  du  noyau, et qui peut etre aussi modifiee par
  l'utilitaire rdev.

  33..11..33..  LLee ppaarraammeettrree ``rrww''

  Ceci est le contraire le plus parfait de ce qui precede, c'est a  dire
  que  ce  parametre  indique  au  noyau de monter le systeme de fichier
  racine en lecture/ecriture. N'executez surtout  pas  un  programme  de
  type `fsck' sur un systeme de fichiers monte en lecture/ecriture.

  La  meme  valeur stockee dans le fichier image mentionne ci-dessus est
  aussi accessible via rdev

  33..22..  OOppttiioonnss lliieeeess aa llaa ggeessttiioonn ddeess ddiissqquueess vviirrttuueellss ((ddiissqquueess RRAAMM))

  Les  options  suivantes correspondent a la facon dont le noyau gere le
  peripherique disque  virtuel,  qui  est  souvent  utilise  comme  zone
  d'amorcage  durant  la  phase d'installation, ou pour des machines qui
  utilisent des pilotes  modulaires  qui  doivent  etre  installes  pour
  acceder au systeme de fichiers racine.

  33..22..11..  LLee ppaarraammeettrree ``rraammddiisskk__ssttaarrtt==''

  Pour  permettre  a  une  image  du  noyau  de loger sur une disquette,
  conjointement avec une image compressee du disque virtuel, la commande
  `ramdisk_start=<offset>' est ajoutee. Le noyau ne peut pas etre inclus
  dans l'image compressee du systeme de fichiers du disque virtuel,  car
  il  doit  etre  stocke a partir du bloc zero de facon a ce que le BIOS
  puisse charger le secteur d'amorce (bootsector) et que le noyau puisse
  alors s'auto-lancer.

  Note  :  Si  vous utilisez une image du disque virtuel non compressee,
  alors le noyau peut faire partie de l'image du systeme de fichiers qui
  est  charge  sur  le  disque virtuel, et la disquette peut-etre lancee
  avec LILO, ou les deux peuvent etre distincts comme  c'est  fait  pour
  les images compressees.

  Si  vous utilisez deux disques boot/root (noyau sur le disque 1, image
  u disque virtuel sur le disque 2) alors, le disque  virtuel  demarrera
  au  bloc zero, et un deplacement (offset) de zero sera utilise.  Etant
  donne que  c'est  la  valeur  par  defaut,  vous  n'aurez  pas  besoin
  actuellement d'utiliser cette commande.

  33..22..22..  LLee ppaarraammeettrree ``llooaadd__rraammddiisskk==''

  Ce  parametre  indique  au  noyau si il essaye de charger une image du
  disque virtuel ou pas. En specifiant `load_ramdisk=1' on indiquera  au
  noyau  de  charger une disquette dans le disque virtuel. La valeur par
  defaut est zero, ce qui  signifie  que  le  noyau  n'essaiera  pas  de
  charger un disque virtuel.

  Voyez  le fichier linux/Documentation/ramdisk.txt pour une description
  complete  des  nouveaux  parametres  de  demarrage,  et  comment   les
  utiliser.  La  facon  dont  ces parametres peuvent etre positionnes et
  stockes dans l'image du noyau via 'rdev' est aussi decrite.

  33..22..33..  LLee ppaarraammeettrree ``pprroommpptt__rraammddiisskk==''

  Ce parametre indique  au  noyau  si  il  doit  ou  non  vous  demander
  d'inserer  la  disquette contenant l'image du disque virtuel. Dans une
  configuration a une seule disquette, l'image du disque virtuel est sur
  la meme disquette que le noyau qui vient juste de se charger/demarrer,
  et donc un message d'invite est inutile. Dans ce cas, on peut utiliser
  `prompt_ramdisk=0'.  Dans une configuration avec deux disquettes, vous
  devez  avoir  la  possibilite  de  changer  de  disquette,  et   alors
  `prompt_ramdisk=1'  peut-etre utilise. Etant donne que c'est la valeur
  par defaut, on n'a pas vraiment besoin de l'indiquer.

  Note Historique : Des gens sournois on l'habitude d'utiliser  l'option
  de  LILO  `vga=ask'  pour stopper temporairement le demarrage et avoir
  ainsi une chance de pouvoir passer de la disquette boot a la disquette
  root.

  Voyez  le fichier linux/Documentation/ramdisk.txt pour une description
  complete  des  nouveaux  parametres  de  demarrage,  et  comment   les
  utiliser.  La  facon  dont  ces parametres peuvent etre positionnes et
  stockes dans l'image du noyau via 'rdev' est aussi decrite.

  33..22..44..  LLee ppaarraammeettrree ``rraammddiisskk__ssiizzee==''

  Bien que ce soit vrai que le disque  virtuel  augmente  sa  taille  de
  facon dynamique, il existe une limite maximum afin qu'il n'utilise pas
  toute la memoire vive (RAM) disponible et vous laisse dans une  triste
  situation.  Par  defaut,  la  taille est de 4096 (c.a.d. 4MB) qui doit
  etre suffisant pour la plupart des besoins. Vous pouvez ecraser  cette
  taille  par  defaut  pour  une  plus grande ou une plus petite avec ce
  parametre de demarrage.
  Voyez le fichier linux/Documentation/ramdisk.txt pour une  description
  complete   des  nouveaux  parametres  de  demarrage,  et  comment  les
  utiliser. La facon dont ces parametres  peuvent  etre  positionnes  et
  stockes dans l'image du noyau via 'rdev' est aussi decrite.

  33..22..55..  LLee ppaarraammeettrree ``rraammddiisskk=='' ((oobbssoolleettee))

  NOTE  :  Ce parametre est obsolete, et ne doit pas etre utilise exepte
  sur les noyaux v1.3.47 et ceux plus anciens. Les  commandes  que  l'on
  peut utiliser pour les disques virtuels sont documentees ci-dessous.

  Ceci indique la taille en Kilo-Octets du disque virtuel (RAM disk) que
  vous pouvez eventuellement utiliser. Par exemple,  si  vous  souhaitez
  avoir  un  systeme de fichiers racine sur une disquette 1.44 Mo charge
  sur le disque virtuel, vous devrez utiliser :

  ______________________________________________________________________
          ramdisk=1440
  ______________________________________________________________________

  C'est un des parametres de  demarrage  qui  a  sa  valeur  par  defaut
  stockee  dans  l'image  du  noyau,  et qui peut etre aussi modifie par
  l'utilitaire rdev.

  33..22..66..  LLee ppaarraammeettrree ``nnooiinniittrrdd'' ((ddiissqquuee RRAAMM iinniittiiaall))

  La version v2.x  du noyau et les versions plus recentes  possedent  la
  caracteristique  de  pouvoir  avoir  le  systeme  de  fichiers  racine
  initialement sur un disque virtuel, et le noyau  execute  linuxrc  sur
  cette  image  memoire. Cette caracteristique est generalement utilisee
  pour permettre de  charger  des  modules  necessaires  au  montage  du
  systeme  de fichiers racine reel (par exemple : charger les modules du
  pilote SCSI stockes dans l'image du disque virtuel, et alors monter le
  systeme de fichiers racine reel sur un disque SCSI).

  Le  parametre  `noinitrd'  actuel  determine ce qui arrive aux donnees
  initrd apres que le noyau ait demarre. Lorsqu'il est indique, au  lieu
  de  se convertir en disque virtuel, il est accessible via /dev/initrd,
  et peut-etre lu juste avant que la RAM soit liberee pour  le  systeme.
  Pour  de  plus amples details sur l'utilisation du disque RAM initial,
  consultez linux/Documentation/initrd.txt.  De plus, les  versions  les
  plus  recentes  LILO  et  LOADLIN  doivent  contenir  des informations
  complementaires tres interessantes.

  33..33..  PPaarraammeettrreess ddee DDeemmaarrrraaggee rreellaattiiffss aa llaa GGeessttiioonn ddee llaa MMeemmooiirree..

  Les  parametres suivants modifient la facon dont linux detecte ou gere
  la memoire physique et virtuelle de votre systeme.

  33..33..11..  LLee ppaarraammeettrree ``mmeemm==''

  Ce parametre vise deux objectifs : L'objectif principal est d'indiquer
  la  quantite  de  memoire installee (ou une valeur plus petite si vous
  desirez limiter le quantite de  memoire  disponible  pour  linux).  Le
  second  ojectif  (tres  utilise)  est  de  specifier mem=nopentium qui
  indique au noyau de linux de ne pas utiliser les  caracteristiques  de
  la table de performance de pages de 4 MO (4MB page table performance).

  L'appel initial au BIOS defini dans la specification des  PC,  et  qui
  renvoie  la  taille  de  la  memoire  installee, a ete concu pour etre
  capable de donner des tailles memoire jusqu'a 64 Mo  (He  oui,  encore
  une   manque   de   prevoyance,   tout   comme  les  disques  de  1024
  cylindres...Pfffff). Linux utilise cet appel au BIOS au demarrage pour
  determiner  quelle  est la quantite de memoire installee. Si vous avez
  plus de 64 Mo de memoire  vive  installee,  vous  pouvez  utiliser  ce
  parametre de demarrage pour indiquer a Linux quelle est la quantite de
  memoire  dont  vous  disposez.  Voici  une  citation  de   Linus   sur
  l'utilisation du parametre `mem='.

  "Le  noyau  acceptera  tous  les  parametres  `mem=xx'  que  vous  lui
  donnerez, et s'il s'apercoit que vous  lui  avez  menti,  il  plantera
  lamentablement  tot  ou  tard. Le parametre indique la plus haute zone
  adressable, donc `mem=0x1000000' signifie  que  vous  avez  16  Mo  de
  memoire,  par  exemple.   Pour  une machine ayant 96 Mo de memoire, le
  parametre serait `mem=0x6000000'."

  NOTE NOTE NOTE: certaines machines peuvent utiliser le  sommet  de  la
  memoire pour le cache du BIOS ou quelque chose d'autre, c'est pourquoi
  il se peut que vous n'ayez pas vraiment la totalite de ces 96 Mo comme
  memoire  adressable.  Le  contraire  est aussi exact : certaines puces
  feront un plan de la memoire physique couverte par la zone  BIOS  dans
  la zone situee juste au dessus du sommet de la memoire, donc le sommet
  de la memoire peut etre actuellement 96Mo +  384ko  par  exemple.   Si
  vous  indiquez  a  LLiinnuuxx  qu'il  a plus de memoire qu'il doit en avoir
  actuellement, des choses plutot desagreables vous arriveront  :  peut-
  etre pas tout de suite, mais un jour surement.''

  Notez  que  cet  argument n'a pas besoin d'etre en hexadecimal, et que
  les suffixes `k' et `M'  (en  majuscule  ou  minuscule,  peu  importe)
  peuvent  etre  utilises  pour  indiquer  respectivement kilo-octets et
  Mega-octets (le `k' multiplie  par  10  votre  valeur  et  le  `M'  la
  multiplie  par 20).  La mise en garde exposee ci-dessus reste vraie en
  cela qu'une machine avec 96 Mo peut fonctionner avec  mem=97920k  mais
  echouer avec soit mem=98304k ou mem=96M.

  33..33..22..  LLee ppaarraammeettrree ``sswwaapp==''

  Il  permet  a  l'utilisateur  de  regler certains des parametres de la
  memoire virtuelle qui sont lies  aux  fichiers  d'echange  (swap)  sur
  disque.  Il accepte les huit parametres suivants :

  ______________________________________________________________________
          MAX_PAGE_AGE
          PAGE_ADVANCE
          PAGE_DECLINE
          PAGE_INITIAL_AGE
          AGE_CLUSTER_FRACT
          AGE_CLUSTER_MIN
          PAGEOUT_WEIGHT
          BUFFEROUT_WEIGHT
  ______________________________________________________________________

  Les  utilisateurs  avertis  pourront  jeter un coup d'oeuil au fichier
  linux/mm/swap.c et sur les donnees du repertoire /proc/sys/vm.

  33..33..33..  LLee ppaarraammeettrree ``bbuuffff==''

  Comme le parametre  `swap=',  il  permet  a  l'utilisateur  de  regler
  certains des parametres relatifs a la gestion des tampons memoire.  Il
  accepte les six parametres suivant :

  ______________________________________________________________________
          MAX_BUFF_AGE
          BUFF_ADVANCE
          BUFF_DECLINE
          BUFF_INITIAL_AGE
          BUFFEROUT_WEIGHT
          BUFFERMEM_GRACE
  ______________________________________________________________________

  Les utilisateurs avertis pourront jeter un  coup  d'oeuil  au  fichier
  linux/mm/swap.c et sur les donnees du repertoire /proc/sys/vm.

  33..44..  PPaarraammeettrreess ddee ddeemmaarrrraaggee ppoouurr lleess ssyysstteemmeess ddee ffiicchhiieerrss rraacciinnee NNFFSS

  Linux supporte des systemes comme les stations de travail sans disques
  a condition que leur systeme de  fichiers  racine  soit  de  type  NFS
  (Network  FileSystem  ou  Systeme de Fichiers Reseau).  Ces parametres
  sont utilises pour indiquer a la station exempte de disque sur  quelle
  machine  elle  doit  aller  chercher  son systeme.  Notez aussi que le
  parametre root=/dev/nfs est requis.  Des informations  detaillees  sur
  l'utilisation  d'un systeme de fichiers racine NFS sont contenues dans
  linux/Documentation/nfsroot.txt. Je vous conseille de lire ce fichier,
  car  ce  qui suit est juste un resume rapide extrait directement de ce
  document.

  33..44..11..  LLee ppaarraammeettrree ``nnffssrroooott==''

  Ce parametre indique au  noyau  quelle  machine,  quel  repertoire  et
  quelles  options  NFS  sont  utilisees  pour  son  systeme de fichiers
  racine.  La structure du parametre est la suivante :

  ______________________________________________________________________
          nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
  ______________________________________________________________________

  Si le parametre nfsroot n'est pas donne sur la ligne de  commande,  on
  utilisera  par  defaut  `/tftpboot/%'.  Les  autres  options  sont les
  suivantes :

  <server-ip> - Indique l'adresse IP du serveur NFS. Si ce  champ  n'est
  pas  indique, l'adresse par defaut determinee par la variable nfsaddrs
  (voir ci-dessous) est utilisee. Une des utilisations de  ce  parametre
  est par exemple l'utilisation de serveurs differents pour RARP et NFS.
  Generalement vous pouvez le laisser a blanc.

  <root-dir> - Nom du repertoire sur le serveur a  monter  en  tant  que
  racine.   Si il y a un caractere `%' dans la chaine, le caractere sera
  remplace par la representation ASCII de l'adresse IP du client.

  <nfs-options> - Options NFS standard. Toutes les options sont separees
  par  des  virgules.  Si le champ option n'est pas indique, les valeurs
  suivantes sont utilisees par defaut :

          port            = tel que donne par le demon portmap du serveur
          rsize           = 1024
          wsize           = 1024
          timeo           = 7
          retrans         = 3
          acregmin        = 3
          acregmax        = 60
          acdirmin        = 30
          acdirmax        = 60
          flags           = hard, nointr, noposix, cto, ac

  33..44..22..  LLee ppaarraammeettrree ``nnffssaaddddrrss==''

  Ce parametre de demarrage positionne les differentes adresses qui sont
  necessaires  a  la  communication sur le reseau. Si ce parametre n'est
  pas indique, le noyau essaie d'utiliser RARP et/ou BOOTP pour calculer
  ces parametres. La structure est la suivante :

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

  <my-ip>  -  Adresse IP du client. Si elle est vide, cette adresse sera
  determinee par RARP ou BOOTP. Le protocole utilise depend de ce qui  a
  ete  active  pendant  la  configuration  du  noyau et sur le parametre
  <auto>. Si ce parametre n'est pas vide, ni RARP, ni  BOOTP  ne  seront
  utilises.

  <serv-ip>  -  Adresse  IP  du  serveur  NFS.  Si RARP est utilise pour
  determiner l'adresse du client et que ce  parametre  N'EST  PAS  vide,
  seules  les  reponses  du  serveur  specifie  seront  acceptees.  Pour
  utiliser differents serveurs NFS et RARP, indiquez votre serveur  RARP
  ici  (ou  laissez  le  a blanc), et indiquez votre serveur NFS dans le
  parametre nfsroot (voir ci-dessus).  Si  cette  entree  est  a  blanc,
  l'adresse  utilisee  est celle du serveur qui repond a la requete RARP
  ou BOOTP.

  <gw-ip> - Adresse IP d'une passerelle (gateway) si le serveur est  sur
  un  sous-reseau different. Si cette entree est vide, aucune passerelle
  n'est utilisee et le serveur est suppose etre sur le reseau  local,  a
  moins qu'une valeur n'ait ete recue par BOOTP.

  <netmask>  -  Masque de reseau pour les interfaces de reseau local. Si
  ce parametre est vide, le masque de reseau est deduit de l'adresse  IP
  du client, a moins qu'une valeur n'ait ete recue par BOOTP.

  <name>  -  Nom  du  client. Si il est vide, l'adresse IP du client est
  utilisee en notation ASCII, sauf si une valeur a ete recue par  BOOTP.

  <dev>  -  Nom  du  peripherique reseau a utiliser. Si le parametre est
  vide, tous les peripheriques sont utilises pour les requetes RARP,  et
  le  premier  trouve  pour BOOTP. Pour NFS, le peripherique utilise est
  celui pour lequel on a recu une reponse  a  RARP  ou  BOOTP.  Si  vous
  n'avez  qu'un peripherique, vous pouvez sans aucun risque le laisser a
  blanc.

  <auto> - Methode a utiliser pour  l'autoconfiguration.  Si  `rarp'  ou
  `bootp'  sont  indiques,  le  protocole  specifie  est utilise.  Si la
  valeur est `both' ou vide,  les  deux  protocoles  seront  utilises  a
  condition  qu'ils  aient ete actives durant la configuration du noyau.
  Utiliser 'none' signifie pas d'autoconfiguration; Dans  ce  cas,  vous
  devez   indiquer  toutes  les  valeurs  necessaires  dans  les  champs
  precedents.

  Le parametre <auto> peut apparaitre seul  comme  valeur  du  parametre
  nfsaddrs   (sans   tous  les  caracteres  `:'  avant).  Dans  ce  cas,
  l'autoconfiguration est utilisee. Toutefois, la  valeur  `none'  n'est
  pas disponible dans ce cas.

  33..55..  DD''aauuttrreess ppaarraammeettrreess ddee ddeemmaarrrraaggee ddiivveerrss

  Ces  differents  parametres de demarrage permettent a l'utilisateur de
  gerer certains parametres internes du noyau.

  33..55..11..  LLee ppaarraammeettrree ``ddeebbuugg''

  Le noyau envoie  des  messages  importants  (et  moins  importants)  a
  l'operateur  via  la  fonction  printk().  Si le message est considere
  comme important, la fonction printk() envoie une copie sur la  console
  active, mais le transmet aussi a la fonction klogd() qui l'archive sur
  le disque. La raison pour laquelle le message est envoye a la  console
  et  archive  sur  disque,  est  simple  : dans certaines circonstances
  malheureuses (par exemple une defaillance du  disque)  le  message  ne
  serait pas ecrit sur le disque et serait perdu.

  Le  seuil a partir duquel un message est considere comme important, ou
  ne l'est pas, est determine par  la  variable  console_loglevel.   Par
  defaut,  l'affichage  sur  la  console  est declenche pour tout ce qui
  depasse le DEBUG (niveau 7). Ces niveaux sont definis dans le  fichier
  include  kernel.h.  Le  fait de specifier comme parametre de demarrage
  debug forcera le niveau de suivi a 10, de facon que _t_o_u_s les  messages
  du noyau apparaissent sur la console.

  Le  niveau  de  suivi de la console peut aussi etre positionne pendant
  l'utilisation via une option du programme klogd().  Consultez la  page
  du manuel correspondant a la version installee sur votre systeme, pour
  voir comment utiliser ce programme.

  33..55..22..  LLee ppaarraammeettrree ``iinniitt==''

  Par defaut, le noyau lance le programme `init' au demarrage, qui prend
  alors soin de configurer l'ordinateur pour les utilisateurs en lancant
  les programmes getty, les scripts `rc' et tout  le  reste.   Le  noyau
  recherche  d'abord  /sbin/init,  ensuite /etc/init (secondaire), et en
  dernier  recours,  il  essaiera  d'utiliser  /bin/sh   (eventuellement
  /etc/rc).   Si  par exemple, votre programme init est corrompu et donc
  stoppe vous serez en mesure de demarrer, en utilisant le parametre  de
  demarrage init=/bin/sh qui vous positionnera directement dans un shell
  au demarrage, vous permettant de remplacer les programmes corrompus.

  33..55..33..  LLee PPaarraammeettrree ``nnoo338877''

  Certains coprocesseurs i387 ont des bogues qui apparaissent lorsqu'ils
  sont  utilises  en  mode protege 32 bits. Par exemple, certaines puces
  ULSI-387 recentes, provoquent  un  blocage  irreversible  lorsqu'elles
  font  des  calculs  un virgule flottante, apparemment du a un bug dans
  les  instructions  FRSAV/FRRESTOR.  L'utilisation  du   parametre   de
  demarrage  `no387'  fait  ignorer a LLiinnuuxx le coprocesseur mathematique
  s'il y en a un. Bien sur, votre noyau doit alors obligatoirement  etre
  compile  avec  l'option d'emulation du coprocesseur !  Cela peut aussi
  etre interessant si vous possedez une de ces _t_r_e_s vielles machines 386
  qui peuvent utiliser une FPU 80287, alors que LLiinnuuxx ne peut pas.

  33..55..44..  LLee PPaarraammeettrree ``nnoo--hhlltt''

  La famille des processeurs i386 (et les suivantes) ont une instruction
  `htl' qui indique au processeur que rien ne va se produire jusqu'a  ce
  qu'un  peripherique  externe (clavier, modem, disque, etc.) demande au
  processeur d'accomplir une tache. Ceci  permet  au  processeur  de  se
  mettre  dans  un  mode `low-power' (economie d'energie) dans lequel il
  reste a l'etat de zombi  jusqu'a  ce  qu'un  peripherique  externe  le
  reveille   (generalement   via   une  interruption).  Certaines  puces
  i486DX-100 recentes ont un probleme avec l'instruction `htl'  qui  est
  le  suivant  :  elles ne peuvent pas retourner en mode operationnel de
  facon  fiable  apres  que  cette   instruction   ait   ete   utilisee.
  L'utilisation  de l'instruction `no-hlt' indique a LLiinnuuxx de simplement
  executer une boucle infinie quand il n'y a rien d'autre a faire, et de
  _n_e _p_a_s  arreter votre processeur quand il n'y a aucune activitee. Ceci
  permet aux personnes qui utilisent ces puces  defectueuses  d'utiliser
  LLiinnuuxx,  bien  qu'ils doivent etre informes du fait que le remplacement
  dans le cadre de la garantie est possible.

  33..55..55..  LLee ppaarraammeettrree ``nnoo--ssccrroollll''

  L'utilisation de ce parametre au  demarrage  desactive  le  defilement
  d'ecran  (scrolling) qui rend difficile l'emploi de terminaux Braille.

  33..55..66..  LLee ppaarraammeettrree ``ppaanniicc==''

  Dans le cas tres desagreable d'une alerte  du  noyau  (kernel  panic),
  c'est  a  dire  une erreur interne qui a ete detectee par le noyau, et
  pour laquelle il a decide qu'elle etait suffisamment grave pour  raler
  bruyamment  et  tout  arreter  ;  le  comportement par defaut est d'en
  rester la  jusqu'a  ce  que  quelqu'un  se  penche  sur  le  probleme,
  visualise  le message sur l'ecran et redemarre la machine.  Cependant,
  si une machine fonctionne sans surveillance dans  un  local  isole  il
  peut-etre  souhaitable qu'il redemarre de lui-meme afin que la machine
  revienne  en  ligne.  Par  exemple,  l'utilisation  de  `panic=30'  au
  demarrage  forcera  le noyau a essayer de redemarrer 30 secondes apres
  que l'alerte du noyau se soit produite. Une valeur  a  zero  donne  le
  comportement  par defaut, qui est d'attendre eternellement.  Notez que
  cette  valeur  d'attente  peut  aussi  etre  lu  et  positionnee   via
  l'interface sysctl /proc/sys/kernel/panic.

  33..55..77..  LLee ppaarraammeettrree ``pprrooffiillee==''

  Les  developpeurs  du noyau peuvent activer une option qui leur permet
  de suivre comment et ou le noyau consomme ses cycles CPU, dans le  but
  d'augmenter  ses  capacites  et  ses  performances.  Cette option vous
  permet de positionner cet indicateur de suivi au moment du  demarrage.
  Generalement  il  est  positionne  a  deux. Vous pouvez aussi compiler
  votre noyau avec l'option de suivi par defaut. Dans tous les  cas,  il
  vous  faudra  un outil comme readprofile.c afin d'utiliser les donnees
  fournies par /proc/profile.

  33..55..88..  LLee ppaarraammeettrree ``rreebboooott==''

  Cette option controle le type de redemarrage que  Linux  fera  lorsque
  vous  ferez  une  remise  a zero de votre ordinateur (generalement via
  /sbin/init en faisant un Ctrl-Alt-Suppr).  Le comportement par  defaut
  des derniers noyaux v2.0 est de faire un redemarrage `a froid' (c.a.d.
  remise a zero complete, le BIOS comtrole la  memoire,  etc.)  au  lieu
  d'un  redemarrage `a chaud' (c.a.d pas de remise a zero totale, pas de
  controle de la memoire).  Il a ete  modifie  pour  prendre  la  valeur
  froid  par defaut depuis que cela semble fonctionner sur des materiels
  bon marche ou endommages qui ne  voulaient  pas  redemarrer  lorsqu'un
  redemarrage a chaud etait requis. Pour retrouver l'ancien comportement
  (c.a.d redemarrage a chaud) utilisez reboot=w en fait  n'importe  quel
  mot commancant par w fonctionnera.

  Pourquoi  cela pourrait-il vous ennuyer ? Certains disques incluant de
  la memoire cache peuvent detecter un redemarrage a  chaud,  et  ecrire
  les  donnees du cache sur le disque. Lors d'un redemarrage a froid, la
  carte peut-etre remise a zero, et les donnees stockees dans la memoire
  cache  seront perdues. D'autres ont signale que des systemes prenaient
  beaucoup de temps pour verifier la memoire, et/ou des  BIOS  SCSI  qui
  etaient  tres  long  a  s'initialiser  lors d'un demarrage a froid, et
  c'est  par  consequent  une  excellente  raison   pour   utiliser   le
  redemarrage a chaud.

  33..55..99..  LLee ppaarraammeettrree ``rreesseerrvvee==''

  Ceci  est  utilise  pour  _p_r_o_t_e_g_e_r  les  zones  des  ports  d'I/O  des
  programmes de test.  La syntaxe de la commande est la suivante :

       reserve=iobase,extent,iobase,extent...

  Sur certaines machines, il peut-etre necessaire d'empecher les pilotes
  de peripheriques de controler les peripheriques a une certaine adresse
  (auto-test). Ceci peut-etre necessaire pour du materiel mal concu  qui
  peut  provoquer  un _b_l_o_q_u_a_g_e au demarrage (comme par exemple certaines
  cartes reseaux ethernet), du materiel mal reconnu,  du  materiel  dont
  l'etat  a  ete modifie par un test recent, ou encore si vous ne voulez
  pas que le noyau initialise certains materiels.

  Le  parametre  de  demarrage  reserve  s'attaque  a  ce  probleme   en
  specifiant  une  zone  d'un  port  d'entree/sortie  qui n'a pas besoin
  d'etre testee. Cette zone est "reservee" (verrouillee) dans  la  table
  d'enregistrement  des  ports  du  noyau comme si un peripherique avait
  deja ete trouve dans cette zone (avec le nom reserved).  Notons que ce
  mecanisme  n'est  pas  necessaire sur la plupart des machines.  Il est
  indispensable d'utiliser ce parametre uniquement en cas de probleme ou
  dans certains cas particuliers.
  Les  ports d'entree/sortie dans la zone specifiee sont proteges contre
  les controles de peripheriques qui font un check_region() au  lieu  de
  tester  aveuglement  une  region d'entree/sortie. Ceci a ete introduit
  pour etre utilise lorsqu'un pilote plante, avec la NE2000 par exemple,
  ou  identifie de facon incorrecte un autre peripherique comme etant le
  sien.  Un pilote de peripherique correct ne doit pas tester  une  zone
  reservee,  a  moins  qu'un  autre  parametre  de demarrage lui demande
  explicitement de le faire. Ceci implique que le parametre reserve doit
  etre le plus souvent utilise avec un autre parametre de demarrage. Par
  consequent si vous specifiez une  region  reserve  pour  preserver  un
  peripherique  particulier,  vous  devrez en general aussi specifier de
  facon explicite un test pour ce peripherique. La plupart  des  pilotes
  ignorent  la  table  d'enregistrement  des  ports si on leur donne une
  adresse specifique.

  Par exemple, la ligne de demarrage

  ______________________________________________________________________
          reserve=0x300,32  blah=0x300
  ______________________________________________________________________

  laisse tous les pilotes  de  peripheriques,  excepte  le  pilote  pour
  `blah', tester 0x300-0x31f.

  Comme  d'habitude  avec  les  parametres  de  demarrage, il existe une
  limite a 11 parametres, c'est pourquoi vous ne pouvez indiquer  que  5
  zones  protegees par mot cle reserve. Plusieurs ordres reserve peuvent
  etre utilises si vous avez une requete vraiment tres complexe.

  33..55..1100..  LLee ppaarraammeettrree ``vvggaa==''

  Notez que ce n'est pas vraiment un parametre de demarrage.  C'est  une
  option  interpretee par LILO et non pas par le kernel, contrairement a
  tous les autres arguments. Pourtant, son utilisation  est  devenue  si
  commune  qu'une  mention  lui  est  reservee  ici.  Il peut aussi etre
  positionne grace a rdev -v ou par  equivalence  avec  vidmode  sur  le
  fichier  vmlinuz. Cela permet au programme de configuration d'utiliser
  le BIOS video pour changer  le  mode  d'ecran  par  defaut,  avant  le
  demarrage  du  noyau  de Linux. Les modes courants sont 80x50, 132x44,
  etc. Le meilleur moyen d'utiliser cette option est  de  demarrer  avec
  vga=ask,  qui vous demandera a l'aide d'une liste des differents modes
  que vous pourrez utiliser avec votre carte video, avant de demarrer le
  noyau.  Une  fois  que  vous  avez le nombre que vous voulez utiliser,
  provenant de la liste ci-dessus, vous pouvez, plus tard, le  placer  a
  la  place  de  'ask'.  Pour  plus  d'informations, veuillez, s'il vous
  plait, regarder le  fichier  linuxDocumentation/svga.txt/  qui  existe
  depuis  les dernieres versions du noyau.  Notez que les noyaux recents
  (version 2.1 et superieures) ont leur programme de  configuration  qui
  permettent  de  changer  le  mode  video,  sous la forme d'une option,
  listee comme un  _S_u_p_p_o_r_t  _d_e  _s_e_l_e_c_t_i_o_n  _d_e  _m_o_d_e  _v_i_d_e_o  (_V_i_d_e_o  _m_o_d_e
  _s_e_l_e_c_t_i_o_n  _s_u_p_p_o_r_t), donc vous devez selectionner cette option si vous
  voulez cette  caracteristique.

  44..  PPaarraammeettrreess ddee ddeemmaarrrraaggee ppoouurr lleess PPeerriipphheerriiqquueess SSCCSSII

  Cette section contient une description des parametres de demarrage qui
  sont  utilises pour passer des informations concernant les adaptateurs
  hotes et les peripheriques SCSI.
  44..11..  PPaarraammeettrreess ppoouurr lleess ppiillootteess ddee nniivveeaauu iinntteerrmmeeddiiaaiirree

  Les pilotes de niveau intermediaire  prennent  en  charge  des  choses
  comme  le  disques,  les  CD-Roms  et  les  bandes sans s'attacher aux
  specificitees de chaque peripheriques.

  44..22..  NNoommbbrree mmaaxxiimmuumm ddee LLUUNN ccoonnttrroolleess ((``mmaaxx__ssccssii__lluunnss==''))

  Chaque peripherique SCSI peut avoir un nombre de  `sous-peripheriques'
  qui  le  composent.  L'exemple  le plus courant est represente par les
  nouveaux CD-ROM SCSI qui utilisent plus d'un disque a la fois grace  a
  un  chargeur  de  CD.  Chaque CD est adressable comme un `Logical Unit
  Number' (LUN = Numero d'Unite Logique) de  ce  peripherique  multiple.
  Mais la plupart des peripheriques comme les disques durs, les lecteurs
  de bandes et  autres,  sont  des  peripheriques  simples  et  on  leur
  attribue le LUN zero.

  Le  probleme  survient avec les peripheriques a un seul LUN qui ont un
  mauvais  microprogramme.  Certains  peripheriques  SCSI   mal   concus
  (anciens  et  malheureurement nouveaux aussi) ne supportent pas d'etre
  testes pour des LUN differents de zero. Ils repondent en se  bloquant,
  et peuvent aussi verrouiller tout le bus SCSI en meme temps.

  Les  nouveaux  noyaux  ont une option de configuration qui vous permet
  d'indiquer le nombre maximum de LUN  a  tester.  Par  defaut,  ils  ne
  testent que le LUN zero, pour eviter le probleme decrit ci-dessus.

  Pour  specifier  le  nombre de LUN a tester au moment du demarrage, il
  suffit d'entrer le parametre de demarrage `max_scsi_luns=n', ou n  est
  un  nombre compris entre un et huit. Pour eviter les problemes decrits
  precedemment, on peut  utiliser  n=1  pour  eviter  de  perturber  les
  peripheriques defectueux.

  44..33..  PPaarraammeettrreess ppoouurr lleess LLeecctteeuurrss ddee BBaannddeess SSCCSSII ((``sstt==''))

  Certaines  configurations de demarrage pour les lecteurs de bande SCSI
  peuvent etre obtenues en utilisant ce qui suit :

  ______________________________________________________________________
          st=buf_size[,write_threshold[,max_bufs]]
  ______________________________________________________________________

  Les deux premiers nombres sont donnes en kilo-octets.  La  valeur  par
  defaut  du  buf_size  est  32  ko,  et la taille maximum qui peut etre
  donnee est la valeur ridicule de 16384 ko.   La  zone  write_threshold
  est  la valeur a laquelle le tampon est envoye vers la bande, avec une
  valeur par defaut de 30ko.  Le nombre  maximum  de  tampons  varie  en
  fonction  du  nombre  de lecteurs detectes, et a une valeur par defaut
  egale a deux. Voici un exemple d'utilisationnbsp;:

  ______________________________________________________________________
          st=32,30,2
  ______________________________________________________________________

  Des indications plus precises peuvent etre trouvees  dans  le  fichier
  README.st  qui  est  dans  le  repertoire  scsi  de l'arborescence des
  sources du noyau.

  44..44..  PPaarraammeettrreess ppoouurr lleess aaddaappttaatteeuurrss SSCCSSII

  Notations utilisees dans cette section :

  iobase  Le premier port d'Entree/Sortie que le  serveur  SCSI  occupe.
  Ceux-ci  sont  donnes  en  notation hexadecimale, et sont generalement
  situes dans la fourchette 0x200 a 0x3ff.

  irq   L'interruption  materielle  pour  laquelle  la   carte   a   ete
  configuree. Les valeurs autorisees dependront de la carte en question,
  mais seront generalement 5, 7, 9,  10,  11,  12,  et  15.  Les  autres
  valeurs  etant  generalement utilisees pour les peripheriques courants
  comme les disques durs IDE, les  lecteurs  de  disquettes,  les  ports
  serie, etc.

  dma   Le  canal DMA (Direct Memory Access - Acces Direct a la Memoire)
  Generalement applique aux cartes de pilotage du bus. Les cartes PCI et
  VLB  pilotent  directement  le bus, et ne necessitent pas de canal DMA
  ISA.

  scsi-id  L'identifiant que la carte-serveur utilise pour  s'identifier
  elle-meme  sur  le  bus SCSI. Un certain nombre de cartes serveur vous
  permettront de modifier cette valeur, alors  que  d'autres  ont  cette
  valeur  stockee de facon definitive sur la carte. La valeur par defaut
  la plus courante est sept, mais les cartes Seagate  et  Future  Domain
  TMC-950 par exemple utilisent la valeur six.

  parity    Determine  si  la  carte  serveur  SCSI  doit  demander  aux
  peripheriques connectes de fournir une valeur de parite avec tous  les
  echanges  d'informations.  La  valeur  1  indique  que la detection de
  parite est activee, et la valeur 0 desactive le  controle  de  parite.
  Encore  une  fois, toutes les cartes ne supportent pas la selection du
  controle de parite par les parametres de demarrage.

  44..44..11..   AAddaapptteecc  aahhaa115511xx,,  aahhaa115522xx,,   aaiicc66226600,,   aaiicc66336600,,   SSBB1166--SSCCSSII
  ((``aahhaa115522xx==''))

  Les valeurs aha font reference a des cartes et les  valeurs  aic  font
  reference  aux puces SCSI actuelles de ce type de cartes, y compris la
  Soundblaster-16 SCSI.

  Le code de test de ces serveurs SCSI recherche  s'il  existe  un  BIOS
  installe,  et  s'il  n'est  pas present, le test ne trouvera pas votre
  carte. Vous aurez alors a utiliser le parametre de demarrage  avec  la
  syntaxe suivante :

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

  Notez  que  si  le  pilote  a  ete  compile avec l'option de recherche
  d'erreur activee, une sixieme valeur peut etre specifiee pour fixer le
  niveau de recherche d'erreur.

  Tous  les  parametres  sont  decrits  au debut de cette section, et la
  valeur reconnect permet au peripherique de se  deconnecter/reconnecter
  si  une  valeur  differente  de  zero  est utilisee.  Voici un exemple
  d'utilisation :

  ______________________________________________________________________
          aha152x=0x340,11,7,1
  ______________________________________________________________________

  Notez que les parametres doivent etre  donnes  dans  l'ordre,  ce  qui
  signifie  que  si  vous desirez specifier une configuration de parite,
  vous devrez alors indiquer les valeurs  de  iobase,  irq,  scsi-id  et
  reconnect aussi.

  44..44..22..  AAddaapptteecc aahhaa115544xx ((``aahhaa11554422==''))

  Ce  sont  les gammes de cartes aha154x. Les differentes cartes aha1542
  ont un controleur de disquette  i82077  en  interne,  tandis  que  les
  cartes  de  la  serie  aha1540  n'en  ont  pas.  Ce  sont des cartes a
  "busmastering", (controle de bus) et  elles  ont  des  parametres  qui
  permettent  d'indiquer  le  niveau  ``d'equite''  qui est utilise pour
  partager le  bus  avec  les  autres  peripheriques.  Le  parametre  de
  demarrage ressemble a ce qui suit.

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

  Les  valeurs  couramment  utilisees  pour  iobase sont les suivantes :
  0x130, 0x134, 0x230,  0x234,  0x330,  0x334.   Des  clones  de  cartes
  peuvent autoriser d'autres valeurs.

  Les valeurs buson, busoff indiquent le nombre de microsecondes pendant
  lesquelles la carte est prioritaire sur le bus ISA.  Les  valeurs  par
  defaut  sont  11 us prioritaire, et 4 us non prioritaire, de facon que
  d'autres cartes (comme une carte Ethernet ISA LANCE) aient une  chance
  d'avoir acces au bus ISA.

  La  valeur  dmaspeed  fait reference a la vitesse (en Mo/s) a laquelle
  s'effectue le transfert DMA (Direct Memory  Access,  Memoire  a  Acces
  Direct).  La  valeur  par defaut est 5 Mo/s. Les nouvelles versions de
  ces cartes vous permettent  de  selectionner  cette  valeur  de  facon
  logicielle  alors  que  les  anciennes cartes utilisait des cavaliers.
  Vous pouvez utiliser des valeurs allant jusqu'a 10 Mo/s  en  supposant
  que  votre  carte  mere  soit  capable  de les supporter. Experimentez
  prudemment si vous utilisez des valeurs superieures a 5 Mo/s.

  44..44..33..  AAddaapptteecc aahhaa227744xx,, aahhaa228844xx,, aaiicc77xxxxxx ((``aaiicc77xxxxxx==''))

  Ces cartes peuvent recevoir un parametre selon la syntaxe suivante :

  ______________________________________________________________________
          aic7xxx=extended,no_reset
  ______________________________________________________________________

  La valeur de extended, si elle est differente de zero, indique que  la
  traduction  etendue  pour  les disques de grande capacite est activee.
  La valeur no_reset, si elle est differente de zero, indique au  pilote
  de  ne  pas  reinitialiser  le  bus SCSI lorsqu'il configure la carte-
  serveur au demarrage.

  44..44..44..  AAddaappttaatteeuurrss SSCCSSII AAddvvaannSSyyss ((``aaddvvaannssyyss==''))

  Le pilote AdvanSys peut  accepter  jusqu'a  quatre  adresses  I/O  qui
  seront testees pour une carte SCSI AdvanSys. Notez que ces valeurs (si
  elles sont utilisees) n'auront en aucun cas d'effet sur les tests EISA
  ou  PCI.  Elles sont seulement utilisees pour tester les cartes ISA et
  VLB.  De plus, si le pilote a ete compile avec  l'option  de  debogage
  activee,  le  niveau  de  detail  des  informations  renvoyees  par le
  debogage peut etre indique en ajoutant un parametre 0xdeb[0-f]. Le 0-f
  permet de faire afficher les 16 niveaux de messages de debogage.

  44..44..55..  AAddaappttaatteeuurr AAllwwaayyss IINN22000000 ((``iinn22000000==''))

  Contrairement  aux  autres  parametres  de demarrage, le pilote IN2000
  utilise des prefixes de type chaine  ASCII  pour  la  plupart  de  ses
  parametres entiers; Voici la liste des parametres acceptes :

  ioport:addr

  -  Ou  addr  est  l'adresse  IO d'une carte (generalement sans memoire
  morte 'ROM').

  noreset

  - Pas de parametres optionnels. Evite la remise a zero du bus SCSI  au
  moment du demarrage.

  nosync:x

  -  x  est  un  masque  d'octets  (bitmask)  ou  les  7  premiers  bits
  correspondent aux 7  peripheriques  SCSI  possibles  (bit  0  pour  le
  peripherique   #0,   etc).   Positionnez  un  bit  pour  PREVENIR  une
  negociation de synchronisation sur ce peripherique.  Par  defaut  sync
  est DESACTIVE sur tous les peripheriques.

  period:ns

  -  ns  est la duree minimum en nanosecondes d'une periode de transfert
  de donnees en SCSI. La valeur par defaut est 500; les valeurs  doivent
  etre comprises entre 250 et 1000.

  disconnect:x

  - x = 0 pour ne jamais autoriser les deconnexions, 2 pour toujours les
  autoriser. x = 1 fait des deconnexions 'selon le besoin', ce  qui  est
  la valeur par defaut et generalement le meilleur choix.

  debug:x  -  Si `DEBUGGING_ON' est positionne, x est un masque d'octets
  qui provoque differents types de sorties  de  debogage  pour  imprimer
  (voyez le DB_xxx definis dans in2000.h).

  proc:x  - Si `PROC_INTERFACE' est defini, x est un masque d'octets qui
  indique comment fontionne l'interface /proc et ce qu'elle  fait  (voir
  la definition de PR_xxx dans in2000.h

  Quelques exemples d'utilisation sont listes ci-dessous :

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

  44..44..66..  MMaatteerriieell bbaassee ssuurr uunn AAMMDD AAMM5533CC997744 ((``AAMM5533CC997744==''))

  Contrairement aux autres pilotes, celui-ci n'utilise pas de parametres
  de demarrage pour indiquer les E/S, les IRQ ou les DMA (depuis que  le
  AM53C974  est un peripherique PCI, il n'a pas besoin de la faire).  En
  revanche, les parametres sont utilises pour communiquer les  modes  de
  transfert  et  les vitesses qui doivent etre utilises entre le serveur
  (host) et le peripherique cible. Utilisons un exemple pour y voir plus
  clair :

  ______________________________________________________________________
          AM53C974=7,2,8,15
  ______________________________________________________________________

  Ceci peut etre interprete de la maniere suivante :

  `Pour  communiquer  entre  le controleur d'identifiant SCSI-ID 7 et le
  peripherique d'identifiant SCSI-ID 2, un taux de transfert de 8 MHz en
  mode  synchrone,  avec  un  decalage  maximum  de  15 octets doit etre
  negocie.' De plus amples details peuvent etre trouves dans le  fichier
  linux/drivers/scsi/README.AM53C974

  44..44..77..  LLeess sseerrvveeuurrss SSCCSSII BBuussLLooggiicc aavveecc lleess nnooyyaauuxx vv11..22 ((``bbuussllooggiicc==''))

  Dans les anciens noyaux, les pilotes buslogic n'acceptent  qu'un  seul
  parametre, qui est l'adresse d'entree/sortie. Elle doit correspondre a
  l'une des valeurs suivantes :

  0x130, 0x134, 0x230, 0x234, 0x330, 0x334.

  44..44..88..  LLeess sseerrvveeuurrss SSCCSSII BBuussLLooggiicc aavveess lleess nnooyyaauuxx vv22..xx ((``BBuussLLooggiicc==''))

  Avec   les  noyaux  v2.x,  le  pilote  BusLogic  accepte  de  nombreux
  parametres (notez la casse ci dessus ; B  et  L  majuscule  !!!).   La
  description  detaillee  qui suit est extraite directement du pilote de
  Leonard N. Zubkoff inclus dans le noyau v2.0 .

  Pour le pilote BusLogic, une  ligne  de  commande  destinee  au  noyau
  comprend  l'identifiant du pilote "BusLogic=" eventuellement suivi par
  une serie d'entiers separes par des virgules,  et  accessoirement  par
  une  suite de chaines aussi separees par des virgules. Chaque ligne de
  commande s'applique a un adaptateur BusLogic. Des lignes  de  commande
  multiples  peuvent etre utilisees sur des systemes utilisant plusieurs
  cartes BusLogic.

  Le premier entier indique est l'adresse d'Entree/Sortie (I/O  Address)
  a  laquelle  l'adaptateur  est situe. Si il n'est pas specifie, il est
  positionne a zero, ce qui indique d'appliquer cette ligne de  commande
  au   premier  adaptateur  BusLogic  trouve  lors  de  la  sequence  de
  detection. Si une adresse I/O est fournie sur la ligne de commande, la
  sequence de detection est ignoree.

  Le  second  entier  fourni  est  la  profondeur de la 'Tagged Queue' a
  utiliser pour  les  peripheriques  cibles  qui  utilisent  le  'Tagged
  Queuing'.  La  profondeur  de  cette  file  correspond  au  nombre  de
  commandes SCSI qui  peuvent  etre  envoyees  simultanement  pour  etre
  executees.  Si  rien  n'est indique, la valeur par defaut est zero, et
  indique d'utiliser une valeur determinee automatiquement  en  fonction
  du  'Total Queue Depth' de l'adaptateur, ainsi que du nombre, du type,
  de la vitesse des peripheriques cible detectes.  Pour les  adaptateurs
  qui  requierent  des 'ISA Bounce Buffers', le 'Tagged Queue Depth' est
  automatiquement  positionne  a   'BusLogic_TaggedQueueDepth_BB'   pour
  eviter une preallocation excessive de memoire 'DMA Bounce Buffer'. Les
  peripheriques  cibles  qui  ne  supportent  pas  le  'Tagged  Queuing'
  utilisent      une     'Queue     Depth'     ayant     pour     valeur
  'BusLogic_UntaggedQueueDepth'.

  Le troisieme entier est le 'Bus Settle Time' (temps  de  stabilisation
  du bus) en secondes. C'est le temps a attendre entre une remise a zero
  physique de l'adaptateur, qui initialise une  remise  a  zero  du  bus
  SCSI,  et  le  moment  ou  l'on peut passer une commande SCSI. Si rien
  n'est indique, il est a zero par defaut, ce qui indique d'utiliser  la
  valeur BusLogic_DefaultBusSettleTime.

  Le  quatrieme  entier  correspond  aux  options locales. Si rien n'est
  indique, la valeur par defaut est 0. Notez  que  ces  options  locales
  sont uniquement utilisees sur un adaptateur hote specifique.

  Le  cinquieme  entier  correspond  aux options globales. Si rien n'est
  indique, le valeur par defaut est 0. Notez que  les  options  globales
  sont appliquees a tous les adaptateurs hotes.

  Les  chaines  d'options  sont  utilisees  pour  controler  le  'Tagged
  Queuing', le recouvrement d'erreur, et le test de l'adaptateur hote.

  Les indications pour le  'Tagged  Queuing'  commencent  par  "TQ:"  et
  permettent d'indiquer precisemment ou le 'Tagged Queuing' est autorise
  sur les peripheriques cibles qui  le  supportent.  Les  specifications
  suivantes sont disponibles :

  TQ:Default

  -  Le  'Tagged Queuing' sera permis, base sur la version de micro-code
  de l'adaptateur hote BusLogic et conditionne par la valeur de  'Tagged
  Queue Depth' qui doit permettre la mise en file d'attente de multiples
  commandes.

  TQ:Enable

  - Le 'Tagged Queuing' est active pour tous les  peripheriques  de  cet
  adaptateur  hote,  outrepassant  toutes  les  limitations qui seraient
  imposees par la version de micro-code de cet adaptateur.

  TQ:Disable

  - Le 'Tagged Queuing'  sera  desactive  pour  tous  les  peripheriques
  relies a cet adaptateur hote.

  TQ:<Per-Target-Spec>

  -  Le  'Tagged  Queuing'  sera  controle  individuellement pour chaque
  peripherique cible. <Per-Target-Spec> est une sequence  de  caracteres
  "Y",  "N",  et  "X".  "Y" active le 'Tagged Queuing', "N" desactive le
  'Tagged Queuing', et "X" correspond a la valeur par defaut  basee  sur
  la   version   du  micro-code.  Le  premier  caractere  correspond  au
  peripherique cible 0, le second au peripherique cible 1, et  ainsi  de
  suite  ;  Si  la sequence de caracteres "Y", "N", et "X" ne suffit pas
  pour  tous  les  peripheriques  cibles,  les  caracteres  non-indiques
  prendront la valeur "X".

  Notez que la demande explicite de 'Tagged Queuing' peut conduire a des
  problemes. Cette capacite est fournie principalement pour permettre de
  desactiver   le   'Tagged   Queuing'  sur  des  peripheriques  qui  ne
  l'utilisent pas correctement.

  Les indications de la Strategie de Recouvrement  d'Erreurs  commencent
  par "ER:" et permettent d'indiquer l'action de recouvrement d'erreur a
  effectuer quand la 'ResetCommand' est appellee en raison d'un incident
  sur  une  commande  SCSI,  de facon a finir correctement.  Les options
  suivantes sont disponibles :

  ER:Default

  - Le Recouvrement d'Erreur choisira entre la remise  a  zero  physique
  (Hard  Reset) et la remise a zero du bus des peripheriques (Bus Device
  Reset) selon les recommandations du sous systeme SCSI.

  ER:HardReset

  - Le Recouvrement d'Erreur demandera une remise  a  zero  physique  de
  l'adaptateur  hote,  ce  qui provoquera aussi une remise a zero du bus
  SCSI.

  ER:BusDeviceReset

  - Le recouvrement d'Erreur  enverra  un  message  'Bus  Device  Reset'
  (remise  a  zero  du  bus) individuellement au peripherique provoquant
  l'erreur. Si le Recouvrement d'Erreur est a  nouveau  appele  pour  ce
  peripherique,  et  qu'aucune  commande SCSI de ce peripherique n'a ete
  executee avec succes depuis le dernier message 'Bus  Device  Reset'  a
  ete envoye, alors une remise a zero physique est provoquee.

  ER:None

  -  Le Recouvrement d'Erreur sera supprime. Cette option peut seulement
  etre selectionnee si un 'SCSI Bus Reset'  ou  un  'Bus  Device  Reset'
  provoque  un  plantage  du  peripherique  cible  de  facon  totale  et
  irrecuperable.

  ER:<Per-Target-Spec>

  - Le Recouvrement d'Erreur sera controle individuellement pour  chaque
  peripherique.   <Per-Target-Spec>  est une sequence de caracteres "D",
  "H", "B", et "N". "D" correspond a 'Default', "H" a 'Hard Reset',  "B"
  a 'Bus Device Reset', et "N" a 'None'. Le premier caractere correspond
  au peripherique 0 , le second au peripherique 1, et ainsi de suite. Si
  la  sequence  de  caracteres  "D", "H", "B", et "N" ne suffit pas pour
  tous  les   peripheriques   possibles,   les   carracteres   manquants
  correspondront a "D".

  Les specifications de test de l'adaptateur hote sont les suivantes :

  NoProbe  -  Aucun  test  d'aucune  sorte  ne  doit  etre  fait, et par
  consequent, aucun adaptateur hote BusLogic ne sera detecte.

  NoProbeISA - Aucun test des adresses I/O standard ISA ne sera fait, et
  par consequent, seuls les adaptateurs hotes PCI seront detectes.

  NoSortPCI  -  Les  adaptateurs  hotes PCI seront enumeres dans l'ordre
  fourni par le BIOS PCI,  ignorant  tous  les  parametres  de  l'option
  "Utilisation  du # des bus et peripheriques pour la sequence d'analyse
  du bus PCI" de l'AutoSCSI.

  44..44..99..  LLeess ccaarrtteess SSCCSSII EEAATTAA ((``eeaattaa==''))

  Depuis la deja ancienne  version  v2.0  du  noyau,  les  pilotes  EATA
  acceptent un parametre de demarrage permettant d'indiquer les adresses
  d'entree/sortie qui doivent etre testees. Il est de la forme :

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

  Le pilote testera les adresses dans l'ordre ou elles sont fournies.

  44..44..1100..  FFuuttuurree DDoommaaiinn TTMMCC--88xxxx,, TTMMCC--995500 ((``ttmmcc88xxxx==''))

  Le code de test pour ces hotes SCSI recherche  un  BIOS  installe,  et
  s'il  n'en  detecte aucun, le test ne trouvera pas votre carte.  Ou si
  la signature de votre BIOS  n'est  pas  reconnue,  elle  ne  sera  pas
  trouvee  non  plus. Dans ce cas, vous aurez a utiliser un parametre de
  demarrage de la forme :

  ______________________________________________________________________
          tmc8xx=mem_base,irq
  ______________________________________________________________________

  La valeur mem_base est l'adresse dans le plan  memoire  de  la  region
  d'entree/sortie  utilisee  par  la  carte.  C'est generalement une des
  valeurs suivantes :

  0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000.

  44..44..1111..  FFuuttuurree DDoommaaiinn TTMMCC--1166xxxx,, TTMMCC--33226600,, AAHHAA--22992200 ((``ffddoommaaiinn==''))

  Le  pilote  detecte ces cartes selon une liste connue de signatures de
  BIOS ROM. Pour obtenir une liste complete  des  revisions  connues  de
  BIOS,  voyez  le  fichier  linux/drivers/scsi/fdomain.c  qui  contient
  beaucoup d'informations en debut de fichier. Si votre BIOS  n'est  pas
  connu  du  pilote,  vous  pourrez  utiliser  un  forcage  de  la facon
  suivante :

  ______________________________________________________________________
          fdomain=iobase,irq[,scsi_id]
  ______________________________________________________________________

  44..44..1122..  LLee lleecctteeuurr ZZIIPP IIOOMMEEGGAA // PPoorrtt PPaarraalllleellee ((``ppppaa==''))

  Ce pilote est pour l'adaptateur SCSI de l'IOMEGA  Port  Parallele  qui
  est integre dans le lecteur IOMEGA ZIP. Il peut aussi fonctionner avec
  le peripherique d'origine IOMEGA PPA3. Le parametre de demarrage  pour
  ce pilote a la structure suivante :

  ______________________________________________________________________
          ppa=iobase,speed_high,speed_low,nybble
  ______________________________________________________________________

  ou  tous  les  parametres  sont  facultatifs,  sauf  'iobase'. Si vous
  souhaitez modifier un des trois elements, il serait  bon  de  lire  au
  prealable le document linux/drivers/scsi/README.ppa afin d'obtenir des
  details sur ces parametres.

  44..44..1133..  CCoonnttrroolleeuurrss uuttiilliissaanntt uunn NNCCRR55338800 ((``nnccrr55338800==''))

  Selon votre carte, le 5380 peut-etre  soit  'i/o  mapped'  ou  'memory
  mapped'  (repertorie  en entree/sortie ou repertorie en memoire).  Une
  adresse en dessous de 0x400 indique souvent l'i/o mapping,  cependant,
  les  materiels  PCI  et EISA utilisent des adresses d'entree/sortie au
  dessus de 0x3ff. Dans tous les cas, vous indiquez l'adresse, la valeur
  de  l'IRQ,  et  la valeur du canal DMA. Un exemple pour une carte 'i/o
  mapped' serait : ncr5380=0x350,5,3.  Si la  carte  n'utilise  pas  les
  interruptions,   une   valeur   d'IRQ   255   (0xff)  desactivera  les
  interruptions. Une IRQ  a  254  indiquera  d'activer  l'autotest.  Des
  details    supplementaires    sont    fournis    dans    le   document
  linux/drivers/scsi/README.g_NCR5380.

  44..44..1144..  CCoonnttrroolleeuurrss uuttiilliissaanntt uunn NNCCRR5533cc440000 ((``nnccrr5533cc440000==''))

  Le support du 53c400 est fait avec le meme pilote que  le  support  du
  5380  mentionne  ci-dessus. Le parametre de demarrage est identique au
  precedent, sauf qu'aucun canal DMA n'est utilise par le 53c400.

  44..44..1155..  CCoonnttrroolleeuurrss uuttiilliissaanntt uunn NNCCRR5533cc440066aa ((``nnccrr5533cc440066aa==''))

  Ce pilote utilise un parametre de demarrage de la forme suivante :

  ______________________________________________________________________
          ncr53c406a=PORTBASE,IRQ,FASTPIO
  ______________________________________________________________________

  ou   les  parametres  IRQ  et  FASTPIO  sont  optionnels.  Une  valeur
  d'interruption  a  zero  desactive  l'utilisation  des  interruptions.
  L'utilisation  d'une  valeur a 1 pour FASTPIO active l'utilisation des
  instructions insl et outsl au lieu des instructions mono-octet inb  et
  outb.  Le  pilote peut aussi utiliser le DMA comme une option utilisee
  lors de la compilation (compile-time option).

  44..44..1166..  PPrroo AAuuddiioo SSppeeccttrruumm ((``ppaass1166==''))

  La PAS16 utilise une  puce  NCR5380  SCSI,  et  les  nouveaux  modeles
  peuvent  etre  configures de facon logicielle. La syntaxe du parametre
  est la suivante :

  ______________________________________________________________________
          pas16=iobase,irq
  ______________________________________________________________________

  La seule difference est que vous pouvez  specifier  une  valeur  d'IRQ
  egale  a  255,  qui  indique au pilote de travailler sans utiliser les
  interruptions,  malheureusement  au  detriment  des  performances.  La
  valeur de iobase est generalement 0x388.

  44..55..  SSeeaaggaattee SSTT--00xx ((``sstt00xx==''))

  Le  code  du  programme  de  test  de  cet hote SCSI recherche un BIOS
  installe, et s'il n'y en a aucun de present, le test ne  trouvera  pas
  votre carte.  Ou si la signature de votre BIOS n'est pas reconnue elle
  ne sera pas trouvee non plus. Dans ce cas, vous aurez  a  utiliser  le
  parametre suivant :

  ______________________________________________________________________
          st0x=mem_base,irq
  ______________________________________________________________________

  La  valeur de mem_base est l'adresse dans le plan memoire de la region
  d'entree/sortie utilisee par la carte. En general, il s'agit d'une des
  valeurs  suivantes  :  0xc8000,  0xca000,  0xcc000,  0xce000, 0xdc000,
  0xde000.

  44..66..  TTrraannttoorr TT112288 ((``tt112288==''))

  Cette carte est aussi concue autour de la puce NCR5380, et accepte les
  options suivantes :

  ______________________________________________________________________
          t128=mem_base,irq
  ______________________________________________________________________

  Les  valeurs  autorisees  pour  mem_base sont les suivantes : 0xcc000,
  0xc8000, 0xdc000, 0xd8000.

  44..66..11..  CCaarrtteess SSCCSSII UUllttrraassttoorr ((``uu1144--3344ff==''))

  Notez que pour cette carte tout se presente  sous  la  forme  de  deux
  pilotes independants, nommes CONFIG_SCSI_U14_34F qui utilise u14-34f.c
  et CONFIG_SCSI_ULTRASTOR qui utilise ultrastor.c. C'est le u14-34f qui
  (jusqu'au  dernier noyau v2.0) accepte un parametre de demarrage de la
  forme :

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

  Le pilote autotestera les adresses  dans  l'ordre  dans  lequel  elles
  apparaissent.

  44..66..22..  CCaarrtteess WWeesstteerrnn DDiiggiittaall WWDD77000000 ((``wwdd77000000==''))

  Le test du pilote pour le wd7000 cherche une chaine connue de BIOS ROM
  et connait quelques reglages standards de  configuration.   Si  il  ne
  retrouve  pas les valeurs correctes pour votre carte, ou que vous avez
  une version de BIOS non reconnue, vous  pouvez  utiliser  le  prametre
  suivant :

  ______________________________________________________________________
          wd7000=irq,dma,iobase
  ______________________________________________________________________

  44..77..  CCaarrtteess nn''aacccceeppttaanntt ppaass lleess ppaarraammeettrreess ddee ddeemmaarrrraaggee

  Pour  l'instant,  les  cartes  SCSI  suivantes  n'utilisent  aucun des
  parametres de demarrage. Dans certains cas, vous pouvez "bricoler" les
  valeurs  en  editant  directement  le  pilote  lui-meme,  si  cela est
  necessaire bien sur.

          Adaptec aha1740 (autotest EISA),
          NCR53c7xx, 8xx (PCI, toutes les deux)
          Qlogic Fast (0x230, 0x330)
          Qlogic ISP (PCI)

  55..  DDiissqquuee DDuurrss

  Cette section fait la  liste  de  tous  les  parametres  de  demarrage
  associes  aux  lecteurs  de  disques standards MFM/RLL, ST-506, XT, et
  IDE.  Notez que les deux pilotes IDE et ST-506 HD  acceptent  l'option
  `hd='.

  55..11..  PPaarraammeettrreess ddeess lleecctteeuurrss ddee DDiissqquueess//CCDD--RROOMM IIDDEE

  Les pilotes IDE acceptent un certain nombre de parametres, qui vont de
  la definition des caracteristiques du  disque,  a  la  correction  des
  erreurs   produites  par  les  nouvelles  puces  ou  celles  qui  sont
  defectueuses.  Ce qui suit est un resume des parametres  de  demarrage
  possibles.   Pour  plus  de  details,  il faut _a_b_s_o_l_u_m_e_n_t consulter le
  fichier ide.txt dans  le  repertoire  linux/Documentation,  duquel  ce
  resume est extrait.

  ______________________________________________________________________

   "hdx="  est reconnu pour toutes les valeurs de "x", de "a" to "h", comme "hdc".
   "idex=" est reconnu pour toutes les valeurs de "x" de "0" a "3", comme "ide1".

   "hdx=noprobe"          : le lecteur est peut-etre present, mais ne pas le tester
   "hdx=none"             : le lecteur n'est PAS present, ignorer le cmos et
                            ne pas tester.
   "hdx=nowerr"           : ignorer le bit WRERR_STAT sur ce lecteur
   "hdx=cdrom"            : le lecteur est present, et c'est un cdrom
   "hdx=cyl,head,sect"    : le lecteur est present, avec la description indiquee
   "hdx=autotune"         : le pilote essaiera de regler la vitesse de l'interface
                            pour atteindre le plus rapide des modes PIO supportes,
                            si possible pour ce lecteur seulement.
                            Ce n'est pas supporte par tous les types de puces,
                            et peut de temps en temps poser des problemes avec
                            les disques IDE anciens ou originaux.

   "idex=noprobe"         : ne pas tenter d'acceder ou utiliser cette interface
   "idex=base"            : tester l'interface a l'adresse indiquee,
                            ou "base" est generalement 0x1f0 ou 0x170
                            et "ctl" est considere comme etant "base"+0x206
   "idex=base,ctl"        : indiquer les deux, base et ctl
   "idex=base,ctl,irq"    : indiquer les valeurs de base, ctl, et irq
   "idex=autotune"        : le pilote tentera de regler la vitesse de l'interface
                            pour atteindre le plus rapide des modes PIO supportes,
                            pour tous les lecteurs de cette interface.
                            Ce n'est pas supporte par tous les types de puces,
                            et peut de temps en temps poser des problemes avec
                            les disques IDE anciens ou originaux.

   "idex=noautotune"      : le pilote n'essaiera PAS de regler la vitesse
                            de l'interface. Ceci est la valeur par defaut pour
                            le plupart des puces, excepte le cmd640.
   "idex=serialize"       : ne pas empieter sur les operations sur idex et ide(x^1)
  ______________________________________________________________________

  Les  suivants  sont  valides  SEULEMENT  pour ide0, et les valeurs par
  defaut pour base, ctl et ports ne doivent pas etre modifies.

  ______________________________________________________________________

   "ide0=dtc2278"         : teste/supporte l'interface DTC2278
   "ide0=ht6560b"         : teste/supporte l'interface HT6560B
   "ide0=cmd640_vlb"      : *REQUIS* pour les cartes VLB avec la puce CMD640
                            (pas pour PCI - automatiquement detecte)
   "ide0=qd6580"          : teste/supporte l'interface qd6580
   "ide0=ali14xx"         : teste/supporte les puces ali14xx (ALI M1439/M1445)
   "ide0=umc8672"         : teste/supporte les puces umc8672
  ______________________________________________________________________

  Tout le reste  est  rejete  par  un  message  "BAD  OPTION"  (mauvaise
  option).

  55..22..  OOppttiioonnss dduu ppiilloottee ssttaannddaarrdd SSTT--550066 ((``hhdd==''))

  Le  pilote  standard  de  disque  accepte  les memes parametres que le
  pilote IDE. Notez cependant qu'il ne requiert que 3 valeurs (C/H/S)  -
  Ni  plus  ni  moins,  et  il  vous  ignorera  -.  De  plus, il accepte
  uniquement le parametre `hd=', c'est a dire que `hda=', `hdb=' et tout
  le reste ne sont pas autorises ici. Le format est le suivant :

  ______________________________________________________________________
          hd=cyls,heads,sects
  ______________________________________________________________________

  Si  deux  disques  sont installes, la ligne ci-dessus est repetee avec
  les caracteristiques techniques du second disque.

  55..33..  OOppttiioonnss dduu ppiilloottee ddee ddiissqquuee XXTT ((``xxdd==''))

  Si vous etes malchanceux au  point  d'utiliser  une  de  ces  vieilles
  cartes 8 bits qui transfere les donnees a la vitesse fulgurante de 125
  ko/s, c'est ici qu'est le scoop. Le  code  de  test  pour  ces  cartes
  recherche  un  BIOS  installe  et  s'il  n'en  trouve  pas, le test ne
  detectera pas votre carte. Ou encore, si la signature  de  votre  BIOS
  n'est pas reconnue, le test ne trouvera pas votre carte non plus. Dans
  n'importe lequel  de  ces  cas,  vous  devrez  utiliser  le  parametre
  suivant :

  ______________________________________________________________________
          xd=type,irq,iobase,dma_chan
  ______________________________________________________________________

  La  valeur de type indique qui est le constructeur de la carte et peut
  prendre  les  valeurs  suivantes  :  0=generic;  1=DTC;  2,3,4=Western
  Digital,   5,6,7=Seagate;   8=OMTI.  La  seule  difference  entre  les
  differents types pour un meme constructeur est la chaine BIOS utilisee
  pour  la detection, et qui n'est pas utilisee si le type est specifie.

  La fonction xd_setup() ne controle pas les valeurs,  et  supporte  que
  vous  saisissiez  les  4  valeurs. Ne soyez pas decu. Voici un exemple
  d'utilisation   pour   un   controleur    WD1002    avec    un    BIOS
  inactive/supprime, utilisant les parametres `par defaut' du controleur
  XT :

  ______________________________________________________________________
          xd=2,5,0x320,3
  ______________________________________________________________________

  66..  CCDD--RROOMMss ((NNoonn--SSCCSSII//AATTAAPPII//IIDDEE))

  Cette section fait l'inventaire de tous les  parametres  de  demarrage
  possibles  pour  les lecteurs de CD-ROM. Ceci n'inclut pas les CD-ROMs
  SCSI ou IDE/ATAPI. Consultez les sections appropriees pour  ces  types
  de CD-ROMs.
  Notez  que  la plupart de ces CD-ROM ont des fichiers de documentation
  que vous  _d_e_v_r_i_e_z  lire,  et  ils  sont  tous  dans  le  repertoire  :
  linux/Documentation/cdrom.

  66..11..  LL''iinntteerrffaaccee AAzztteecchh ((``aazzttccdd==''))

  La syntaxe pour ce type de carte est :

  ______________________________________________________________________
          aztcd=iobase[,magic_number]
  ______________________________________________________________________

  Si  vous  positionnez le magic_number (nombre magique) a 0x79 alors le
  pilote   essaiera   puis   laissera   tomber   dans   le   cas   d'une
  microprogrammation   inconnue.   Toutes   les  autres  valeurs  seront
  ignorees.

  66..22..  LL''iinntteerrffaaccee SSoonnyy CCDDUU--3311AA eett CCDDUU--3333AA ((``ccdduu3311aa==''))

  On rencontre cette interface CD-ROM sur certaines cartes son Pro Audio
  Spectrum,  ainsi  que  sur  les autres cartes d'interface fournies par
  Sony.  La syntaxe est la suivante :

  ______________________________________________________________________
          cdu31a=iobase,[irq[,is_pas_card]]
  ______________________________________________________________________

  Le fait de specifier une valeur d'IRQ egale a zero indique  au  pilote
  que  les  interruptions  logicielles ne sont pas supportees (comme sur
  certaines cartes PAS). Si votre carte supporte les interruptions, vous
  devrez  les utiliser car elles abaissent la consommation de CPU par le
  pilote.

  Le `is_pas_card' peut-etre saisi sous la forme suivante `PAS' si  vous
  utilisez  une  carte  Pro  Audio  Spectrum,  mais on peut aussi ne pas
  l'indiquer.

  66..33..  LL''iinntteerrffaaccee SSoonnyy CCDDUU--553355 ((``ssoonnyyccdd553355==''))

  La syntaxe pour cette interface de CD-ROM est :

  ______________________________________________________________________
          sonycd535=iobase[,irq]
  ______________________________________________________________________

  La valeur zero peut-etre utilisee comme `bouche-trou' pour l'I/O  base
  si l'on desire specifier une valeur d'IRQ.

  66..44..  LL''iinntteerrffaaccee GGoollddSSttaarr ((``ggssccdd==''))

  La syntaxe pour cette interface de CD-ROM est :

  ______________________________________________________________________
          gscd=iobase
  ______________________________________________________________________

  66..55..  LL''iinntteerrffaaccee ssttaannddaarrdd MMiittssuummii ((``mmccdd==''))

  La syntaxe pour cette interface de CD-ROM est :

  ______________________________________________________________________
          mcd=iobase,[irq[,wait_value]]
  ______________________________________________________________________

  La  valeur  wait_value  est  utilisee  comme  une  valeur  interne  de
  depassement de temps pour les gens qui ont  des  problemes  avec  leur
  disques,  et  peut,  ou  non,  etre  implementee  en  fonctions  d'une
  instruction DEFINE lors de la compilation.

  66..66..  LL''iinntteerrffaaccee IISSPP1166 ((``iisspp1166==''))

  la syntaxe pour cette interface de CD-ROM est :

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

  Utiliser une valeur a 0 pour irq ou dma signifie qu'ils  ne  sont  pas
  utilises.  Les  valeurs possibles pour drive_type sont noisp16, Sanyo,
  Panasonic, Sony, et Mitsumi.  L'utilisation de noisp16  desactive  les
  lecteurs totalement.

  66..77..  LL''iinntteerrffaaccee MMiittssuummii XXAA//MMuullttiiSSeessssiioonn ((``mmccddxx==''))

  Pour  l'instant,  ce  pilote  `experimental'  possede  une fonction de
  configuration mais aucun parametre n'est  encore  implemente  (version
  1.3.15).   Le  materiel  est  le  meme  que  ci-dessus, mais le pilote
  possede de nouvelles fonctionnalites.

  66..88..  LL''iinntteerrffaaccee OOppttiiccss SSttoorraaggee ((``ooppttccdd==''))

  La syntaxe pour ce type de carte est :

  ______________________________________________________________________
          optcd=iobase
  ______________________________________________________________________

  66..99..  LL''iinntteerrffaaccee PPhhiilllliippss CCMM220066 ((``ccmm220066==''))

  La syntaxe pour ce type de carte est :

  ______________________________________________________________________
          cm206=[iobase][,irq]
  ______________________________________________________________________

  La valeur de l'IRQ est comprise entre 3  et  11,et  les  adresses  des
  ports d'entree/sortie sont comprises entre 0x300 et 0x370, vous pouvez
  donc specifier un ou deux nombres,  dans  n'importe  quel  ordre.   Il
  accepte aussi `cm206=auto' pour activer l'autotest.

  66..1100..  LL''iinntteerrffaaccee SSaannyyoo ((``ssjjccdd==''))

  La syntaxe pour ce type de carte est :

  ______________________________________________________________________
          sjcd=iobase[,irq[,dma_channel]]
  ______________________________________________________________________

  66..1111..  LL''iinntteerrffaaccee SSoouunnddBBllaasstteerr PPrroo ((``ssbbppccdd==''))

  La syntaxe de ce type de carte est :

  ______________________________________________________________________
          sbpcd=iobase,type
  ______________________________________________________________________

  Ou  type  prend  une des valeurs suivantes (Attention : le respect des
  majuscules  et  des  minuscules  est  important)   :   `SoundBlaster',
  `LaserMate',  ou  `SPEA'.  L'adresse d'entree/sortie de base est celle
  de l'interface de CD-ROM, et _n_o_n celle de la partie son de la carte.

  77..  AAuuttrreess PPeerriipphheerriiqquueess MMaatteerriieellss

  Tous les autres peripheriques qui ne peuvent etre classes dans une des
  categories ci-dessus sont entasses ici.

  77..11..  PPeerriipphheerriiqquueess EEtthheerrnneett ((``eetthheerr==''))

  Differents pilotes utilisent differents parametres, mais ils partagent
  tous au moins une IRQ, une adresse d'entree/sortie, et un nom. Dans sa
  forme la plus generique, cela ressemble a ca :

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

  Le  premier  argument  non-numerique  est  pris  comme nom.  La valeur
  param_n (si elle est applicable)  a  generalement  des  significations
  differentes  pour  chaque  carte/pilote.   Les  valeurs  courantes  de
  param_n sont utilisees pour indiquer des choses comme l'adresse de  la
  memoire  partagee,  la selection d'interface, le canal DMA et ainsi de
  suite.

  L'utilisation la plus courante de ce parametre est de forcer  le  test
  d'une  seconde  carte  ethernet,  alors que par defaut on en teste une
  seule. Ceci peut etre accompli avec un simple ordre :

  ______________________________________________________________________
          ether=0,0,eth1
  ______________________________________________________________________

  Notez que la valeur zero pour l'IRQ et l'I/O base dans  l'exemple  ci-
  dessus indiquent au pilote de faire un autotest.

  NOTE  IMPORTANTE POUR LES UTILISATEURS DE MODULES : ce qui est indique
  ci-dessus _n_e _f_o_r_c_e_r_a _p_a_s un autotest pour une seconde si vous utilisez
  les pilotes de peripheriques en tant que modules chargeables au moment
  de l'execution (au lieu de les avoir  compiles  dans  le  noyau).   La
  plupart   des  distributions  de  Linux  utilisent  un  noyau  central
  depouille combine avec une large selection de pilotes  modulaires.  Le
  parametre ether= s'applique seulement aux pilotes compiles directement
  dans le noyau.

  Le  Ethernet-HowTo  decrit  de  facon  exhaustive   l'utilisation   de
  plusieurs  cartes  simultanement, ainsi que la facon dont est utilisee
  la valeur param_n en fonction des specificites de chaque carte/pilote.
  Les  lecteurs  concernes  pourront  faire reference a la section de ce
  document correspondant a leur carte pour une information plus precise.
  Ethernet-HowTo <http://sunsite.unc.edu/mdw/HOWTO/Ethernet-HOWTO.html>

  77..22..  LLee ppiilloottee dduu LLeecctteeuurr ddee DDiissqquueetttteess ((``ffllooppppyy==''))

  Il  existe  de  nombreuses  options  pour  le  pilote  du  lecteur  de
  disquette, et qui sont listees  dans  le  fichier  README.fd  dans  le
  repertoire   linux/drivers/block.   Cette   information  est  extraite
  directement du fichier.

  floppy=mask,allowed_drive_mask

  Positionne le "bitmask" (masque binaire) des lecteurs autorises  a  la
  valeur mask. Par defaut, seules les unites 0 et 1 de chaque controleur
  de lecteur de disquette sont autorisees. Ceci est  fait  car  certains
  materiels  non-standards  (cartes  meres ASUS PCI) mettent la pagaille
  dans le clavier lorsque l'on accede aux unites 2 ou  3.  Cette  option
  est un peu obsolete en raison de l'option cmos.

  floppy=all_drives

  Positionne  le "bitmask" (masque binaire) des disques autorises a tous
  les disques. Utilisez ceci si vous  avez  plus  de  deux  lecteurs  de
  disquette connectes a un controleur de lecteur de disquettes.

  floppy=asus_pci

  Positionne le "bitmask" uniquement aux unites autorisees 0 et 1.  (Par
  defaut)

  floppy=daring

  Indique au pilote du lecteur de disquette que vous avez un  controleur
  de  lecteur  de  disquette  qui  se  conduit  bien.  Ceci  permet  des
  operations plus efficaces et plus discretes,  mais  peut  echouer  sur
  certains controleurs. Ceci peut accelerer certaines operations.

  floppy=0,daring

  Indique  au  pilote  du lecteur de disquette que votre controleur doit
  etre utilise avec precaution.

  floppy=one_fdc

  Indique au pilote de  lecteur  de  disquette  que  vous  n'avez  qu'un
  controleur de lecteur de disquette (Par defaut).

  floppy=two_fdc _o_u floppy=address,two_fdc

  Indique  au  pilote  de  lecteur  de  disquette  que  vous  avez  deux
  controleurs de lecteurs de disquette. Le second controleur est suppose
  etre  a  l'adresse  indiquee. Si l'adresse n'est pas donnee on suppose
  qu'elle est egale a 0x370.

  floppy=thinkpad

  Indique au pilote de lecteur de disquette que vous avez  un  Thinkpad.
  Les  Thinkpads  utilisent une convention inversee pour la "disk change
  line" (ligne de changement de disque).

  floppy=0,thinkpad

  Indique au pilote de lecteur de disquette que vous ne possedez pas  un
  Thinkpad.

  floppy=drive,type,cmos

  Positionne  le  type  cmos  du  drive a type.  De plus, ce lecteur est
  autorise dans le "bitmask" (masque binaire).  C'est pratique  si  vous
  avez  plus  de  deux  lecteurs  de  disquette (seuls deux peuvent etre
  decrits dans la cmos physique), ou si votre BIOS utilise  un  type  de
  CMOS  non-standard.  Si  l'on  positionne  le  CMOS  a 0 pour les deux
  premiers disques (par defaut) le pilote de lecteur  de  disquette  ira
  lire la cmos physique.

  floppy=unexpected_interrupts

  Imprime  un  message  d'alerte  lorsqu'une interruption inattendue est
  recue (comportement par defaut).

  floppy=no_unexpected_interrupts _o_r floppy=L40SX

  Ne pas imprimer de  message  lorsqu'une  interruption  inattendue  est
  recue.   Ceci  est  necessaire sur un IBM L40SX portable dans certains
  modes video (il semble qu'il y ait une interaction entre la  video  et
  les  disquettes).   Les  interruptions inattendues affectent seulement
  les performances, et peuvent etre ignorees sans crainte).

  77..33..  LLee ppiilloottee ddee ssoonnss ((``ssoouunndd==''))

  Le pilote de sons peut aussi recevoir des parametres de demarrage  qui
  ecraseront  les  valeurs  compilees  dans le programme. Ceci n'est pas
  recommande, et de plus c'est complexe. Ceci est decrit (etait decrit ?
  )    dans    le    fichier    Readme.Linux,    dans    le   repertoire
  linux/drivers/sound.  Il  accepte  de  recevoir  un  parametre  de  la
  forme :

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

  Ou  chaque  valeur  de deviceN est de la forme 0xTaaaId, et les octets
  sont utilises de la facon suivante :

  T - type de peripherique : 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16,
  7=SB16-MPU401

  aaa - adresse d'entree/sortie en hexadecimal.

  I - ligne d'interruption en hexadecimal (i.e 10=a, 11=b, ...).

  d - canal DMA.

  Comme  vous  pouvez  le voir, ceci reste assez malpropre et vous ferez
  mieux de compiler vos propres valeurs comme c'est recommande. Si  l'on
  utilise  un  parametre de demarrage `sound=0' on desactive entierement
  le pilote de sons.

  77..44..  LLee ppiilloottee ddee ssoouurriiss ssuurr bbuuss ""BBuuss MMoouussee"" ((``bbmmoouussee==''))

  Le pilote des souris sur bus accepte un seul  parametre,  qui  est  la
  valeur de l'IRQ materielle a utiliser.

  77..55..  LLee ppiilloottee MMSS BBuuss MMoouussee ((``mmssmmoouussee==''))

  Le pilote MS mouse accepte un seul parametre, qui correspond a l'IRQ a
  utiliser.
  77..66..  LLee ppiilloottee dd''iimmpprriimmaanntteess ((``llpp==''))

  Depuis le noyau 1.3.75, vous pouvez indiquer  au  pilote  d'imprimante
  quels  sont  les  ports  qu'il doit utiliser et ceux qu'il _n_e _d_o_i_t _p_a_s
  utiliser. Vous devriez l'utiliser si vous ne voulez pas que le  pilote
  demande  tous  les  ports  paralleles  disponibles, alors que d'autres
  pilotes (c.a.d. PLIP, PPA) peuvent aussi les utiliser.

  Le  format  du  parametre  est  des  paires  i/o,  IRQ.  Par  exemple,
  lp=0x3bc,0,0x378,7  utilisera le port d'adresse 0x3bc en mode IRQ-less
  (election), et utilisera l'IRQ 7 pour le port d'adresse 0x378. Le port
  0x278  (si  il y en a un) ne sera pas teste, jusqu'a ce que l'autotest
  soit  utilise  en  l'absence  d'un  parametre  `lp='  argument.   Pour
  desactiver totalement le pilote d'impression, on peut utiliser lp=0.

  77..77..  LLee ppiilloottee IICCNN IISSDDNN ((``iiccnn==''))

  Le  pilote  ISDN  necessite  un  parametre  de  demarrage  de la forme
  suivante :

  ______________________________________________________________________
          icn=iobase,membase,icn_id1,icn_id2
  ______________________________________________________________________

  ou iobase est l'adresse du port d'entree/sortie de la  carte,  membase
  est  l'adresse de base de la memoire partagee de la carte, et les deux
  icn_id sont des chaines d'identification ASCII uniques.

  77..88..  LLee ppiilloottee PPCCBBIITT IISSDDNN ((``ppccbbiitt==''))

  Ce parametre de demarrage utilise des paires de valeurs de la forme :

  ______________________________________________________________________
          pcbit=membase1,irq1[,membase2,irq2]
  ______________________________________________________________________

  ou membaseN est l'adresse de base de la memoire partagee de  la  Nieme
  carte,  et  irqN  est l'interruption de la Nieme carte.  La valeur par
  defaut est IRQ 5 et l'adresse de base 0xD0000.

  77..99..  LLee ppiilloottee TTeelleess IISSDDNN ((``tteelleess==''))

  Le pilote ISDN  necessite  un  parametre  de  demarrage  de  la  forme
  suivantenbsp;:

  ______________________________________________________________________
          teles=iobase,irq,membase,protocol,teles_id
  ______________________________________________________________________

  ou iobase est l'adresse du port e/s de la carte, membase est l'adresse
  de base de la  memoire  partagee,  irq  est  le  canal  d'interruption
  utilise par la carte, et teles_id est l'identifiant ASCII unique.

  77..1100..  LLee ppiilloottee DDiiggiiBBooaarrdd ((``ddiiggii==''))

  Le  pilote DigiBoard accepte une chaine de six identifiants ou entiers
  separes par des virgules. Les 6 valeurs dans l'ordre sont :

          Active/Desactive la carte
          Type de la carte_: PC/Xi(0), PC/Xe(1), PC/Xeve(2), PC/Xem(3)
          Active/Desactive la mise en ordre alternative des broches
          Nombre de ports sur cette carte
          Port E/S sur lequel la carte est configuree  (en HEXA si on
          utilise des chaines d'identification)
          Adresse de base de la fenetre memoire (en HEXA si on utilise les
          chaines d'identification)

  Un exemple de parametre de demarrage correct (dans  ses  deux  formes)
  est :

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

  Notez  que  le pilote prend les valeurs par defaut de 0x200 pour l'i/o
  et pour la memoire partagee  0xD0000  en  l'absence  de  parametre  de
  demarrage  digi=.  Il  n'y a pas d'autotest effectue.  Plus de details
  peuvent       etre        trouves        dans        le        fichier
  linux/Documentation/digiboard.txt.

  77..1111..  llee ppiilloottee RRIISSCCoomm//88 MMuullttiippoorrtt SSeerriiaall ((``rriissccoomm88==''))

  Jusqu'a  quatre  cartes  peuvent  etre  supportees  en fournissant une
  valeur d'E/S unique pour chaque carte installee.  Les  autres  details
  pourront-etre trouves dans le fichier linux/Documentation/riscom8.txt.

  77..1122..  LLee mmooddeemm SSeerriiee//PPaarraalllleellee RRaaddiioo BBaayyccoomm ((``bbaayyccoomm==''))

  Le format du parmetre de demarrage pour ces peripheriques  est  de  la
  forme :

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

  Utiliser modem=1 signifie que vous avez le peripherique ser12, modem=2
  signifie que vous  avez  le  peripherique  par96.  Utiliser  options=0
  signifie   l'utilisation   du  DCD  materiel,  et  options=1  signifie
  l'utilisation du DCD logiciel. L'io et l'irq  sont  l'adresse  I/O  de
  base  du port, et la valeur de l'interruption.  Il y a plus de details
  dans le fichier README.baycom qui est generalement dans le  repertoire
  /linux/drivers/char/.

  88..  CCoonncclluussiioonn

  Si   vous  avez  trouve  des  fautes  de  frappe  manifestes,  ou  des
  informations perimees dans ce document, faites le moi savoir.  Il  est
  facile de laisser passer quelque chose.

  Merci,

  Paul Gortmaker, Paul.Gortmaker@anu.edu.au

  Merci de faire parvenir vos remarques sur la traduction de ce document
  a Laurent Renaud, lrenaud@hol.fr

  (http://wwwperso.hol.fr/~lrenaud)

