<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.docbook.org/xml/4.3/docbookx.dtd" [
<!ENTITY guides "http://www.traduc.org/docs/guides/lecture/">
<!ENTITY howto "http://www.traduc.org/docs/howto/lecture/">
]>
<article lang="fr">
<articleinfo>
<title>Guide pratique du Plug-and-Play</title>
<subtitle>
Adaptation française du <foreignphrase>Plug-and-Play
HOWTO</foreignphrase>
</subtitle>
<authorgroup>
<author>
<firstname>David</firstname>
<othername role="mi">S.</othername>
<surname>Lawyer</surname>
<affiliation>
<address>
<email>dave CHEZ lafn POINT org</email>
</address>
</affiliation>
</author>
</authorgroup>
<othercredit role="traduction">
<firstname>Guillaume</firstname>
<surname>Lelarge</surname>
<contrib>Traduction française</contrib>
<email>gleu CHEZ wanadoo POINT fr</email>
</othercredit>
<othercredit role="publication">
<firstname>Jean-Philippe</firstname>
<surname>Guérard</surname>
<contrib>Préparation de la publication de la v.f.</contrib>
<email>fevrier CHEZ tigreraye POINT org</email>
</othercredit>
<revhistory>
<revision>
<revnumber>1.15.fr.0.9</revnumber>
<date>2007-09-04</date>
<authorinitials>GL, JPG</authorinitials>
<revremark>
Version française mise à jour mais non relue.
</revremark>
</revision>
<revision>
<revnumber>1.15</revnumber>
<date>2007-08-??</date>
<authorinitials>DSL</authorinitials>
</revision>
<revision>
<revnumber>1.14.fr.0.9</revnumber>
<date>2006-03-07</date>
<authorinitials>GL, JPG</authorinitials>
<revremark>
Version française mise à jour mais non relue.
Prise en compte des corrections suggérées par Jean-Philippe Guérard
et par Bernard Adrian.
</revremark>
</revision>
<revision>
<revnumber>1.14</revnumber>
<date>2006-02-??</date>
<authorinitials>DSL</authorinitials>
</revision>
<revision>
<revnumber>1.13.fr.0.9</revnumber>
<date>2005-08-22</date>
<authorinitials>GL, JPG</authorinitials>
<revremark>
Version française non relue. Prise en compte des
corrections suggérées par Black Myst.
</revremark>
</revision>
<revision>
<revnumber>1.13</revnumber>
<date>2005-08-??</date>
<authorinitials>DSL</authorinitials>
</revision>
<revision>
<revnumber>1.12</revnumber>
<date>2005-03-??</date>
<authorinitials>DSL</authorinitials>
</revision>
<revision>
<revnumber>1.11.fr.0.9</revnumber>
<date>2004-11-20</date>
<authorinitials>GL, JPG</authorinitials>
</revision>
<revision>
<revnumber>1.11</revnumber>
<date>2004-11-??</date>
<authorinitials>DSL</authorinitials>
</revision>
<revision>
<revnumber>1.10.fr.0.9</revnumber>
<date>2004-09-11</date>
<authorinitials>GL, JPG</authorinitials>
</revision>
<revision>
<revnumber>1.10</revnumber>
<date>2004-08-??</date>
<authorinitials>DSL</authorinitials>
</revision>
<revision>
<revnumber>1.09</revnumber>
<date>2004-08-??</date>
<authorinitials>DSL</authorinitials>
</revision>
<revision>
<revnumber>1.08.fr.0.9</revnumber>
<date>2004-07-22</date>
<authorinitials>GL</authorinitials>
</revision>
<revision>
<revnumber>1.08</revnumber>
<date>2004-06-??</date>
<authorinitials>DSL</authorinitials>
</revision>
<revision>
<revnumber>1.07.fr.0.9</revnumber>
<date>2003-09-27</date>
<authorinitials>GL</authorinitials>
</revision>
<revision>
<revnumber>1.07</revnumber>
<date>2002-08-??</date>
<authorinitials>DSL</authorinitials>
</revision>
<revision>
<revnumber>1.06.fr.0.9</revnumber>
<date>2003-05-08</date>
<authorinitials>GL</authorinitials>
</revision>
<revision>
<revnumber>1.06</revnumber>
<date>2002-09-??</date>
<authorinitials>DSL</authorinitials>
</revision>
</revhistory>
<copyright>
<year>1998</year>
<year>1999</year>
<year>2000</year>
<year>2001</year>
<year>2002</year>
<year>2003</year>
<year>2004</year>
<year>2005</year>
<year>2006</year>
<year>2007</year>
<holder>David S. Lawyer</holder>
</copyright>
<copyright>
<year>2003</year>
<year>2004</year>
<year>2005</year>
<year>2006</year>
<year>2007</year>
<holder>Guillaume Lelarge</holder>
<holder>Jean-Philippe Guérard</holder>
</copyright>
<!--
Revision history:
v1.15 Aug. 2007 Revised interrupt sections. Removed 2
redundant and confusing paragraphs containing a mystery function "h()"
v1.14 Feb. 2006: Revised "How Linux Does PnP"; LPC was intended to be
config. by the BIOS. Balancing IRQs. Linux can find drivers for
detected devices. Fixed typos "the the"
v1.13 July 2005: IRQ conflicts. Better clarity in resource
descriptions. /proc/bus. PCI configuration space accessed via IO
address space. More hardware detection tools. "Can't allocate
region" error message.
v1.12 Mar. 2005: /dev/eth0 doesn't exist anymore. Info in /sys and
/proc changed for kernel 2.6. PCI Config. address space is
"geographic". scanpci may find a device that lspci can't. Kernel may
assign addresses at boot-time.
v1.11 Nov. 2004: LPC bus. Format error (text in contents)
v1.10 August 2004: sysfs not yet as useful as claimed, obsolete card info
moved to "Historical" section.
v1.09 August 2004: Edited per long email from Ross Boylan
<ross@biostat.ucsf.edu>. Clarity re telling BIOS if it's a PnP OS.
/proc/isapnp covered. Typos fixed. sysfs in kernel 2.6.
v1.08 June 2004: Edited all except appendix for more clarity and to
correct some obsolete statements in view of the increasing PnP
abilities of Linux. Added brief info on "hot plug" and USB.
More I/0 space on PCI bus.
v1.07 August 2003: New M$ url, reserve resources for isa-pnp, lspci+,
scanport may not find hdw, finding dev. and config.
v1.06 September 2002: Revised about telling the BIOS if the OS is PnP
v1.05 July 2002: typos: or => of, and => an, A Allocate => Allocate,
programs => program; Dell PCs: "Plug and Play Configuration Error",
clarity on telling BIOS if your OS is PnP, "Intro to PnP" had truncated
sentence, routing IRQs on PCI clarified, Change of emphasis in entire
doc: Linux is now a PnP OS (sort of), PCI has almost replaced ISA
v1.04 March 2002 finding a device driver, PCI serial ports,
alias example in modules.conf, PnP needed for linmodems
v1.03 August 2001: error messages, boot-prompt parameters
v1.02 July 2001: PCI config regs.
v1.01 April 2001: less shortage today of bus-resources, clarity in sect. 2,
Windows 2000 OK (even if "not a PnP OS" in CMOS)
v1.00 November 2000: "skip file" workaround for reconfiguring under Windows.
PCI interrupt details: X, W were transposed, rewrote, mentioned MSI,
etc. General Introduction added. Revised "How Linux Does PnP",
etc.. Patching kernel to make it PnP no longer feasible. Drivers do
more now due to kernel-provided functions.
v0.12 June 2000 scanpci, workaround for Dos zeroing PCI IRQs.
v0.11 May 2000 scanport utility, many typos fixed, setpci hard to use
v0.10 2 March 2000 typo: /bus/pnp/devices, lspci+, book "Programming
..."
v0.09 /proc/bus/pci/devices too cryptic,
v0.08 my new email
v0.07 in Windows: remove devices
v0.06 Oct. 1999 in Windows: forced+, legacy into ESCD, pause key (bios)
v0.05 Aug. 1999 lspci, url for isapnp, tell the dev. driver, PCI still
needs PnP
v0.04 June 1999 alternatives to reinstall Windows?, add D.D. url
v0.03 May 1999 typos, reinstall Windows, clarity, removed D.D. url
v0.02 Apr. 1999 /proc/... doesn't show hdw config (except pci)
v0.01 Mar. 1999 serial PnP spec, PCI interrupts, no DMA on PCI,
dumpregs for pnpdump , Bus Mastering DMA, clarity rewrites, pciutils
kernel 2.2 /proc tree, IO range check, Windows may not update ESCD
v0.00 Nov. 1998
-->
<abstract><para>
Le Plug-and-Play (ou PnP) est un système de détection et de
configuration automatique du matériel PC. Ce guide pratique présente
en détail les différentes ressources bas niveau gérées par le Plug-and-Play,
telles que les adresses, les interruptions, et cætera. Ce guide couvre le
bus PCI (qui a été conçu dès le départ pour le Plug-and-Play) et
l'utilisation du Plug-and-Play sur l'ancien bus ISA. Si le
Plug-and-Play faisait son travail correctement, vous n'auriez pas
besoin de ce guide pratique. Dans le cas contraire ou si vous disposez
d'un vieux matériel qui n'utilise pas le Plug-and-Play pour toutes les
cartes, ce guide pratique vous aidera. Il ne couvre pas le UPnP
(<foreignphrase lang="en">Universal Plug and Play</foreignphrase>).
</para></abstract>
<releaseinfo>Version : 1.15.fr.0.9</releaseinfo>
<pubdate>2006-09-04</pubdate>
</articleinfo>
<sect1><title>Introduction</title>
<sect2><title>Droits d'utilisation, avertissements et remerciements</title>
<sect3><title>Copyright</title>
<important><para>
Le texte ci-dessous est la licence de ce document. Ce texte fait foi. Il
est composé de la licence (en anglais) du document original, suivi de la
licence (en français) de sa traduction.
</para></important>
<para>Copyright © 1998-2005 by David S. Lawyer
<email>dave CHEZ lafn POINT org</email>.</para>
<para>Please freely copy and distribute (sell or give away) this document
in any format. Send any corrections and comments to the document
maintainer. You may create a derivative work and distribute it
provided that you:</para>
<itemizedlist>
<listitem><para>
If it's not a translation: Email a copy of your derivative work (in a
format LDP accepts) to the author(s) and maintainer (could be the same
person). If you don't get a response then email the LDP (Linux
Documentation Project):
<email>submit CHEZ en POINT tldp POINT org</email>.
</para></listitem>
<listitem><para>
License the derivative work in the spirit of this license or use GPL.
Include a copyright notice and at least a pointer to the license
used.</para></listitem> <listitem><para>Give due credit to previous
authors and major contributors.
</para></listitem>
</itemizedlist>
<para>If you're considering making a derived work other than a translation, it's
requested that you discuss your plans with the current maintainer.</para>
</sect3>
<sect3><title>Droits d'utilisation</title>
<para>Copyright © 1998-2005 par David S. Lawyer
<email>dave CHEZ lafn POINT org</email>.
</para>
<para>Copyright © 2003-2005 par Guillaume
Lelarge <email>gleu CHEZ wanadoo POINT fr</email> & ? <email>?</email>.
</para>
<para>Vous pouvez copier et distribuer librement (vendre ou donner) ce document
quel que soit son format. Envoyez toute correction ou tout commentaire à
l'auteur du document. Vous pouvez créer et distribuer une version dérivée à
condition que :
<itemizedlist>
<listitem><para>
vous envoyez au gestionnaire et à l'auteur (s'il ne s'agit pas de la
même personne) une copie de votre travail par courrier électronique
(s'il ne s'agit pas d'une traduction) dans un format que le LDP
accepte. Si vous n'obtenez pas de réponse, alors envoyez votre
message au LDP (Linux Documentation Project) :
<email>submit CHEZ en POINT tldp POINT org</email> ;
</para></listitem>
<listitem><para>
la licence utilisée pour votre travail soit dans le même esprit que
cette licence ou utilise la licence GPL. Incluez les informations de
droit d'utilisation ou au moins un pointeur vers la licence
utilisée ;
</para></listitem>
<listitem><para>vous donnez crédit aux auteurs précédents et aux contributeurs
majeurs.</para></listitem>
</itemizedlist>
</para>
<para>Si vous pensez faire un travail dérivé autre qu'une traduction, vous devez
en discuter avec le gestionnaire actuel.</para>
</sect3>
<sect3><title>Avertissements</title>
<para>Bien que je n'aie pas essayé de vous tromper intentionnellement, il est
probable que des erreurs restent dans ce document. Faites-le moi savoir si vous
en trouvez. Comme il s'agit d'une documentation libre, il est évident que je ne
peux pas être tenu responsable des erreurs contenues dans ce texte.</para>
</sect3>
<sect3><title>Marques déposées</title>
<para>Tout nom de marque (avec une majuscule initiale tel que MS Windows) sera
supposé être une marque déposée. Elles appartiennent à leur propriétaires
respectifs.</para>
</sect3>
<sect3><title>Remerciements</title>
<para>
<itemizedlist>
<listitem><para>
Daniel Scott a relu ce document en mars 2000 et y a trouvé de
nombreuses erreurs ;
</para></listitem>
<listitem><para>
Pete Barrett a donné une astuce pour empêcher Windows de
réinitialiser les <acronym>IRQ</acronym>
<acronym>PCI</acronym> ;
</para></listitem>
<listitem><para>
Août 2004 : Ross Boylan a trouvé des erreurs et a
indiqué un manque de clarté dans la partie où on indique au
<acronym>BIOS</acronym> qu'il s'agit d'un système d'exploitation
<acronym>PnP</acronym>.
</para></listitem>
</itemizedlist>
</para>
</sect3>
</sect2>
<sect2><title>Plans futurs : vous pouvez aider</title>
<para>
Merci de m'indiquer toute erreur, que ce soit dans les faits, les
opinions, la logique, l'orthographe, la grammaire, la clarté, les liens,
et cætera. Mais tout d'abord, si la date du document est vieille de plus
de plusieurs mois, vérifiez que vous possédez bien la dernière version.
Envoyez-moi toute information que vous trouvez intéressante pour ce
document.
</para>
<para>Je n'ai pas encore étudié le code utilisé par les différents pilotes
Linux et par le noyau pour implémenter le Plug-and-Play. Mais, j'ai commencé à
jeter un œil, notamment aux commentaires. Donc, ce guide pratique est
encore incomplet. Il devrait expliquer plus en profondeur le <quote>hot
swapping</quote>, le <quote>hot-plug</quote> et le nouveau logiciel
<acronym>PnP</acronym> du noyau 2.6. Et il ne couvre pas le firewire. Il
comporte certainement quelques erreurs (faites-moi savoir où je me trompe). Dans
ce guide pratique, j'ai utilisé deux points d'interrogation (??) pour signaler
que je n'ai pas vraiment la réponse.</para>
</sect2>
<sect2><title>Nouvelles versions de ce guide pratique</title>
<para>De nouvelles versions du guide pratique Plug-and-Play devraient apparaître
tous les ans et seront disponibles à la navigation et en téléchargement sur
les sites miroirs du LDP. Pour une liste des sites miroirs, voir <ulink
url="http://www.tldp.org/mirrors.html"/>. Différents formats sont disponibles.
Si vous voulez seulement vérifier rapidement la date de la dernière version,
regardez sur <ulink url="&howto;Plug-and-Play-HOWTO.html"/>.
La version que vous lisez actuellement est la traduction française
de la v1.15, d'août 2007.</para>
</sect2>
<sect2><title>Nouveautés des dernières versions</title>
<para>Pour un historique complet des révisions, voir le fichier source
(dans son format DocBook SGML) sur <ulink
url="http://cvsview.tldp.org/index.cgi/LDP/howto/linuxdoc/Plug-and-Play-HOWTO.sgml."/>.
<itemizedlist>
<listitem><para>v1.15, Août 2007 : Révision de la section sur les
interruptions. Suppression de deux paragraphes redondants et confus portant
sur une mystérieuse fonction « h() ».</para></listitem>
<listitem><para>v1.14, Février 2006 : Révision de <quote>Comment Linux
gère-t'il le <acronym>PnP</acronym></quote> ; LPC devait être configuré
par le BIOS. Balance des <acronym>IRQ</acronym>. Linux peut trouver des
pilotes pour les périphériques détectés.</para></listitem>
<listitem><para>v1.13, Juillet 2005 : Conflit d'IRQ. Plus grande clarté
dans les descriptions des ressources. /proc/bus. Espace de configuration
PCI accédé via l'espace d'adressage des entrées/sorties. Plus d'outils de
détection de matériel. Message d'erreur <foreignphrase>Can't allocate
region</foreignphrase>.</para></listitem>
<listitem><para>v1.12, Mars 2005 : /dev/eth0 n'existe plus. Informations
modifiées dans /sys et /proc depuis le noyau 2.6. L'espace d'adressage de
la configuration PCI est <quote>géographique</quote>. scanpci pourrait
trouver un périphérique que lspci ne voit pas. Le noyau peut affecter des
adresses au démarrage.</para></listitem>
</itemizedlist>
</para>
</sect2>
<sect2><title>Introduction générale. Avez-vous besoin de ce guide
pratique ?</title>
<para>
Le Plug-and-Play (<acronym>PnP</acronym>) est un système détectant
automatiquement les périphériques tels que les disques, les cartes son,
les cartes réseau, les modems, et cætera. Il trouve tous les
périphériques du bus <acronym>PCI</acronym> et tous les périphériques
supportant <acronym>PnP</acronym> sur l'ancien bus
<acronym>ISA</acronym>. Avant <acronym>PnP</acronym>, beaucoup de
périphériques étaient automatiquement recherchés en utilisant des
méthodes non <acronym>PnP</acronym> mais n'étaient pas trouvés quelque
fois. <acronym>PnP</acronym> fournit un moyen de trouver tous les
périphériques supportant <acronym>PnP</acronym>. Il réalise aussi une
configuration de bas niveau de ces périphériques. Les périphériques non
<acronym>PnP</acronym> (et les périphériques <acronym>PnP</acronym>
ayant été correctement configurés avec <acronym>PnP</acronym>) peuvent
souvent être détectés par des méthodes n'utilisant pas
<acronym>PnP</acronym>. Le bus <acronym>PCI</acronym> a été conçu pour
le <acronym>PnP</acronym> alors que le vieux bus <acronym>ISA</acronym>
ne l'a pas été à ses origines mais son support lui a été ajouté plus
tard. Donc, souvent, <acronym>PnP</acronym> est utilisé pour signifier
uniquement <acronym>PnP</acronym> pour l'ancien bus
<acronym>ISA</acronym>. Par exemple, lorsque vous apercevez au démarrage
des messages d'isapnp du style : <quote>Plug & Play
device</quote>, cela signifie seulement qu'il y a un périphérique
<acronym>ISA</acronym> <acronym>PnP</acronym>. Dans ce guide pratique,
nous traitons à la fois le PnP du bus <acronym>ISA</acronym> et du bus
<acronym>PCI</acronym>.
</para>
<para>Avec le temps, le noyau Linux améliore son support de
<acronym>PnP</acronym>. À la fin du 20è siècle, on pouvait dire que Linux
n'était pas un système d'exploitation <acronym>PnP</acronym>. Mais il est dit
qu'avec la version 2.6 du noyau, Linux est maintenant totalement
compatible avec <acronym>PnP</acronym> (en supposant que le noyau est construit
avec le support de <acronym>PnP</acronym>). Bien que le système
<acronym>PnP</acronym> n'est pas centralisé comme cela peut l'être avec MS
Windows (et son registre), le <acronym>PnP</acronym> Linux décentralisé semble
fonctionner correctement.</para>
<para>Linux conserve la trace des affectations de ressources demandées par les
pilotes de périphériques et refuse toute requête s'il estime que cela causerait
un conflit. Le noyau fournit aussi des programmes que les pilotes de
périphériques peuvent appeler pour effectuer leurs opérations de plug-and-play.
Le noyau lit aussi tous les registres de configuration de tous les périphériques
<acronym>PnP</acronym> et maintient leur tables que les pilotes de périphériques
peuvent consulter. Cette table aide les pilotes à trouver leur matériel. Le
noyau 2.6 fournit aussi un meilleur support pour le
<quote>hot-plug</quote>.</para>
<para>Le <acronym>BIOS</acronym> de votre <acronym>PC</acronym> travaillera
certainement un peu pour le plug-and-play. Donc, si tout fonctionne en harmonie
avec <acronym>PnP</acronym>, vous pouvez utiliser votre ordinateur sans avoir
besoin de tout connaître sur le plug-and-play. Mais, si certains périphériques
supportés par Linux ne fonctionnent pas (parce qu'ils n'ont pas été repérés
par Linux ou parce qu'ils ont été mal configurés), vous aurez besoin de
lire au moins une partie de ce guide pratique. Vous en apprendrez sur le
<acronym>PnP</acronym> mais aussi sur la façon dont la communication prend place
dans un ordinateur. Si vous avez un ordinateur moderne avec un bus
<acronym>PCI</acronym> mais sans bus <acronym>ISA</acronym>, vous pouvez passer
les parties sur le bus <acronym>ISA</acronym>.</para>
<para>Si vous avez des problèmes avec un périphérique, regardez les
messages affichés lors du démarrage (remontez la liste avec
<keycombo><keycap>Shift</keycap><keycap>PageUp</keycap></keycombo>). Si
cela n'affiche pas aussi les messages du lancement, à partir du
<acronym>BIOS</acronym>,
utilisez la touche Pause (voir <xref linkend="pause_"/>).</para>
<para>Vérifiez
que vous utilisez le bon pilote pour un périphérique et que ce pilote est trouvé
et utilisé. Si le pilote est un module, tapez <command>insmod</command> (en tant
qu'utilisateur privilégié) pour voir s'il est chargé (et utilisé). Si ce n'est
pas un module, alors il doit être intégré au noyau.</para>
<para>Ce guide pratique ne couvre pas le problème de la recherche et de
l'installation de pilotes de périphériques. Peut-être qu'il devrait. Un des
problèmes possibles est qu'une carte (ou un autre périphérique physique) peut ne pas dire
le type de composants qu'elle utilise. Le nom du pilote correspond souvent au
nom de la puce et non pas au nom de la marque. Une façon de commencer la
vérification du pilote est de regarder s'il en est question dans la
documentation du noyau, dans un autre guide pratique ou plus généralement sur
Internet. Attention : de telles documentations peuvent ne plus être à jour.
</para>
<para>Les ordinateurs disposant de bus <acronym>PCI</acronym> (et sans bus
<acronym>ISA</acronym>) ont significativement réduit le nombre de points posant
problèmes. Concernant le bus <acronym>ISA</acronym> et le manque de support au niveau
noyau pour l'<acronym>ISA</acronym> <acronym>PnP</acronym> (avant le noyau 2.4),
beaucoup de choses
posaient problèmes. Rappelez-vous que, parfois les problèmes semblant être
relatifs à <acronym>PnP</acronym> sont dûs en réalité à un matériel défectueux
ou à un matériel non conforme aux spécifications <acronym>PnP</acronym>.</para>
</sect2>
</sect1>
<sect1><title>Ce que <acronym>PnP</acronym> doit faire : allouer des
<quote>ressources bus</quote></title>
<sect2><title>En quoi consiste le Plug-and-Play
(<acronym>PnP</acronym>) ?</title>
<para>Si vous ne comprenez pas cette section, lisez <link
linkend="dev_commun">Périphériques matériels et la communication avec ces
derniers</link>.</para>
<para>En simplifiant à l'extrême, Plug-and-Play indique aux pilotes de
périphériques où trouver les différents matériels (périphériques) tels que
modems, cartes réseau, cartes son, et cætera. La tâche du Plug-and-Play est de
faire correspondre les périphériques physiques avec les logiciels (pilotes de
périphériques) qui les font fonctionner, et d'établir des canaux de
communication entre chaque périphérique physique et son pilote. Pour ce faire,
<acronym>PnP</acronym> alloue les <quote>ressources bus</quote> suivantes
aux matériels : adresses d'entrée/sortie, plages mémoire,
<acronym>IRQ</acronym>, canaux <acronym>DMA</acronym> (uniquement pour les bus
<acronym>LPC</acronym> et <acronym>ISA</acronym>). Ces quatre dernières sont
parfois appelées des ressources de premier ordre ou simplement des ressources.
<acronym>PnP</acronym> maintient un enregistrement de ce qu'il fait et autorise
l'accès à ces informations aux pilotes de périphériques. Si vous ne comprenez
pas ce que sont ces quatre ressources bus, lisez les sous-sections suivantes de
ce guide pratique : Adresses d'entrée/sortie, <acronym>IRQ</acronym>,
Canaux <acronym>DMA</acronym>, Régions mémoire. Un article de la Linux Gazette
parle de trois des ressources bus. Il est disponible sur <ulink
url="http://www.linuxgazette.com/issue38/blanchard.html">
Introduction aux <acronym>IRQ</acronym>, <acronym>DMA</acronym> et adresses de
base</ulink> (NdT : une traduction française est disponible sur <ulink
url="http://www.linuxgazette.com/issue38/blanchard.html">traduc.org</ulink>).
Une fois que ces ressources bus ont été assignées (et si le bon pilote est
installé), le pilote actuel et ses <quote>fichiers</quote> du répertoire
<filename
class="directory">/dev</filename> sont prêt à être utilisés.</para>
<para>Cette méthode d'affectation <acronym>PnP</acronym> des ressources bus est
parfois appelée <quote>configuration</quote> mais il s'agit seulement d'une
configuration bas-niveau. Le répertoire <filename class="directory">/etc</filename>
comprend beaucoup de fichiers de configuration mais un grand nombre d'entre eux
ne concernent pas la configuration de <acronym>PnP</acronym>. Donc, la grande
majorité des configurations de périphériques physiques n'a rien à voir avec
<acronym>PnP</acronym> ou les ressources bus. Par exemple, l'initialisation d'un
modem par une phrase d'initialisation ou la configuration de sa vitesse ne
concerne pas <acronym>PnP</acronym>. Donc lorsque nous parlons de
<acronym>PnP</acronym>, la configuration ne concerne qu'un seul type de
configuration. Alors que d'autres documentations (telles que celles pour MS
Windows) appellent les ressources bus <quote>ressources</quote>, j'ai utilisé le
terme de
ressources bus au lieu du simple <quote>ressources</quote> pour les distinguer
des
nombreux autres types de ressources.
</para>
<para><acronym>PnP</acronym> est un long processus réalisé par différents logiciels
et matériels. Si seul un programme gérait <acronym>PnP</acronym> sur Linux,
cela serait simple. Mais, avec Linux, chaque pilote de périphérique fait son
propre <acronym>PnP</acronym> en utilisant le logiciel fourni par le noyau. Le
matériel du BIOS du PC utilise <acronym>PnP</acronym> au démarrage du PC. Et il
y a bien plus que cela.</para>
</sect2>
<sect2 id="dev_commun"><title>Périphériques matériels et la communication avec
ces derniers</title>
<para>Un ordinateur est composé d'un processeur (<acronym>CPU</acronym>)
réalisant
les opérations et de mémoire vive (<acronym>RAM</acronym>) pour stocker les
programmes et les données (en accès rapide). De plus, il existe de nombreux
périphériques tels que différents types de disques, une carte vidéo, un clavier,
des périphériques réseaux, des cartes modem, des périphériques sons, le bus
<acronym>USB</acronym>,
les ports séries et parallèles, et cætera. Dans les anciens temps, la plupart des
périphériques étaient des cartes insérées dans des emplacements du PC. Aujourd'hui,
beaucoup de périphériques, qui étaient auparavant des cartes, sont maintenant
compris dans les composants intégrés à la carte-mère. On trouve aussi une
alimentation apportant l'électricité, différents bus sur la carte mère pour
connecter les périphériques au <acronym>CPU</acronym> et une boîte pour contenir
le tout.</para>
<para>Les cartes se connectant sur la carte mère peuvent contenir plus d'un
périphérique. Les cartes mémoires sont quelque fois considérées comme des
périphériques mais ils ne sont pas Plug-and-Play si on suit le sens utilisé dans
ce guide pratique.</para>
<para>Pour que l'ordinateur fonctionne bien, chaque périphérique doit être sous
le contrôle de son <quote>pilote</quote>. Il s'agit d'un logiciel faisant partie du
système
d'exploitation, pouvant être chargé en tant que module et exécuté à partir du
<acronym>CPU</acronym>. Les pilotes de périphériques sont associés à des
<quote>fichiers spéciaux</quote> rangés dans le répertoire <filename
class="directory">/dev</filename>, bien qu'ils ne soient pas vraiment des
fichiers. Ils ont des noms tels que hda3 (troisième partition du disque a),
ttyS1 (deuxième port série), eth0 (première carte Ethernet), et cætera.</para>
<para>Le périphérique eth0 est celui de la carte ethernet (carte réseau).
Auparavant, il s'agissait de /dev/eth0 mais c'est maintenant un périphérique
virtuel du noyau. Ce que eth0 référence dépend du type de carte ethernet que
vous avez. Si le pilote est un module, cette affectation se trouve probablement
dans une table interne du noyau mais pourrait aussi se trouver dans
<filename>/etc/modules.conf</filename> (appelé <quote>alias</quote>). Par
exemple, si vous disposez d'une carte ethernet utilisant le composant
<quote>tulip</quote>, vous devez placer la ligne <quote>alias eth0 tulip</quote>
dans <filename>/etc/modules.conf</filename> pour que, lorsque votre PC cherche
eth0, il trouve le pilote tulip. Néanmoins, les noyaux modernes peuvent
généralement trouver le bon module du périphérique. De cette façon, vous n'aurez
pas à le spécifier vous-même.</para>
<para>Pour contrôler un périphérique, le <acronym>CPU</acronym> (sous le
contrôle du pilote de périphérique) envoie des commandes et des données du
périphérique. Il reçoit aussi l'état et des données des différents
périphériques. Pour cela, chaque pilote doit connaître l'adresse du périphérique
qu'il doit contrôler. Connaître cette adresse revient à mettre en place un canal
de communication, même si le <quote>canal</quote> physique se trouve être le bus
de données interne au PC, bus partagé avec beaucoup d'autres périphériques.</para>
<para>Ce canal de communication est en fait un peu plus complexe que ce qui est
décrit ci-dessus. Une <quote>adresse</quote> est en fait une plage d'adresses,
ce qui fait que, parfois, le mot <quote>plage</quote> est utilisé à la place du
mot <quote>adresse</quote>. Il peut exister plus d'une plage (sans recoupement)
pour un seul périphérique. Il existe aussi un autre canal connu sous le nom
d'interruptions permettant au périphérique d'envoyer une requête de
<quote>demande d'aide</quote> urgente à leur pilote.
</para>
</sect2>
<sect2><title>Adresses</title>
<para>Le bus PCI a trois plages d'adressage : les entrées/sorties,
la mémoire principale (mémoire d'entrées/sorties) et la configuration.
L'ancien bus <acronym>ISA</acronym> ne dispose pas de cette dernière.
Seules les entrées/sorties et la mémoire principale sont utilisées pour
les entrées/sorties du périphérique. Les adresses de configuration sont
fixes et ne peuvent pas être modifiées donc elles n'ont pas besoin
d'être affectées. Pour plus d'informations, voir <link
linkend="pci_conf">Espace d'adressage de la configuration
PCI</link>.</para>
<para>Quand le CPU veut accéder à un périphérique, il place l'adresse du
périphérique sur un bus important de l'ordinateur (pour le PCI : le
bus d'adresse/données). Tous les types d'adresses (tels que les
entrées/sorties et la mémoire principale) partagent le même bus sur le
PC. Mais la présence ou l'absence de voltage sur certains fils dédiés
sur le bus du PC indique l'espace occupée par une adresse :
entrée/sortie, mémoire principale (voir <link linkend="mem_">Espaces
d'adressage</link>) ou la configuration (seulement PCI). Ceci est un peu
trop simplifié car indiquer à un périphérique PCI qu'il s'agit d'une
adresse de configuration est réellement plus complexe que la description
ci-dessus. Voir <link linkend="pci_conf">Espace d'adressage pour la
configuration PCI</link> pour plus d'informations. Voir <link
linkend="address_details">Détails des adresses</link> pour plus
d'informations sur l'adressage en général.</para>
<para>Les adresses d'un périphérique sont stockées dans les registres du
matériel physique. Elles peuvent être changées par logiciel et elles peuvent
être désactivées pour que le périphérique ne soit plus adressable, sauf en ce
qui concerne les adresses de configuration du PCI qui ne peuvent être ni
modifiées ni désactivées.</para>
</sect2>
<sect2><title>Adresses d'entrées/sorties (principes relatifs à d'autres
ressources)</title>
<para>Les périphériques étaient originellement situés dans la plage d'adresses
des entrées/sorties mais, aujourd'hui, ils peuvent utiliser la plage en mémoire
principale. Une adresse d'entrée/sortie est quelque fois simplement appelée
<quote>I/O</quote>, <quote>IO</quote>, <quote>i/o</quote> ou <quote>io</quote>.
Les termes <quote>port I/O</quote> ou <quote>plage d'entrées/sorties</quote>
sont aussi utilisés. Ne confondez pas ces ports d'entrées/sorties avec la
mémoire d'entrées/sorties située en mémoire principale. Il existe deux étapes
principales pour allouer des adresses I/O (ou d'autres ressources bus telles que
les interruptions sur le bus <acronym>ISA</acronym>) :
<itemizedlist>
<listitem><para>Initialiser l'adresse I/O, et cætera. dans le matériel (dans un de ses
registres),</para></listitem>
<listitem><para>Laisser son pilote de périphérique reconnaître l'adresse I/O,
et cætera.</para></listitem>
</itemizedlist>
</para>
<para>Souvent, le pilote du périphérique fait les deux (en quelque sorte).
Le pilote de périphérique n'a pas réellement besoin d'initialiser une
adresse d'entrée/sortie s'il découvre que l'adresse a déjà été initialisée
(peut-être par le <acronym>BIOS</acronym>) et qu'il souhaite accepter cette
adresse. Une fois que le pilote a soit trouvé une adresse précédemment
configurée soit configuré l'adresse lui-même, alors il sait évidemment de quelle
adresse il s'agit, donc il n'est pas nécessaire de lui fournir cette
information -- il la connaît déjà.</para>
<para>Le processus en deux étapes ci-dessus (1. configurer l'adresse au niveau
matériel. 2. mettre au courant le pilote.) ressemble aux deux
parties d'un problème pour trouver le numéro de la maison d'une personne dans
la rue. Quelqu'un doit installer un numéro sur l'entrée de la maison pour
qu'elle puisse être trouvée, puis les personnes qui souhaitent aller à cette
adresse doivent obtenir (et conserver) ce numéro pour qu'elles puissent trouver
la maison. En informatique, le matériel du périphérique doit d'abord obtenir
son adresse, qu'il placera dans un registre matériel spécial (ce qui revient à
conserver le numéro dans notre exemple), puis le pilote de périphérique doit obtenir
cette adresse (écrire ce numéro dans son carnet d'adresses). Les deux doivent
être réalisés, soit automatiquement par le logiciel soit en saisissant
manuellement des données dans des fichiers de configuration. Des problèmes
pourraient survenir si seulement un des deux est fait correctement.</para>
<para>Pour la configuration manuelle de <acronym>PnP</acronym>, des personnes
font l'erreur de ne faire qu'une de ces deux étapes et se demandent ensuite pourquoi
l'ordinateur ne peut pas trouver le périphérique. Par exemple, ils utilisent
<command>setserial</command> pour associer une adresse au port série sans
réaliser que ceci ne fait que donner une adresse au pilote. Cela n'enregistre
pas cette adresse au niveau du port série physique. Si vous avez dit une bêtise
au port série, alors vous avez un problème. Une autre façon de parler au pilote
est de donner l'adresse comme option au module du noyau (pilote de périphérique).
Si ce que vous dites est faux, il peut y avoir des problèmes. Un pilote
intelligent pourrait détecter comment le matériel est réellement configuré
et rejeter les mauvaises informations fournies par l'option (ou au moins
afficher un message d'erreur).</para>
<para>
Un pré-requis évident est que le périphérique physique (comme une carte)
doit connaître son adresse avant le pilote du périphérique. Comme les
pilotes de périphérique se lancent souvent tout de suite après le
démarrage de l'ordinateur, ils peuvent tenter d'accéder à une carte
(pour vérifier sa présence, et cætera) avant que l'adresse ne soit
enregistrée au niveau de la carte par le programme de configuration
<acronym>PnP</acronym>. Et vous verrez un message d'erreur indiquant
l'absence de la carte même si elle est bien dans le PC (mais n'a pas
encore obtenue son adresse).
</para>
<para>Ce qui a été dit dans les derniers paragraphes concernant les
adresses I/O s'applique de la même manière à la majorité des autres
ressources bus : <xref linkend="mem_"/>, <xref
linkend="interrupt_over"/> et <xref linkend="dma_"/>. Les trois
prochaines sections expliqueront ce qu'ils sont. La seule exception est
que les interruptions du bus <acronym>PCI</acronym> ne sont pas
données par les registres d'une carte mais elles sont plutôt déroutées
vers les <acronym>IRQ</acronym> par un composant de la carte mère. Ensuite,
l'<acronym>IRQ</acronym> utilisée par cette carte <acronym>PCI</acronym> est
inscrite dans un registre de la carte dans un but unique d'informer.</para>
<para>Pour voir quelles adresses d'entrées/sorties sont utilisées sur votre
<acronym>PC</acronym>, regardez dans le fichier
<filename>/proc/ioports</filename>.</para>
</sect2>
<sect2 id="mem_"><title>Plages mémoire</title>
<para>Beaucoup de périphériques disposent d'une plage mémoire en mémoire
principale. C'est quelquefois appelé <quote>mémoire partagée</quote> ou
<quote>mémoire d'entrées/sorties</quote>. Cette mémoire est située physiquement
dans le périphérique physique mais l'ordinateur y accède comme s'il accédait à
des composants mémoire. En parlant de ressources bus, c'est souvent
simplement appelé <quote>mémoire</quote>, <quote>mem</quote>, voire
<quote>iomem</quote>. En plus de l'utilisation de cette <quote>mémoire</quote>,
un tel périphérique peut aussi utiliser une plage mémoire conventionnelle
d'entrées/sorties. Pour connaître la mémoire utilisée sur votre ordinateur,
cherchez dans <filename>/proc/iomem</filename>. Ce <quote>fichier</quote> inclut
la mémoire utilisée par les composants mémoire habituels de la RAM, donc il
affiche l'allocation mémoire en général et pas seulement l'allocation iomem.
Si vous apercevez un numéro étrange au lieu d'un nom, c'est probablement le
numéro d'un périphérique PCI, ce que vous pouvez vérifier en exécutant
<quote>lspci</quote>.</para>
<para>Lorsque vous insérez une carte utilisant iomem, vous êtes aussi en train
d'insérer un module mémoire pour la mémoire principale. Une adresse haute est
sélectionnée pour lui par <acronym>PnP</acronym> de façon à ce que cela ne
rentre pas en conflit avec les modules de la mémoire principale (composants).
Cette mémoire peut être de la mémoire morte (<acronym>ROM</acronym> ou Read Only
Memory) ou de la mémoire partagée. Cette dernière est partagée entre le
périphérique et le <acronym>CPU</acronym> (ayant lancé le pilote du
périphérique) de la même façon que la plage d'adresses d'entrées/sorties est
partagée entre le périphérique et le <acronym>CPU</acronym>. Cette mémoire
partagée sert en tant que moyen de <quote>transfert</quote> de données entre le
périphérique et la mémoire principale. C'est de l'entrée/sortie mais ce n'est
pas fait dans la plage d'adresses des entrées/sorties. La carte et le pilote
doivent connaître la plage d'adresses.</para>
<para>La <acronym>ROM</acronym> (<foreignphrase>Read-Only Memory</foreignphrase>,
soit mémoire en lecture seule) est un genre différent d'iomem. C'est plutôt un
programme (parfois un pilote de périphérique), utilisé avec ce périphérique.
Cela peut aussi être un code d'initialisation malgré que le pilote soit encore
nécessaire. Avec un peu de chance, il fonctionnera aussi sous Linux, et pas
seulement sous MS Windows. Elle peut être copiée en mémoire principale pour
fonctionner plus rapidement. Mais dans ce cas, elle n'est plus <quote>en lecture
seule</quote>.</para>
</sect2>
<sect2 id="interrupt_over"><title><acronym>IRQ</acronym> - un aperçu</title>
<para>Après avoir lu ceci, vous pouvez lire <xref
linkend="interrupt_detail"/> pour bien plus de détails. Ce qui suit
est volontairement simplifié : en plus des adresses, il existe
aussi un numéro d'interruption à gérer (tel que l'<acronym>IRQ</acronym>
5). Cela s'appelle un numéro d'<acronym>IRQ</acronym> (Interrupt
ReQuest, ou demande d'interruption), ou plus simplement une
<quote>irq</quote>. Nous avons déjà mentionné ci-dessus que le pilote de
périphérique doit connaître l'adresse d'une carte pour être capable de
communiquer avec elle. </para>
<para>Mais qu'en est-il de la communication en sens inverse ? Supposez que
le périphérique ait besoin de dire quelque chose à son pilote immédiatement.
Par exemple, le périphérique peut recevoir un grand nombre d'octets destinés à
la mémoire principale et le tampon utilisé pour stocker ces octets est
pratiquement plein. Du coup, le périphérique a besoin de demander à son pilote
de récupérer ces octets avant que le tampon ne se voit dépassé par le flot continu
d'octets. Un autre exemple serait de signaler au pilote que le périphérique a
terminé d'envoyer un ensemble d'octets et qu'il attend maintenant de nouveaux
octets à envoyer.</para>
<para>Comment le périphérique peut-il envoyer rapidement un signal à son
pilote ?
Il peut ne pas être capable d'utiliser le bus de données principal car il y a
des chances qu'il soit déjà utilisé. Au lieu de cela, il place un voltage sur
un fil d'interruption dédié (aussi appelé ligne ou trace) qui est souvent réservé
pour ce seul périphérique. Ce signal est appelé une demande d'interruption
(<acronym>IRQ</acronym>) ou plus simplement une <quote>interruption</quote>. Il
existe l'équivalent de 16 (ou 24, et cætera.) fils de ce type dans un PC et chaque fil amène
(indirectement) à un certain pilote de périphérique. Chaque fil a un numéro
d'<acronym>IRQ</acronym> unique. Le périphérique doit placer son interruption
sur le bon fil. Le fil sur lequel le périphérique envoie ces demandes
d'aide est déterminé par le numéro d'<acronym>IRQ</acronym> enregistré dans le
périphérique. Ce même numéro d'<acronym>IRQ</acronym> doit être connu par le
pilote du périphérique pour que celui-ci sache quelle interruption écouter.
</para>
<para>Une fois que le pilote reçoit l'interruption du périphérique, il
doit trouver pourquoi cette interruption a été générée et agir de
manière appropriée pour régler le problème. Sur le bus
<acronym>ISA</acronym>, chaque périphérique a habituellement besoin de
son propre numéro unique d'<acronym>IRQ</acronym>. Pour le bus
<acronym>PCI</acronym> et dans d'autres cas spéciaux, le partage
d'<acronym>IRQ</acronym> est autorisé (deux périphériques <acronym>PCI</acronym>,
ou plus, pourraient avoir le même numéro d'<acronym>IRQ</acronym>).
De même, pour le <acronym>PCI</acronym>, chaque périphérique <acronym>PCI</acronym>
a un fil fixe <foreignphrase>PCI Interrupt</foreignphrase>. Mais un composant
de routage programmable fait correspondre les fils <acronym>PCI</acronym> aux
interruptions de type <acronym>ISA</acronym>. Voir <xref
linkend="interrupt_detail"/> pour savoir comment cela fonctionne.</para>
</sect2>
<sect2 id="dma_"><title><acronym>DMA</acronym> (accès direct à la
mémoire) ou maîtrise du bus</title>
<para>Pour le bus <acronym>PCI</acronym>, <acronym>DMA</acronym> et maîtrise de
bus signifient la même chose. Avant l'arrivée du bus <acronym>PCI</acronym>, la
maîtrise du bus était rare et le <acronym>DMA</acronym> fonctionnait différemment
et était lent. L'accès direct à la mémoire (<acronym>DMA</acronym>, acronyme de
<foreignphrase>Direct Memory Access</foreignphrase>) est ce qui permet à un
périphérique de prendre la main sur le bus principal de l'ordinateur et de
transférer directement des octets vers la mémoire principale ou vers d'autres
périphériques. Normalement, le processeur s'occupe des transferts d'un
périphérique vers la mémoire principale par un processus en deux
étapes :</para>
<itemizedlist>
<listitem><para>lire un ensemble d'octets à partir de la page mémoire
d'entrées/sorties et les stocker dans le <acronym>CPU</acronym> lui-même ;
</para></listitem>
<listitem><para>écrire ces octets dans la mémoire principale.</para>
</listitem>
</itemizedlist>
<para>Avec le <acronym>DMA</acronym>, il s'agit d'un processus en une seule
étape consistant en l'envoi des octets directement du périphérique à la
mémoire. Les périphériques doivent disposer de capacités <acronym>DMA</acronym>
intégrées et, du coup, tous les périphériques ne peuvent pas faire de
<acronym>DMA</acronym>. Alors que le <acronym>DMA</acronym> est en cours, le
processeur ne peut pas faire grand chose car le bus principal est en cours
d'utilisation par le transfert <acronym>DMA</acronym>.</para>
<para>L'ancien bus <acronym>ISA</acronym> peut faire du <acronym>DMA</acronym>
lentement alors que le bus <acronym>PCI</acronym> peut faire du
<acronym>DMA</acronym> par maîtrise du bus. Le bus <acronym>LPC</acronym> a à
la fois l'ancien et le nouveau <acronym>DMA</acronym> (maîtrise du bus). Sur le
bus <acronym>PCI</acronym>, ce qui devrait être appelé plus précisément
« maîtrise du bus » est souvent appelé « Ultra DMA », « BM-DNA », « udma » ou
tout simplement « DMA ». Sur le bus <acronym>PCI</acronym>, la maîtrise du bus
est souvent appelé <acronym>DMA</acronym>. La maîtrise du bus permet aux
périphériques de devenir temporairement les maîtres du bus et de transférer des
octets un peu comme lorsque le maître du bus était le processeur. Il n'utilise
aucun numéro de canal car l'organisation du bus <acronym>PCI</acronym>
est telle que le matériel <acronym>PCI</acronym> sait quel
périphérique est actuellement le maître du bus et quel périphérique
réclame à devenir le maître du bus. Du coup, il n'y a pas d'allocation de
ressources pour les canaux <acronym>DMA</acronym> pour le bus
<acronym>PCI</acronym> et aucune ressource de canaux <acronym>DMA</acronym>
n'existe pour ce bus. Le bus <acronym>LPC</acronym> est supposé être
configuré par le <acronym>BIOS</acronym> pour que les utilisateurs n'aient
pas à se soucier des canaux <acronym>DMA</acronym>.</para>
</sect2>
<sect2 id="dma_isa"><title>Canaux <acronym>DMA</acronym> (non pas pour le bus
<acronym>PCI</acronym>)</title>
<para>C'est seulement pour l'ancien bus ISA et le bus LPC. Quand un périphérique veut faire du
DMA, il lance une requête de DMA en utilisant les fils dédiés à cela, un peu
comme une requête d'interruption. En fait, le DMA aurait pû être géré en
utilisant des interruptions mais cela aurait introduit des délais, donc il est
plus rapide de faire cela en ayant un type spécial d'interruption connu en tant
que requête DMA. Comme les interruptions, les demandes DMA sont numérotées pour
identifier le périphérique lançant la requête. Ce nombre est appelé un canal DMA.
Comme les transferts DMA utilisant tous le bus principal (et qu'un seul peut être
lancé à la fois), ils utilisent tous les même canal pour le flot de données mais
le numéro de <quote>canal DMA</quote> sert à identifier qui utilise le canal. Les
registres matériels existent sur la carte mère, qui enregistre l'état actuel de
chaque canal. Du coup, pour lancer une requête DMA, le périphérique doit connaître
son numéro de canal DMA stocké dans un registre spécial du périphérique physique.
</para>
</sect2>
<sect2><title><quote>Ressources</quote> du périphérique et du pilote</title>
<para>Donc, les pilotes de périphériques doivent être <quote>attachés</quote>
d'une façon quelconque au matériel qu'ils contrôlent. Ceci se fait en allouant
des ressources bus (I/O, mémoire, <acronym>IRQ</acronym>, <acronym>DMA</acronym>)
au périphérique physique et en laissant le pilote le découvrir. Par exemple,
un port série utilise seulement deux ressources : une
<acronym>IRQ</acronym> et une adresse d'entrées/sorties. Ces deux valeurs
doivent être fournies au pilote et au périphérique physique. Le pilote (et son
périphérique) dispose d'un nom dans le répertoire /dev (tel que ttyS1).
L'adresse et le numéro <acronym>IRQ</acronym> sont stockés par le périphérique
physique dans ses registres de configuration sur sa carte (ou dans un composant
de la carte mère). Les vieux matériels (dans les années 1990) utilisaient des
interrupteurs (ou des cavaliers) pour configurer physiquement l'<acronym>IRQ</acronym>
et l'adresse au niveau du matériel. Ce paramétrage restera fixe tant qu'une
personne n'enlevera pas le boîtier pour déplacer les cavaliers.</para>
<para>Mais, dans le cas de <acronym>PnP</acronym> (pas de cavaliers), les données
du registre de configuration sont habituellement perdues lorsque le PC est
éteint, donc les données des ressources bus doivent être fournies à chaque
périphérique à chaque allumage du PC.</para>
</sect2>
<sect2><title>Les ressources sont limitées</title>
<sect3><title>L'ordinateur idéal</title>
<para>
L'architecture du PC n'apporte qu'un nombre limité de ressources :
<acronym>IRQ</acronym>, canaux <acronym>DMA</acronym>, adresses
d'entrées/sorties et de plages mémoires. S'il n'existait qu'un
nombre limité de périphériques et qu'ils aient tous des ressources bus
standardisées (telles que des adresses d'entrées/sorties et des numéros
d'<acronym>IRQ</acronym> uniques), il n'y aurait aucun souci pour
attacher un pilote à son périphérique. Chaque périphérique devrait avoir
un nombre fixe de ressources qui n'entreraient pas en conflit avec tout
autre périphérique sur votre ordinateur. Deux périphériques ne devraient
pas avoir les mêmes adresses, il n'y aurait pas de conflit
d'<acronym>IRQ</acronym> sur le bus <acronym>ISA</acronym>, et cætera.
Chaque pilote devrait être développé avec des adresses, des
<acronym>IRQ</acronym>, et cætera, uniques codées en dur dans le
programme. La vie serait simple.
</para>
<para>Une autre façon d'empêcher les conflits d'adresses serait d'avoir un
numéro d'emplacement, inclus dans l'adresse, pour chaque carte. Du coup, il n'y
aurait plus de conflits d'adresses entre deux cartes différentes (car elles
sont dans des emplacements différents). La conception des cartes ne permettrait
pas les conflits d'adresses entre les différentes fonctions de la carte. Il en
ressort que l'espace d'adressage (utilisé pour la demande et l'affectation de
ressources) le fait réellement. Mais cela n'est pas pris en compte pour les
adresses d'entrées/sorties et pour les régions mémoire. Partager des IRQ comme
sur le bus PCI évite aussi des conflits mais peut poser d'autres problèmes.</para>
</sect3>
<sect3><title>L'ordinateur réel</title>
<para>Mais l'architecture du PC a des problèmes de conflit. L'augmentation
du nombre de périphériques (incluant les multiples périphériques de même type)
a tendance à augmenter les conflits potentiels. En même temps, l'introduction
du bus PCI, où deux périphériques ou plus peuvent partager la même interruption
et l'introduction d'interruptions supplémentaires,
a tendance à réduire les conflits. Le résultat global, dû au passage au PCI,
a été une réduction des conflits car les ressources les plus faibles sont les
IRQ. Néanmoins, même sur le bus PCI, c'est un peu plus efficace pour éviter le
partage des IRQ. Dans certains cas où les interruptions arrivent en une
succession rapide et doivent être traitées rapidement (comme en audio),
le partage peut causer des dégradations dans les performances. Donc, il
n'est pas bon d'affecter tous les périphériques <acronym>PCI</acronym>
au même <acronym>IRQ</acronym>, l'affectation doit être partagée. Néanmoins,
certaines personnes trouvent que tous les périphériques <acronym>PCI</acronym>
sont sur la même <acronym>IRQ</acronym>.</para>
<para>Donc, les périphériques ont besoin d'avoir de la flexibilité de façon à ce
qu'ils puissent être initialisés avec n'importe quelle adresse,
<acronym>IRQ</acronym>, et cætera. C'est nécessaire pour éviter tout conflit et arriver
à un point d'équilibre. Mais quelques <acronym>IRQ</acronym> et adresses sont
pratiquement des standards, comme ceux de l'horloge et du clavier. Ils n'ont pas
besoin d'une telle flexibilité.</para>
<para>En plus du problème de conflit lors de l'allocation des ressources bus,
une indication erronée en indiquant au pilote de périphérique quelles sont les
ressources bus peut causer un autre problème. Cela a plus de chances d'arriver
dans le cas de la configuration manuelle où l'utilisateur saisit les ressources
utilisées dans un fichier de configuration sur le disque dur. Ceci fonctionne
généralement bien quand les ressources sont initialisées avec des cavaliers sur
les cartes (en supposant que l'utilisateur sache comment elles étaient
initialisées et n'a fait aucune faute en saisissant ces données dans les fichiers
de configuration). Mais, avec des ressources configurées par un logiciel
<acronym>PnP</acronym>, elles ne seront pas toujours identiques et cela
pourrait poser problème pour toute configuration manuelle où l'utilisateur saisit
les valeurs des ressources bus configurées par <acronym>PnP</acronym>.</para>
<para>L'allocation de ressources bus, lorsqu'elle est faite correctement, établit
des canaux de communications sans conflit entre le matériel physique et le
pilote associé. Par exemple, si une certaine plage mémoire d'entrées/sorties
(ressource) est allouée à la fois au pilote de périphérique et au matériel,
alors cela a établi une communication sur une voie à sens unique entre eux. Le
pilote peut envoyer des commandes et des informations au périphérique. C'est
donc un peu plus qu'une voie à sens unique car le pilote peut obtenir des
informations du périphérique en lisant ces registres. Mais le périphérique ne
peut pas initier une communication de cette façon. Pour initier une
communication, le périphérique a besoin d'une <acronym>IRQ</acronym> pour qu'il
puisse envoyer une interruption à son pilote. Ceci crée un canal de
communication à double-sens où le périphérique physique et son pilote peuvent
initier une communication.</para>
</sect3>
</sect2>
</sect1>
<sect1><title>Deuxième introduction au Plug-and-Play (<acronym>PnP</acronym>)</title>
<sect2><title>Introduction à <acronym>PnP</acronym></title>
<para>Le terme Plug-and-Play (<acronym>PnP</acronym>) a différentes
significations. Au sens général, il s'agit de la configuration automatique
lorsqu'une personne connecte un périphérique et que celui-ci se configure
lui-même. Le sens utilisé dans ce livre est tout autre :
<acronym>PnP</acronym> signifie la
configuration des ressources bus pour <acronym>PnP</acronym> (les configurer au
niveau des périphériques physiques) et la communication de cette information aux pilotes
de périphériques. Dans le cas de Linux, il s'agit souvent d'un pilote
déterminant la façon dont le bus a initialisé les ressources bus et, si
nécessaire, le pilote donnant une commande pour changer (réinitialiser) les
ressources bus. Souvent, <quote>PnP</quote> ne signifie que <acronym>PnP</acronym>
sur le bus <acronym>ISA</acronym> donc le message
d'isapnp, <quote>No Plug and Play device found</quote>, signifie simplement qu'aucun
périphérique <acronym>ISA</acronym> <acronym>PnP</acronym> n'a été trouvé. Les
spécifications du <acronym>PCI</acronym> standard (inventé
avant l'utilisation du terme <quote>PnP</quote>) apportent l'équivalent de
<acronym>PnP</acronym> au
bus <acronym>PCI</acronym>.</para>
<para><acronym>PnP</acronym> fait correspondre les périphériques avec leur
pilote et spécifie leurs canaux de communication (en allouant des ressources
bus). Il communique électroniquement avec les registres de configuration situés
à l'intérieur des périphériques physiques en utilisant un protocole standardisé.
Sur le bus <acronym>ISA</acronym> et avant le Plug-and-Play, les ressources bus
étaient simplement initialisées au niveau matériel avec des interrupteurs de
différentes sortes. Quelquefois, les ressources bus pouvaient être configurées
sur le matériel par un pilote (généralement écrit seulement pour un système MS
mais dans de rares cas supporté aussi par un pilote Linux). Cela ressemblait à du
<acronym>PnP</acronym> mais aucun protocole standardisé n'était utilisé donc il
ne s'agissait pas vraiment de <acronym>PnP</acronym>. Certaines cartes contiennent
un paramètrage par cavaliers qui peut être surchargé par un tel pilote. Pour Linux
avant le <acronym>PnP</acronym>, les ressources bus étaient affectées aux pilotes
logiciels par des fichiers de
configuration (ou autre chose de ce genre) ou en parcourant le bus aux adresses
où il s'attendait à trouver le périphérique. Mais ces méthodes sont toujours
utilisées de nos jours pour permettre à Linux d'utiliser du matériel non
<acronym>PnP</acronym>. Et, quelque fois, ces vieilles méthodes sont toujours
utilisées de nos jours sur du matériel <acronym>PnP</acronym> (après que le
<acronym>BIOS</acronym> ait affecté des ressources aux matériels par
les méthodes <acronym>PnP</acronym>).</para>
<para>Le bus PCI ressemblait au <acronym>PnP</acronym> dès le début mais il n'a
pas été appelé <acronym>PnP</acronym> ou « plug and play », ce qui a eu comme
résultat que <acronym>PnP</acronym> signifie souvent <acronym>PnP</acronym> sur
le bus <acronym>ISA</acronym>. Dans la documentation, <acronym>PnP</acronym>
signifie habituellement <acronym>PnP</acronym> sur le bus <acronym>ISA</acronym>
comme sur le bus <acronym>PCI</acronym>.</para>
</sect2>
<sect2><title>Comment fonctionne le <acronym>PnP</acronym> (explication simplifiée)</title>
<para>
Voici comment <acronym>PnP</acronym> devrait fonctionner. L'hypothétique
programme de configuration <acronym>PnP</acronym> trouve tous les
périphériques <acronym>PnP</acronym> et demande à chacun les ressources
bus dont il a besoin. Ensuite, il vérifie quelles sont les ressources
bus qu'il peut affecter (<acronym>IRQ</acronym>, et cætera). Bien sûr,
s'il a réservé des ressources bus utilisées pour des périphériques non
<acronym>PnP</acronym> (s'il les connaît), il ne les donne pas. Il
utilise certains critères (ne faisant pas partie des spécifications
<acronym>PnP</acronym>) pour donner les ressources bus de façon à ce
qu'il n'y ait pas de conflit et de façon à ce que tous les périphériques
disposent de ce qu'ils ont demandé (si possible). Il indique ensuite
indirectement à chaque périphérique physique les ressources bus qui lui
ont été assignées et les périphériques se configurent eux-mêmes pour
n'utiliser que ces ressources-là. Enfin, les pilotes de périphériques
trouvent d'une manière ou d'une autre quelles ressources sont utilisées
par leur périphérique et sont donc capables de communiquer avec les
périphériques qu'ils contrôlent.
</para>
<para>Par exemple, prenons une carte ayant besoin d'une <acronym>IRQ</acronym>
(d'un numéro d'<acronym>IRQ</acronym>) et de 1 Mo de mémoire partagée. Le
programme <acronym>PnP</acronym> lit cette requête des registres de
configuration de la carte. Il lui affecte l'<acronym>IRQ</acronym> 5 et
1 Mo d'espace mémoire, commençant à partir de l'adresse 0xe9000000. Le
programme <acronym>PnP</acronym> lit aussi les informations d'identification de
la carte, indiquant ainsi le type de périphérique, son numéro
d'identifiant, et cætera. Ensuite,
il informe, directement ou indirectement, le pilote de périphérique convenable
pour ce matériel, de ce qu'il a fait. Si le pilote lui-même gère le
<acronym>PnP</acronym>, alors
il n'est pas nécessaire de trouver un pilote pour le périphérique (car le
pilote est déjà en cours d'exécution). Sinon, le bon pilote de périphérique doit
être trouvé et la configuration du périphérique doit lui être
communiquée.</para>
<para>Ce n'est pas toujours aussi simple car la carte (ou la table de routage
pour le PCI) pourrait indiquer qu'elle ne peut utiliser que certains numéros
d'<acronym>IRQ</acronym> ou que les 1 Mo de mémoire doivent résider dans
un certain espace d'adresses. Les détails sont différents pour les bus
<acronym>PCI</acronym> et <acronym>ISA</acronym>, cette dernière étant la plus
complexe.</para>
<para>Une façon habituellement utilisée pour allouer des ressources est
de commencer avec un périphérique et de lui allouer des ressources bus.
Puis de faire la même chose avec le périphérique suivant, et cætera. Ensuite,
si finalement tous les périphériques obtiennent les ressources allouées
sans conflit, alors tout va bien. Mais si allouer une ressource requise
créait un conflit, alors il serait nécessaire de revenir en arrière et
d'essayer de faire quelques changements dans les allocations précédentes
de façon à conserver la ressource bus nécessaire. Ceci s'appelle le
balancement. Linux ne le fait pas mais MS Windows en est capable dans
certains cas. Pour Linux, tout ceci est fait par le
<acronym>BIOS</acronym>, le noyau ou les pilotes de périphériques. Avec
Linux, le pilote du périphérique n'obtient pas son allocation finale de
ressources tant que le pilote n'est pas lancé, donc une façon d'éviter
les conflits est de ne pas lancer un périphérique qui pourrait causer un
conflit. Néanmoins, le <acronym>BIOS</acronym> alloue fréquemment des
ressources au périphérique physique avant que Linux ne soit complètement
démarré et le noyau vérifie les périphériques <acronym>PCI</acronym>
pour les conflits d'adresse au démarrage.</para>
<para>Des raccourcis existent et le logiciel <acronym>PnP</acronym> peut les
utiliser. Un d'eux est de garder la trace de la façon dont sont assignées les
ressources bus lors de la dernière configuration (lorsque l'ordinateur a été
utilisé pour la dernière fois) et de réutiliser cette information. Les
<acronym>BIOS</acronym> le font ainsi que MS Windows mais le Linux standard
ne le fait pas. Mais, d'une certaine façon, il le fait car il utilise souvent
ce que le <acronym>BIOS</acronym> a fait. Windows stocke cette information
dans sa base de registres sur le disque dur et un <acronym>BIOS</acronym>
PnP/<acronym>PCI</acronym> le stocke dans une mémoire non volatile de votre PC
(mémoire appelée
<acronym>ESCD</acronym> ; voir <xref linkend="escd_"/>). Certains disent
que ne pas avoir de registres (ce qui est le cas de Linux) est mieux car,
avec Windows, la base de registres peut être corrompue et elle est de toute
façon difficile à éditer. Mais <acronym>PnP</acronym> sur Linux a aussi des
problèmes.</para>
<para>Alors que MS Windows (sauf en ce qui concerne Windows 3.x et NT4) est un
système d'exploitation <acronym>PnP</acronym>, Linux n'était pas originellement
un système d'exploitation <acronym>PnP</acronym> mais l'est devenu
graduellement. Au début, <acronym>PnP</acronym> a fonctionné avec Linux parce
qu'un <acronym>BIOS</acronym> <acronym>PnP</acronym> configurait les ressources
bus et que les pilotes de périphériques récupéraient cette information en
utilisant des programmes apportés par le noyau Linux. Aujourd'hui, la plupart
des pilotes peuvent envoyer des commandes pour réaliser leur propre
configuration et n'ont pas besoin de se reposer toujours sur le
<acronym>BIOS</acronym>. Malheureusement, un pilote pourrait utiliser une
ressource bus dont un autre périphérique aurait besoin plus tard. D'autres pilotes
de périphériques enregistrent la dernière configuration dans un fichier de
configuration et l'utilisent la prochaine fois que l'ordinateur est
allumé.</para>
<para>Si le périphérique physique se rappelle de son ancienne configuration, alors
il n'y aura pas de matériel à configurer au prochain démarrage, mais il
semble oublier sa configuration lors de l'arrêt. Certains périphériques
disposent d'une configuration par défaut (mais pas nécessairement la dernière
utilisée). Donc, un périphérique <acronym>PnP</acronym> a besoin d'être
reconfiguré à chaque fois que le PC est allumé. De la même manière, si un
nouveau périphérique est ajouté, alors il a besoin d'être configuré. Allouer
des ressources bus pour ce nouveau périphérique peut nécessiter de récupérer
des ressources données auparavant à un autre et d'affecter à ce dernier de
nouvelles ressources. Actuellement, Linux ne peut pas gérer ce niveau de
sophistication (et MS Windows XP pourrait aussi ne pas en être capable).</para>
</sect2>
<sect2><title>Démarrer le PC</title>
<para>Quand le PC est lancé la première fois, le <acronym>BIOS</acronym> lance
son programme pour démarrer le PC (la première étape étant de vérifier le
matériel de la carte mère). Si le système d'exploitation est stocké sur disque
dur (ce qui est habituellement le cas), alors le <acronym>BIOS</acronym> doit
disposer de certaines informations sur le disque dur. Si ce disque est
<acronym>PnP</acronym>, le <acronym>BIOS</acronym> peut utiliser des méthodes
<acronym>PnP</acronym> pour le trouver. De même, pour permettre à l'utilisateur
de configurer manuellement le <acronym>CMOS</acronym> du <acronym>BIOS</acronym>
et de répondre
aux messages d'erreur lors du démarrage, un écran (et donc une carte vidéo) et
un clavier sont aussi requis. Donc, le <acronym>BIOS</acronym> doit toujours
configurer via <acronym>PnP</acronym> les périphériques nécessaires au
chargement du système d'exploitation à partir du disque dur.</para>
<para>Une fois que le <acronym>BIOS</acronym> a identifié le disque dur, la
carte vidéo et le clavier, il est prêt à commencer le démarrage (charger le
système d'exploitation en mémoire). Si vous avez indiqué au
<acronym>BIOS</acronym> que vous disposez d'un système d'exploitation
<acronym>PnP</acronym>, il devrait commencer le chargement comme indiqué
ci-dessus et laisser le système d'exploitation finir la configuration
<acronym>PnP</acronym>. Autrement, un
<acronym>BIOS</acronym>-<acronym>PnP</acronym> essaiera de configurer le reste
des périphériques (mais sans en informer leur pilote). peuvent toujours
trouver les informations nécessaires en utilisant les fonctions disponibles
dans le noyau Linux.</para>
</sect2>
<sect2><title>Les bus</title>
<para>Pour voir ce qui se trouve sur le bus <acronym>PCI</acronym>, exécutez
<command>lspci</command> ou <command>lspci -vv</command>. Ou vous pouvez aussi
saisir <command>scanpci -v</command> pour la même information dans le format
de code numérique où le périphérique est indiqué par numéro (par exemple :
<quote>device 0x122d</quote>) au lieu du nom, et cætera. Dans de rares cas,
<command>scanpci</command> trouvera un périphérique que <command>lspci</command>
n'arrive pas à trouver.</para>
<para>Les messages au démarrage sur votre écran affichent les périphériques
qui ont été trouvés sur les différents bus (utilisez shift-PageUp pour les voir).
Voir <link linkend="boot_time_msgs">Messages au démarrage</link>.</para>
<para><acronym>ISA</acronym> est l'ancien bus des PC compatibles IBM alors
que <acronym>PCI</acronym> est le nouveau bus, plus rapide, d'Intel. Le bus
<acronym>PCI</acronym> a été conçu pour ce qui est appelé de nos jours
<acronym>PnP</acronym>. Ceci rend facile (comparé à ce qu'il faut faire pour le
bus <acronym>ISA</acronym>) la découverte de l'affectation des ressources bus
<acronym>PnP</acronym> aux périphériques matériels.</para>
<para>Pour le bus <acronym>ISA</acronym>, il existait un problème réel
avec l'implémentation de <acronym>PnP</acronym> car personne n'avait en
tête <acronym>PnP</acronym> lorsque ce bus a été conçu et il existe
encore moins d'adresses d'entrées/sorties disponibles pour
<acronym>PnP</acronym> pour envoyer des informations de configuration à
un périphérique physique. Du coup, la façon dont <acronym>PnP</acronym>
a été réalisé pour le bus <acronym>ISA</acronym> est très complexe. Des
livres entiers ont été écrits à ce sujet. Voir notamment <link
linkend="pnp_book">ce livre</link>. Entre autres choses, il requiert
que soit assigné par le programme <acronym>PnP</acronym> à chaque
périphérique <acronym>PnP</acronym> un point d'ancrage temporaire pour
que tout le monde puisse faire la configuration <acronym>PnP</acronym>.
Assigner ces <quote>points d'ancrage</quote> est appelé
<quote>isolation</quote>. Voir <xref linkend="isolation_"/> pour des
détails complexes.</para>
<para>Au fur et à mesure de la disparition du bus <acronym>ISA</acronym>,
<acronym>PnP</acronym> sera un peu plus facile. Il ne sera pas seulement plus
simple de savoir comment le <acronym>BIOS</acronym> a configuré le matériel mais
il y aura aussi
moins de conflits, le <acronym>PCI</acronym> pouvant partager des interruptions.
Il y aura toujours besoin de faire correspondre un pilote de périphérique à un
matériel et il y aura toujours besoin de configurer les périphériques ajoutés
lors du lancement du PC. Le sérieux problème des quelques périphériques non
supportés par Linux restera présent.</para>
</sect2>
<sect2 id="how_linux_pnps"><title>Comment Linux gère-t-il le
<acronym>PnP</acronym></title>
<para>Linux a eu de sérieux problèmes dans le passé pour la gestion de
<acronym>PnP</acronym> mais la plupart de ces problèmes sont maintenant résolus
(vers mi-2004). Linux est parvenu d'un système non <acronym>PnP</acronym> à un
système qui peut être <acronym>PnP</acronym> si le noyau est compilé avec
certaines options. Le BIOS peut affecter des IRQ mais Linux peut aussi
affecter certains d'entre eux ou même les refaire ce que le BIOS a déjà
fait. La partie de configuration de <acronym>ACPI</acronym> (<foreignphrase>Advance
Configuration and Power Interface</foreignphrase>) est conçu pour faciliter
la propre configuration des systèmes d'exploitation. Linux peut utiliser
l'ACPI si le noyau a été compilé avec son support.</para>
<para>Dans Linux, il est traditionnel qu'un pilote de périphérique fasse
sa propre configuration de bas niveau. C'était difficile jusqu'au moment
où le noyau Linux a fourni le logiciel que les pilotes peuvent utiliser
pour se faciliter le travail. Aujourd'hui (2005), c'est arrivé à un point où
le pilote peut simplement appelé la fonction pci_enable_device() du noyau
et où le périphérique se voit configuré en étant activé et en récupérant
une <acronym>IRQ</acronym> (si nécessaire) et les adresses affectées au
périphérique. Cette affectation pourrait être ce qui avait été affecté
auparavant par le <acronym>BIOS</acronym> ou ce que le noyau avait
réservé quand le périphérique PCI ou ISAPNP a été détecté par le noyau.
Il existe même une option ACPI pour que le noyau affecte toutes les IRQ
des périphériques lors du démarrage.</para>
<para>Donc aujourd'hui, d'une certaine façon, les pilotes font toujours la
configuration mais ils peuvent la faire en demandant simplement au noyau de
s'en charger (et Linux pourrait ne pas avoir besoin de faire grand chose
car il est quelque fois capable d'utiliser ce qui a déjà été configuré par
le BIOS ou par lui-même). Donc, c'est vraiment la partie du noyau, hors du
pilote, qui fait la grande partie de configuration. Du coup, il pourrait
être correct d'appeler Linux un système d'exploitation PnP, au moins pour
les architectures communes.</para>
<para>Ensuite, lorsqu'un pilote découvre son périphérique, il demande à
connaître les adresses et IRQ affectés (par le <acronym>BIOS</acronym> ou
par Linux) et, habituellement, les accepte simplement. Mais, si le pilote le
souhaite, il peut essayer de modifier les adresses en utilisant les fonctions
fournies par le noyau. Cependant, le noyau n'acceptera pas d'adresses entrant
en conflit avec d'autres périphériques ou des adresses que le matériel ne peut
pas supporter. Quand le PC démarre, vous pouvez noter les messages à l'écran
montrant que certains pilotes de périphériques Linux ont trouvé leurs
périphériques matériels et quels sont leurs IRQ et adresses.</para>
<para>Donc, le noyau fournit des fonctions (programmes) que les pilotes
peuvent utiliser pour trouver si leur périphérique est présent, la façon
dont il est configuré et les fonctions qui permettent de modifier la
configuration si nécessaire. Le noyau 2.2 pouvait faire ceci pour
le bus <acronym>PCI</acronym> seulement mais le noyau 2.4 contient cette
fonctionnalité pour les bus ISA et PCI (à condition que les options PnP et
PCI appropriés ont été sélectionnées avant la compilation du noyau). Le
noyau 2.6 est arrivé avec une meilleure utilisation de l'ACPI. Ceci ne
garantie en rien que tous les pilotes utilisent complètement et correctement
ces fonctionnalités. Les périphériques propriétaires que le BIOS ne connait
pas pourraient ne pas être configurés tant qu'une configuration manuelle ne
soit effectuée.</para>
<para>De plus, le noyau tente d'éviter les conflits d'adresses en ne
permettant pas à deux périphériques d'utiliser les même ressources bus
en même temps. Au début, ce n'était valable que pour les IRQ et les DMA
mais, maintenant, cela s'adresse aussi aux adresses.</para>
<para>Si vous avez un ancien bus ISA, le programme isapnp doit être exécuté au
démarrage pour trouver et configurer les périphériques PnP sur le bus ISA.
Regardez les messages avec « dmesg ».</para>
<para>Pour voir quelle aide le noyau peut apporter aux pilotes de
périphériques, consultez le répertoire <filename
class="directory">/usr/…/…/Documentation</filename> où un des
<quote>…</quote> contient le mot <quote>kernel-doc</quote> ou quelque
chose
d'approchant. Attention : cette documentation a tendance à ne plus être à
jour pour avoir les dernières informations donc vous aurez besoin de lire les
messages des listes de diffusion des développeurs du noyau et peut-être aussi
de lire le code source et les commentaires qu'ils ont écrits. Dans le répertoire
de la documentation du noyau, voir pci.txt (<quote>How to Write Linux
<acronym>PCI</acronym>
Drivers</quote>, c'est-à-dire <quote>Comment écrire des pilotes
<acronym>PCI</acronym> pour
Linux</quote>) ainsi que le fichier
<filename>/usr/include/linux/pci.h</filename>. Si vous êtes un gourou des
pilotes et si vous connaissez la programmation en C, ces fichiers sont écrits
d'une telle façon qu'il ne vont pas vous permettre d'écrire un pilote. Mais cela
vous donnera une idée des fonctions type <acronym>PnP</acronym> disponibles pour
les pilotes.</para>
<para>Pour le noyau 2.4, voir <filename>isapnp.txt</filename>. Pour le noyau
2.6, <filename>isapnp.txt</filename> est remplacé par
<filename>pnp.txt</filename> qui est totalement différent et gère en plus le bus
PCI. Voir aussi le livre d'O'Reilly : Linux Device Drivers, 3è
édition, 2005. Le texte complet est disponible sur Internet.</para>
</sect2>
<sect2><title>Problèmes avec Linux <acronym>PnP</acronym></title>
<para>Il existe un certain nombre d'autres points qu'un
système d'exploitation <acronym>PnP</acronym> devrait mieux gérer :
<itemizedlist>
<listitem><para>Allouer des ressources bus quand il en existe peu par
une réallocation des ressources si nécessaire ;</para></listitem>
<listitem><para>Gérer le choix d'un pilote lorsqu'il en existe plus d'un
par périphérique ;</para></listitem>
</itemizedlist>
</para>
<para>Comme chaque pilote s'occupe de lui mais pas des autres, un pilote
pourrait récupérer les ressources bus nécessaires à d'autres périphériques (et
non encore alloués à ceux-ci par le noyau). Donc un noyau Linux
<acronym>PnP</acronym> plus
perfectionné serait bien mieux, un noyau qui pourrait s'occuper de l'allocation
une fois toutes les requêtes envoyées. Une alternative serait d'essayer
de réallouer les ressources déjà affectées quand un pilote n'obtient pas toutes
les ressources qu'il a demandées.</para>
<para>Le problème de la <quote>rareté des ressources bus</quote> devient de
moins en moins
réel pour deux raisons : la première est que le bus
<acronym>PCI</acronym>
est en train de remplacer le bus <acronym>ISA</acronym>. Le bus
<acronym>PCI</acronym> n'a pas ce type de problème pour les
<acronym>IRQ</acronym> car celles-ci peuvent être partagées (bien que ce
partage rende le système un peu moins efficace). De plus, le
<acronym>PCI</acronym>
n'utilise pas les ressources <acronym>DMA</acronym> (bien qu'il dispose d'un
équivalent sans avoir besoin des ressources).</para>
<para>La deuxième raison est que plus d'espace d'adresses est disponible pour
les entrées/sorties des périphériques. Alors que l'espace d'adresses
conventionnel du bus <acronym>ISA</acronym> était limité à 64 Ko, le bus
<acronym>PCI</acronym> dispose de 4 Go. Comme plus de périphériques
physiques utilisent les adresses en mémoire principale au lieu de l'espace
d'adresses des entrées/sorties, il existe toujours un peu de place disponible,
y compris sur le bus <acronym>ISA</acronym>. Sur les PC 32
bits, il y a un espace d'adressage de 4 Go en mémoire principale et la
plupart de ces ressources bus est disponible pour les entrées/sorties des
périphériques (à moins que vous ayez 4 Go de mémoire principale
installée).</para>
<para>Il y a eu au moins une tentative pour faire de Linux un vrai système
d'exploitation PnP. Voir <ulink url="http://www.astarte.free-online.co.uk"/>.
Bien que développé dès 1998, elle n'a jamais été intégrée au noyau (mais aurait
certainement dûe l'être).</para>
</sect2>
</sect1>
<sect1 id="conf_pnp_bios"><title>Configurer un <acronym>BIOS</acronym>
<acronym>PnP</acronym></title>
<para>Lorsque l'ordinateur est démarré, le <acronym>BIOS</acronym> est lancé
avant que le système d'exploitation ne soit chargé. Les <acronym>BIOS</acronym>
modernes sont <acronym>PnP</acronym> et peuvent configurer la plupart des
périphériques <acronym>PnP</acronym>. Quelques anciens <acronym>BIOS</acronym>
<acronym>PCI</acronym> vont seulement configurer le bus <acronym>PCI</acronym>.
Voici quelques choix qui pourraient exister dans le menu <acronym>CMOS</acronym>
de votre <acronym>BIOS</acronym> :
<itemizedlist>
<listitem><para><xref linkend="bios_pnp_os"/> ;</para></listitem>
<listitem><para><xref linkend="escd_resources"/> ;</para></listitem>
<listitem><para><xref linkend="escd_reset"/>.</para></listitem>
</itemizedlist>
</para>
<sect2 id="bios_pnp_os"><title>Avez-vous un système d'exploitation
<acronym>PnP</acronym> ?</title>
<para>Quelle que soit votre réponse au <acronym>BIOS</acronym>, le
<acronym>BIOS</acronym> <acronym>PnP</acronym> utilisera
<acronym>PnP</acronym> pour paramétrer le disque dur, le lecteur de
disquette, la carte vidéo et le clavier, afin de permettre au système de
démarrer. Si vous dites avoir un système d'exploitation
<acronym>PnP</acronym>, il laissera la fin de la configuration au
système d'exploitation (ou aux pilotes de périphériques). Si vous dites
ne pas avoir de système d'exploitation <acronym>PnP</acronym>, alors le
<acronym>BIOS</acronym> devra tout configurer.
</para>
<para>Comment répondre à cette question de votre <acronym>BIOS</acronym> ?
Si vous avez au moins un noyau 2.4, vous pourriez répondre ce que vous voulez et
Linux fonctionnera habituellement correctement. Même si vous avez Windows
2000 ou XP sur le même PC, cela devrait fonctionner de toute façon tout
simplement parce que Windows et Linux sont tous les deux à priori des
systèmes d'exploitation <acronym>PnP</acronym> et que si le système
d'exploitation est <acronym>PnP</acronym>, il devrait être capable de gérer le
cas où le <acronym>BIOS</acronym> a tout configuré lui-même (si vous avez
répondu que le système d'exploitation n'est pas <acronym>PnP</acronym>). Mais,
je continue à suggèrer de répondre qu'il n'est pas <acronym>PnP</acronym> sauf
si une raison valable vous oblige à faire autrement.</para>
<sect3 id="prior_2.4"><title>Linux avant le noyau 2.4</title>
<para>La réponse n'est pas souvent claire dans ce cas. Si isapnp était utilisé
par Linux, alors Linux fera la configuration et il était indiqué qu'il est
mieux de dire qu'il s'agit d'un système d'exploitation <acronym>PnP</acronym>.
La raison pour laquelle isapnp aurait des problèmes en présence de
périphériques déjà configurés par le <acronym>BIOS</acronym> n'est pas claire
mais de tels problèmes arrivent quelquefois et sont corrigés en stoppant la
configuration du <acronym>BIOS</acronym> (en répondant oui, c'est un système
d'exploitation <acronym>PnP</acronym>). Il existe quelques cas où dire non
résolvait un problème. Donc, si isapnp n'est pas utilisé, non est généralement
mieux. Les pilotes Linux de périphériques <acronym>PCI</acronym> devraient
configurer correctement ces périphériques. Mais pour le cas où les périphériques
<acronym>PCI</acronym> pilotés par des pilotes non <acronym>PCI</acronym>, alors
vous pourriez dire que le système d'exploitation n'est pas
<acronym>PnP</acronym> pour obtenir du <acronym>BIOS</acronym> qu'il les
configure directement.</para>
</sect3>
<sect3><title>Windows 2000 et XP</title>
<para>Si vous utilisez aussi des systèmes d'exploitation Windows sur le même PC,
vous pourriez dire que vous n'avez pas un système d'exploitation
<acronym>PnP</acronym>. C'est ce
que MS vous suggère de faire. Peut-être que MS souhaite que le
<acronym>BIOS</acronym> fasse un
meilleur travail pour la configuration que Windows ne le fera. Ceci est sensé
parce que le <acronym>BIOS</acronym> devrait être conçu pour les particularités
spécifiques de la
carte mère, et tout spécialement de nos jours où beaucoup de périphériques sont
intégrés à celle-ci. Dire non devrait aussi être bon pour les noyaux Linux
2.4 et ultérieurs. Mais pour les noyaux précédents, ce n'est pas si clair (voir
la section ci-dessous). Donc, si vous avez des problèmes avec Linux, vous
pourriez essayer de dire que vous avez un système d'exploitation Linux mais
ceci va contre ce que raconte MS (mais fonctionnera probablement bien de toute
façon).</para>
<para>Lorsque le <acronym>BIOS</acronym> configure un périphérique différemment
de ce qui est
stocké dans la base de registres de Windows, celui-ci vous dira qu'il a
découvert un nouveau matériel. Ce qu'il est réellement en train de faire est de
trouver l'ancien matériel qui a été configuré différemment. De toute façon, il
enregistre la configuration que le <acronym>BIOS</acronym> a utilisée dans ses
registres et le
périphérique devrait bien fonctionner à partir de ce moment.</para>
</sect3>
<sect3><title>MS Windows 95, 98 (et Me ?)</title>
<para>Pour Windows9x, MS suggère de dire au <acronym>BIOS</acronym> que vous
avez un système d'exploitation <acronym>PnP</acronym> (l'opposé complet du cas
pour Windows 2000 et XP). Ceci devrait être bon pour Linux si vous disposez
d'un noyau 2.4 ou ultérieur. Mais si vous avez un noyau Linux précédent le
2.4, alors il est mieux pour Linux de dire qu'il ne s'agit pas d'un système
d'exploitation <acronym>PnP</acronym>. Une façon de résoudre ce dilemme est de
le configurer pour le système d'exploitation que vous utilisez le plus
fréquemment. Ensuite, au démarrage de l'autre système d'exploitation, modifiez
manuellement la configuration du <acronym>BIOS</acronym>. C'est très ennuyant
mais c'est faisable si vous n'utilisez pratiquement jamais l'autre système
d'exploitation. Sinon, il existe de meilleurs façons de résoudre ce dilemme.
</para>
<para>La deuxième façon de résoudre ce dilemme est de faire en sorte que Linux
configure toutes les ressources. Voir <xref linkend="prior_2.4"/>. Ensuite,
vous dites au <acronym>BIOS</acronym> qu'il s'agit d'un système d'exploitation
<acronym>PnP</acronym>.</para>
<para>La troisième façon de résoudre ce dilemme est de dire au
<acronym>BIOS</acronym> qu'il ne
s'agit pas d'un système d'exploitation <acronym>PnP</acronym>. Ceci va à
l'encontre de ce que dit
MS mais il est possible d'obtenir un bon fonctionnement de MS Windows9x si vous
comprenez ce que vous faites (et pourquoi). Si vous dites au
<acronym>BIOS</acronym> qu'il ne
s'agit pas d'un système d'exploitation <acronym>PnP</acronym>, MS Windows ne
devrait-il pas
détecter la façon dont le <acronym>BIOS</acronym> a configuré les périphériques
et modifier cela
s'il n'aime pas ce que le <acronym>BIOS</acronym> a fait ? Cela devrait,
mais malheureusement,
cela ne semble pas fonctionner de cette façon.</para>
<para>Ce que Windows 9x semble faire lorsqu'il trouve un matériel déjà
configuré par le <acronym>BIOS</acronym> est de le laisser seul et de ne pas le
reconfigurer. Maintenant, Windows 9x garde une trace de la configuration des
ressources bus dans sa base de registres. Si la configuration du
<acronym>BIOS</acronym> est différent, il devrait soit corriger ce qui se
trouve dans sa base de registres soit tout reconfigurer suivant les indications
de cette même base. Mauvaise nouvelle : il semble ne rien faire et pense
que la configuration actuelle est la même que celle de la base de registres
alors qu'en fait elles sont différentes.</para>
<para>Mais si la base de registre contient une configuration des ressources bus
identique à celle du <acronym>BIOS</acronym>, alors tout fonctionnera bien. Un
périphérique
fonctionnera bien si le <acronym>BIOS</acronym> l'a configuré de la même façon
que ce qui est
enregistré dans la base de registres. Donc, le moyen de faire fonctionner
correctement MS Windows est d'obtenir que la base de registres soit synchronisée
avec la configuration du <acronym>BIOS</acronym>. Comme mentionné précédemment,
le <acronym>BIOS</acronym> configure
les éléments suivant son <acronym>ESCD</acronym> (qui est quelque chose comme la
base de registres
mais pour le <acronym>BIOS</acronym>). Voir <xref linkend="escd_"/>. Donc, nous
avons besoin
d'obtenir la synchronisation des registres avec l'<acronym>ESCD</acronym> du
<acronym>BIOS</acronym> pour que la base
de registres et <acronym>ESCD</acronym> contiennent la même configuration. Dans
certains cas, ces
deux arrivent à être synchrones et vous n'avez pas besoin de faire quoi que ce
soit.</para>
<para>Une question à laquelle vous pourriez penser est : comment
l'<acronym>ESCD</acronym> du
<acronym>BIOS</acronym> et la base de registres Windows peuvent-ils se
désynchroniser ? Voici
un scénario. Vous installez Windows avec le <acronym>BIOS</acronym> configuré
pour un système
d'exploitation <acronym>PnP</acronym>. Alors, Windows configure la plupart des
éléments et
sauvegarde sa configuration dans sa base de registres. Puis, plus tard, vous
changez la configuration du <acronym>BIOS</acronym> en précisant qu'il ne s'agit
pas d'un système
d'exploitation <acronym>PnP</acronym>. Ensuite, après un redémarrage, le
<acronym>BIOS</acronym> configure tout et il
ne fait pas exactement ce que Windows a fait. Donc, la configuration actuelle
du matériel et ce que Windows dispose dans sa base de registres sont maintenant
différents.</para>
<para>Une façon d'essayer d'obtenir que la base de registres et l'ESCD
disposent des mêmes informations est d'installer (ou de réinstaller) Windows
lorsque le <acronym>BIOS</acronym> est configuré pour un système d'exploitation
non
<acronym>PnP</acronym>. De cette façon, Windows disposera du matériel configuré
par le <acronym>BIOS</acronym>. Si cette configuration est faite sans conflit,
Windows n'en changera pas et la sauvegardera dans sa base de registres. Et dans
ce cas, l'<acronym>ESCD</acronym> et la base de registres seront
synchronisés.</para>
<para>
Une autre méthode est de supprimer les périphériques causant problèmes à
Windows en cliquant <quote>Supprimer</quote> dans le gestionnaire des
périphériques. Puis redémarrez avec <quote>OS non
<acronym>PnP</acronym></quote> (enregistré dans la mémoire
<acronym>CMOS</acronym> du <acronym>BIOS</acronym> lorsque vous
redémarrez). Windows va alors réinstaller les périphériques, en
utilisant, on l'espère, les ressources bus configurées par le
<acronym>BIOS</acronym>. Faites attention que Windows vous demandera
d'insérer le CD d'installation de Windows car il peut ne pas trouver les
fichiers du pilote de périphériques, même s'il sont bien là. Un
contournement est de sélectionner <quote>skip file</quote> ce qui
évitera l'installation du fichier à partir du CD. Si le fichier est
toujours sur le disque dur, avec un peu de chance, le pilote et tout ira
bien, même si le programme d'installation de Windows vous a demandé de
l'installer à partir du CD (ce que vous avez passé).
</para>
<para>Comme test, j'ai <quote>supprimé</quote> une carte réseau qui utilisait un
pilote
compatible Novell. Au redémarrage, Windows l'a réinstallé avec le Réseaux
Microsoft plutôt qu'avec Novell. Ceci signifie que le client Novell a dû être
réinstallé, un gros travail inutile. Donc, il serait mieux de ne pas continuer
avec Windows 95/98 mais laisser Linux configurer les ressources bus.</para>
<para>Lors de l'utilisation d'un PC Window-Linux (<foreignphrase>dual
boot</foreignphrase>), vous pouvez noter un changement dans la façon dont le
<acronym>BIOS</acronym> configure à cause de Windows9x (et des autres versions de
Windows ??) en modifiant l'<acronym>ESCD</acronym>. Il fait cela seulement
si vous <quote>forcez</quote> une configuration ou une installation d'un périphérique
propriétaire. Voir <xref linkend="W9x_ESCD"/>. Les pilotes de périphériques
réalisant la configuration pourraient modifier ce que le <acronym>BIOS</acronym>
a fait comme le font les outils <acronym>PCI</acronym> et isapnp.</para>
</sect3>
</sect2>
<sect2 id="escd_resources"><title>Affecter les ressources par le
<acronym>BIOS</acronym> ?</title>
<para>Les <acronym>BIOS</acronym> modernes vous permettent d'allouer
manuellement des ressources, principalement des <acronym>IRQ</acronym>. Il
existe normalement une option pour configurer l'allocation à <quote>auto</quote>
de façon à ce que le <acronym>BIOS</acronym> décide de l'allocation des
ressources. <quote>Auto</quote> est souvent un bon choix sauf si vous avez
d'anciennes cartes <acronym>ISA</acronym> propriétaires non
<acronym>PnP</acronym>.</para>
<para>Si vous avez de telles cartes non <acronym>PnP</acronym>, alors il
peut être important de réserver les ressources (telles que les
<acronym>IRQ</acronym>) pour celles-ci dans le <acronym>BIOS</acronym>.
Sinon, le <acronym>BIOS</acronym> pourrait utiliser ces ressources pour
d'autres périphériques et créer ainsi des conflits. Une exception concerne
quelques périphériques propriétaires communs, comme les ports parallèle et
séries, les disques durs. Le <acronym>BIOS</acronym> pourrait les trouver
(jetez un œil à l'écran au démarrage) pour que vous n'ayez pas besoin
de réserver les ressources pour eux. Si vous avez utilisé Windows sur votre
PC, Windows pourrait déjà avoir renseigné le <acronym>BIOS</acronym> en
utilisant l'outil ICU (ou un outil identique) sous Windows.</para>
<para>Pour le <acronym>PCI</acronym>, le <acronym>BIOS</acronym> devrait aussi
vous permettre d'affecter les <acronym>IRQ</acronym> aux
emplacements de cartes 1, 2, 3, 4, et cætera. Si vous le faites, vous devez connaître
les emplacements où se trouvent les cartes. En fait, chaque emplacement dispose
de quatre <acronym>IRQ</acronym> <acronym>PCI</acronym> : A, B, C et D. Si
le menu du <acronym>BIOS</acronym> ne vous dit pas
laquelle (A, B, C, D) est affectée à un numéro d'IRQ, il est probable qu'il
affecte seulement le numéro d'<acronym>IRQ</acronym> à l'<acronym>IRQ</acronym>
<acronym>PCI</acronym> A. Mais, beaucoup de cartes
utilisent seulement l'<acronym>IRQ</acronym> A donc il s'agit surtout d'affecter
une <acronym>IRQ</acronym> à un emplacement. Voir les <link
linkend="pci_int">interruptions PCI</link>.</para>
</sect2>
<sect2 id="escd_reset"><title>Réinitialiser la configuration</title>
<para>C'est aussi un peu risqué. Ceci va écraser les données du
<acronym>BIOS</acronym> contenues dans l'<acronym>ESCD</acronym> indiquant la
façon dont vos périphériques <acronym>PnP</acronym> ont été configurés et
comment les périphériques non <acronym>PnP</acronym> ont été configurés
manuellement. Ne faites jamais ceci à moins que vous ne soyez convaincu que la
base de données est mauvaise et a besoin d'être reconstruite. Il était indiqué
quelque part que vous deviez faire ceci seulement lorsque vous n'arrivez plus
à démarrer. Si le <acronym>BIOS</acronym> perd les données sur les périphériques
<acronym>ISA</acronym> non <acronym>PnP</acronym>, alors vous devrez relancer
ICA une nouvelle fois sous DOS/Windows pour ré-enregistrer les données.</para>
</sect2>
</sect1>
<sect1><title>Gérer les cartes <acronym>PnP</acronym></title>
<sect2><title>Introduction à la gestion des périphériques
<acronym>PnP</acronym></title>
<para>De nos jours, pratiquement toutes les nouvelles cartes internes sont
Plug-and-Play. Du coup, la configuration des ressources bus devraient être dans
la plupart des cas entièrement automatique. Si un périphérique ne fonctionne pas,
vérifiez s'il a été détecté, par exemple en redémarrant. Si le pilote de
périphérique ne peut pas configurer les ressources, alors probablement une ou
plus des méthodes du 2.6 le feront :
<itemizedlist>
<listitem><para><xref linkend="dev_d_conf"/> ;</para></listitem>
<listitem><para><xref linkend="sys_"/> le noyau 2.6+ (pas encore pour le
<acronym>PCI</acronym>
et quelques autres sévères limitations) ;</para></listitem>
<listitem><para><xref linkend="bios_conf"/> (pour le bus
<acronym>PCI</acronym>, vous avez seulement besoin d'un
<acronym>BIOS</acronym> <acronym>PCI</acronym>, sinon vous avez besoin
d'un <acronym>BIOS</acronym>
<acronym>PnP</acronym>) ;</para></listitem>
<listitem><para><xref linkend="disable_pnp"/> par des cavaliers ou avec un
logiciel DOS/Windows (mais la plupart des cartes ne le font pas) ;
</para></listitem>
<listitem><para><xref linkend="isapnp_"/> est un programme que vous pouvez
toujours utiliser pour configurer les périphériques <acronym>PnP</acronym>
du bus <acronym>ISA</acronym> (seulement),</para></listitem>
<listitem><para><xref linkend="pciutils_"/> permet de configurer le bus
<acronym>PCI</acronym> mais le pilote de périphérique devrait le
gérer ;
</para></listitem>
<listitem><para><xref linkend="windows_conf"/> et alors vous démarrez Linux à
partir de Windows/DOS. A utiliser en dernier recours.</para></listitem>
</itemizedlist>
</para>
<para>N'importe lequel configurera les ressources bus au niveau matériel mais
seul le premier (voire le second) indiquera au pilote ce qui a été fait. La façon
dont le pilote est informé dépend du pilote. Vous pouvez avoir besoin de faire
quelque chose pour l'informer. Voir <xref linkend="tell_driver_config"/>.</para>
</sect2>
<sect2 id="dev_d_conf"><title>Configuration du pilote de périphérique,
réservation des ressources</title>
<para>Les pilotes de périphériques (avec l'aide de fonctions du
noyau) peuvent être écrits pour utiliser des méthodes <acronym>PnP</acronym>
pour configurer les ressources bus du matériel mais seulement pour le
périphérique qu'ils contrôlent. Mais beaucoup de pilotes de périphériques
acceptent directement ce que le BIOS ou Linux a configuré et utilise le code
fourni par le noyau pour découvrir comme ce périphérique a été configuré.
Comme le pilote a vérifié la configuration et la certainement reconfiguré,
il connaît de façon évidente la configuration et il n'y a aucun besoin de lui
donner cette information. C'est dont la façon la plus simple de le faire car
vous n'avez rien à faire si le pilote fait tout.</para>
<para>Si vous avez un matériel datant d'avant l'<acronym>ISA</acronym>
<acronym>PnP</acronym>, le logiciel <acronym>PnP</acronym> Linux
pourrait ne pas le savoir et pourrait ne pas connaître les ressources
bus qu'il réclame. Donc, il pourrait allouer de façon erronée des
ressources dont cet ancien matériel a besoin à un autre périphérique. Le
résultat est un conflit de ressources mais il existe un moyen de
l'éviter. Vous pouvez réserver les ressources dont cette ancienne carte
<acronym>ISA</acronym> a besoin en configurant le <acronym>BIOS</acronym>
au démarrage (habituellement), au module isa-pnp ou au noyau (si le support de
<acronym>PnP</acronym> est intégré dans le noyau). Par exemple, pour
réserver l'<acronym>IRQ</acronym> 5, donnez cet argument au module
isa-pnp (ou au noyau) : isapnp_reserve_irq=5. Voir le <ulink
url="&howto;BootPrompt-HOWTO.html">Guide
pratique sur l'invite de démarrage
(<foreignphrase>BootPrompt-HOWTO</foreignphrase>)</ulink>. Au lieu de
..._irq, il existe aussi _io, _dma et _mem.</para>
<para>Pour les périphériques <acronym>PCI</acronym>, la plupart des pilotes
configureront <acronym>PnP</acronym>. Malheureusement, un pilote peut récupérer
des ressources bus nécessaires à d'autres périphériques (mais non alloués à eux
par le noyau). Donc, un noyau Linux <acronym>PnP</acronym> plus
perfectionné serait meilleur là où le noyau fait l'allocation pour toutes les
demandes envoyées. Voir <xref linkend="how_linux_pnps"/>.</para>
</sect2>
<sect2 id="sys_"><title>/sys : interface de configuration pour
l'utilisateur</title>
<para>Depuis le noyau 2.6, il existe une nouvelle façon pour que l'utilisateur
configure les ressources grâce au répertoire /sys. Mais, jusqu'à août 2004, il
ne peut pas être utilisé pour une configuration dans la plupart des cas. Voir
<xref linkend="sys_dir"/>.</para>
</sect2>
<sect2 id="bios_conf"><title>Configuration du <acronym>BIOS</acronym></title>
<sect3><title>Introduction à l'utilisation de la configuration
<acronym>PnP</acronym> faite par le <acronym>BIOS</acronym></title>
<para>Si vous avez un <acronym>BIOS</acronym> <acronym>PnP</acronym>, il peut
configurer le matériel. Si le pilote ne peut pas le faire, le
<acronym>BIOS</acronym> le peut probablement. Ceci veut dire que votre
<acronym>BIOS</acronym> lit les besoins en ressources de tous les périphériques
et les configure (en leur allouant les ressources bus). C'est un substitut pour
l'OS <acronym>PnP</acronym> sauf que le <acronym>BIOS</acronym> ne peut faire
correspondre les pilotes avec leur périphériques et ne peut pas non plus
indiquer aux pilotes la façon dont il a configuré les périphériques. Il devrait
normalement utiliser la configuration enregistrée dans sa mémoire non volatile
(ESCD). S'il trouve un nouveau périphérique ou s'il existe un conflit, le
<acronym>BIOS</acronym> devra effectuer les changements nécessaires et pourrait
ne pas utiliser la même configuration que celle de l'ESCD. Dans ce cas, il
devra mettre à jour l'<acronym>ESCD</acronym> pour refléter la situation.</para>
<para>Votre <acronym>BIOS</acronym> doit gérer une telle
configuration, mais il existe des cas où il ne le fait pas correctement ou pas
complètement. Le <acronym>BIOS</acronym> a aussi besoin de savoir via le menu
CMOS si le système d'exploitation est <acronym>PnP</acronym>. Alors que la
plupart des pilotes de périphériques seront capables de détecter automatiquement
ce que le <acronym>BIOS</acronym> a fait, dans certains cas, vous aurez besoin
de le déterminer (ce qui n'est pas toujours facile). Voir <xref
linkend="current_config"/>. Un avantage possible à laisser le
<acronym>BIOS</acronym> faire cette configuration est qu'il fait son boulot
avant de lancer Linux, donc c'est fait très tôt dans le processus de démarrage.
</para>
<para>La plupart des <acronym>BIOS</acronym> créés après 1996 ?? peuvent
configurer les
ressources des bus <acronym>PCI</acronym> et <acronym>ISA</acronym>. Mais, il a
été dit que certains anciens <acronym>BIOS</acronym>
peuvent uniquement s'occuper du <acronym>PCI</acronym>. Pour essayer d'en savoir
plus sur votre
<acronym>BIOS</acronym>, cherchez sur le web. Merci de ne pas me demander car je
n'ai pas toutes les données là-dessus. Les détails du <acronym>BIOS</acronym>
que vous souhaitez connaître peuvent être difficiles à trouver. Certains
<acronym>BIOS</acronym> pourraient avoir des capacités <acronym>PnP</acronym>
minimales et attendre que le système d'exploitation fasse la configuration
<acronym>PnP</acronym>. Si cela arrive, vous devrez soit trouver une autre
méthode soit essayer d'enregistrer les informations dans la base de données
<acronym>ESCD</acronym>
si le <acronym>BIOS</acronym> en a une. Voir la prochaine section.</para>
</sect3>
<sect3 id="escd_"><title>La base de données <acronym>ESCD</acronym> du
<acronym>BIOS</acronym></title>
<para>Le <acronym>BIOS</acronym> maintient une base de données non volatile
contenant la configuration <acronym>PnP</acronym> qu'il essaiera d'utiliser (si
vous aviez indiqué qu'il ne s'agit pas d'un système d'exploitation
<acronym>PnP</acronym>). Elle s'appelle l'<acronym>ESCD</acronym> (acronyme pour
Extended System
Configuration Data, soit Données pour une Configuration Étendue du Système).
Encore une fois, l'<acronym>ESCD</acronym> est optionnel mais la plupart des
<acronym>BIOS</acronym> <acronym>PnP</acronym> en disposent.
L'<acronym>ESCD</acronym> enregistre
non seulement la configuration des ressources pour les périphériques
<acronym>PnP</acronym> mais aussi celle des périphériques non
<acronym>PnP</acronym> (et les indique en tant que tels) pour éviter les
conflits. Les données de l'<acronym>ESCD</acronym> sont habituellement
enregistrées sur un
composant et restent intactes lorsque la machine est arrêtée, mais c'est parfois
stocké sur un disque dur ??</para>
<para>L'<acronym>ESCD</acronym> a pour but de conserver la dernière
configuration utilisée. Mais
comme Linux peut modifier la configuration des périphériques (en incluant
l'utilisateur avec les outils <acronym>PCI</acronym> ou isapnp),
l'<acronym>ESCD</acronym> ne sera pas au courant
de cette modification et ne sauvegardera pas cette configuration. Un bon système
d'exploitation <acronym>PnP</acronym> devrait mettre à jour l'ESCD, pour que les
informations qui y sont stockées puissent être utilisées par un système
d'exploitation non <acronym>PnP</acronym> (comme un Linux standard). MS Windows
9x ne le fait que dans certains précis. Voir <xref linkend="W9x_ESCD"/>. À
partir du noyau 2.6, Linux est capable de modifier l'<acronym>ESCD</acronym>
mais cela n'est pas encore utilisé (août 2004).</para>
<para>Pour utiliser ce qui a été enregistré dans l'ESCD, assurez-vous d'avoir
bien spécifié que l'OS n'est pas <acronym>PnP</acronym> dans le
<acronym>CMOS</acronym> du
<acronym>BIOS</acronym>. Par la suite, à chaque fois que le
<acronym>BIOS</acronym> démarre (avant que l'OS Linux ne soit chargé), il devrait
tout configurer de cette façon. Si le <acronym>BIOS</acronym> détecte une
nouvelle carte <acronym>PnP</acronym> non indiquée dans l'ESCD, alors il
allouera des ressources bus à la carte et mettra à jour l'ESCD. Il pourrait
même changer les ressources bus assignées aux cartes <acronym>PnP</acronym>
existantes et modifier l'<acronym>ESCD</acronym> de manière concordante.</para>
<para>Un programme vous permet de visualiser le contenu de l'ESCD. Il affiche
les <acronym>IRQ</acronym>, les adresses d'entrées/sorties, et cætera mais les noms de
périphériques
manquent (seulement les numéros d'identifiant des périphériques EISA). Il est
disponible sur l'<ulink
url="http://home.t-online.de/home/gunther.mayer/lsescd/">index de
/home/gunther.mayer/lsescd</ulink>.</para>
<para>Si chaque périphérique sauvegardait sa dernière configuration au niveau
du matériel, la configuration matérielle ne serait pas nécessaire à chaque
démarrage du PC. Mais cela ne fonctionne pas ainsi. Donc, toutes les données de
l'<acronym>ESCD</acronym> ont besoin d'être actualisées si vous utilisez le
<acronym>BIOS</acronym>
pour <acronym>PnP</acronym>. Il existe des <acronym>BIOS</acronym> ne disposant
pas d'<acronym>ESCD</acronym> mais ayant une mémoire non volatile pour stocker
des informations
concernant l'attribution des ressources bus aux cartes non
<acronym>PnP</acronym>. Beaucoup de <acronym>BIOS</acronym> disposent des deux.
</para>
</sect3>
<sect3 id="W9x_ESCD"><title>Utiliser Windows pour configurer l'ESCD</title>
<para>Éventuellement, Linux pourrait initialiser l'ESCD. Depuis Linux 2.6, une
fonction du nouveau code pourrait le faire si le noyau a été compilé avec
PNPBIOS. Mais elle reste pour l'instant inutilisée.</para>
<para>Si le <acronym>BIOS</acronym> ne configure pas l'<acronym>ESCD</acronym>
de la façon
souhaitée (ou de la bonne façon), alors il serait bien de disposer d'un
utilitaire Linux pour le faire. Donc, vous pourriez vouloir
utiliser Windows (si vous l'avez sur le même PC) pour faire cela.</para>
<para>Il existe trois façons d'utiliser Windows pour tenter de modifier
l'ESCD. La première est d'utiliser l'utilitaire ICU pour DOS ou Windows 3.x. Il
devrait aussi fonctionner pour Windows 9x/2k ?? Une autre façon est
de
configurer les périphériques manuellement (<quote>en forçant</quote>) sous
Windows 9x/2k de
façon à ce que Windows enregistre les informations dans
l'<acronym>ESCD</acronym> lorsque Windows
est arrêté normalement. La troisième façon est possible uniquement pour les
périphériques non <acronym>PnP</acronym>. Si Windows connaît quelque chose sur
eux, notamment quelles ressources bus ils utilisent, alors Windows enregistrera
cette information dans l'ESCD.</para>
<para>Si les périphériques <acronym>PnP</acronym> sont configurés
automatiquement par Windows sans que l'utilisateur ait besoin de forcer cette
reconnaissance, alors ces paramétrages ne se trouveront probablement pas dans
l'ESCD. Bien sûr, Windows pourrait bien décider de lui-même de configurer ce qui
est enregistré dans l'ESCD, ce qui pourrait aboutir au même par coïncidence.
</para>
<para>Windows 9x est un système d'exploitation <acronym>PnP</acronym> et
configure automatiquement via <acronym>PnP</acronym> les périphériques. Il
maintient leur propre base de données <acronym>PnP</acronym> dans la base de
registre (fichiers binaires de Windows). Beaucoup d'autres données de
configuration résident dans la base de registre en plus des ressources bus
<acronym>PnP</acronym>. Il y a à la fois une configuration des ressources
<acronym>PnP</acronym> actuelles et une autre (peut-être la même) enregistrée sur
le disque dur. Pour voir ça avec Windows 98, ou pour forcer l'enregistrement
des modifications, utilisez le gestionnaire des périphériques.</para>
<para>Dans Windows 98, il existe deux façons d'arriver au gestionnaire des
périphériques :
<itemizedlist>
<listitem><para>1. Poste de travail --> Panneau de configuration -->
Système --> Gestionnaire de périphériques</para></listitem>
<listitem><para>2. (clic droit) Poste de travail --> Propriétés -->
Gestionnaire de périphériques.</para></listitem>
</itemizedlist>
Ensuite, dans ce gestionnaire, vous sélectionnez un périphérique (parfois un
processus en plusieurs étapes s'il existe plusieurs périphériques de la même
classe). Ensuite, cliquez sur <quote>Propriétés</quote> puis
<quote>Ressources</quote>. Pour essayer de modifier la configuration des
ressources manuellement, décochez <quote>Utilisez la configuration
automatique</quote> puis cliquez sur <quote>Changer la configuration</quote>.
Maintenant, essayez de modifier les paramétrages. Il peut ne pas vous
laisser les modifier. S'il vous le permet, vous avez <quote>forcé</quote> un
changement. Du coup, un message devrait vous avertir que vous avez forcé cette
modification. Si vous souhaitez garder le paramétrage existant affiché par
Windows, mais que vous voulez forcer, alors vous devrez forcer un autre
changement et de nouveau forcer sa modification en sa valeur précédente.</para>
<para>Pour voir ce qui a été forcé sous Windows 98, regardez la liste des
matériels <quote>forcés</quote> : Démarrer --> Programme --> Accessoires
--> Outils
système --> Information système --> Ressources matérielles --> Matériel
forcé. Lorsque vous <quote>forcez</quote> un changement des ressources bus dans
Windows,
il devrait enregistrer votre modification dans l'<acronym>ESCD</acronym> (à
condition que
vous ayez quitté Windows normalement). À partir de la fenêtre
<quote>Informations
système</quote>, vous pouvez aussi voir comment les <acronym>IRQ</acronym> et
les
ports d'entrées/sorties ont été alloués par Windows.</para>
<para>Même si Windows ne montre aucun conflit des ressources bus, il peut
exister un conflit sous Linux. Ceci est dû au fait que Windows peut affecter
des ressources bus différentes de celles de l'ESCD. Dans le cas rare où les
périphériques sous Windows sont soit non <acronym>PnP</acronym> soit
<quote>forcés</quote>, alors la configuration Windows et celle de l'ESCD
devraient être
les mêmes.
</para>
</sect3>
<sect3><title>Ajouter un nouveau périphérique (sous Linux ou Windows)</title>
<para>Si vous ajoutez un nouveau périphérique <acronym>PnP</acronym> et avez
configuré le <acronym>BIOS</acronym> à <quote>pas un système d'exploitation
<acronym>PnP</acronym></quote>,
alors le <acronym>BIOS</acronym> devrait automatiquement le configurer et
enregistrer la configuration dans l'ESCD. S'il ne s'agit pas d'un périphérique
non <acronym>PnP</acronym> (ou un utilisant les cavaliers), alors il existe
quelques options pour le gérer.</para>
<para>Vous pouvez indiquer directement au <acronym>BIOS</acronym> (via le menu
de configuration <acronym>CMOS</acronym>) que certaines ressources bus qu'il
utilise sont réservées et ne peuvent pas être allouées avec
<acronym>PnP</acronym>. Ceci ne met pas cette information dans l'ESCD. Il existe
un menu de sélection du <acronym>BIOS</acronym> permettant d'indiquer si les
choix <acronym>CMOS</acronym> supplantent ceux de l'<acronym>ESCD</acronym> en
cas de conflit. Une autre méthode revient à lancer ICU sous DOS/Windows. Encore
une autre permet de l'installer manuellement sous Windows 9x/2k puis de
s'assurer que cette configuration est <quote>forcée</quote> (voir la section
précédente). Si elle l'est, Windows devrait mettre à jour
l'<acronym>ESCD</acronym> à l'arrêt du PC.</para>
</sect3>
</sect2>
<sect2 id="disable_pnp"><title><acronym>ISA</acronym> seulement :
Désactiver <acronym>PnP</acronym> ?</title>
<para>Les périphériques <acronym>PCI</acronym> sont <acronym>PnP</acronym> à la
base donc cela ne peut pas être désactivé. Mais quelques périphériques
<acronym>ISA</acronym> ont des options pour désactiver <acronym>PnP</acronym>
par l'intermédiaire de cavaliers ou en lançant un programme Windows fourni
avec le périphérique (configuration logicielle). Si le pilote du périphérique
ne peut pas le configurer, ceci évitera la tâche probablement compliquée de la
configuration <acronym>PnP</acronym>. N'oubliez pas de dire au
<acronym>BIOS</acronym> que ces ressources bus sont réservées. Mais comme le
support de Linux pour le <acronym>PnP</acronym> a été amélioré, vous ne voulez
généralement pas
désactiver <acronym>PnP</acronym>. Voici quelques arguments pour lesquels vous
ne voudrez pas
désactiver <acronym>PnP</acronym> :
<itemizedlist>
<listitem><para>Si vous avez Windows sur la même machine, alors vous pouvez
permettre à <acronym>PnP</acronym> de configurer les périphériques
différemment entre Windows et Linux.</para></listitem>
<listitem><para>L'ensemble des choix pour les numéros d'<acronym>IRQ</acronym>
(ou ports d'adresse) peut être assez limité sauf si vous utilisez
<acronym>PnP</acronym>.</para></listitem>
<listitem><para>Vous pourriez avoir un pilote de périphérique Linux utilisant
des méthodes <acronym>PnP</acronym> pour rechercher le périphérique qu'il
contrôle.</para></listitem>
<listitem><para>Si vous avez besoin de modifier la configuration plus tard,
il serait plus facile de faire ceci avec <acronym>PnP</acronym> (sans
utiliser de cavaliers ou d'avoir à lancer un programme Dos/Windows).
</para></listitem>
</itemizedlist>
</para>
<para>Une fois vos périphériques configurés sans <acronym>PnP</acronym>,
ils ne peuvent plus être configurés par un logiciel
<acronym>PnP</acronym> ou par un <acronym>BIOS</acronym>
<acronym>PnP</acronym> (jusqu'à ce que vous changiez les cavaliers ou
utilisiez le logiciel de configuration Dos/Windows).</para>
</sect2>
<sect2 id="isapnp_"><title>Bus <acronym>ISA</acronym> : Isapnp (outil
faisant partie d'isapnptools)</title>
<para>Le programme <command>isapnp</command> est utilisé uniquement pour les
périphériques <acronym>PnP</acronym> du bus <acronym>ISA</acronym> (donc non
<acronym>PCI</acronym>). Il était vraiment nécessaire avant les noyaux 2.4.
Avec le noyau 2.4, qui a apporté des fonctionnalités permettant aux pilotes de
gérer le <acronym>PnP</acronym> sur le bus <acronym>ISA</acronym>, le programme
<command>isapnp</command> devient moins important. De plus, le
<acronym>BIOS</acronym> pourrait
configurer <acronym>ISA</acronym> <acronym>PnP</acronym> de manière
satisfaisante. Mais, le module isa-pnp (ou
l'équivalent intégré au noyau) est déjà très satisfaisant car de nombreux
pilotes de périphériques <acronym>ISA</acronym> l'appellent pour configurer les
ressources du bus.
Avant le noyau 2.6, cela résultait en un <quote>fichier</quote>
<filename>/proc/isapnp</filename> pouvant être utilisé pour configurer
manuellement (voir isapnp.txt dans la documentation du noyau).</para>
<para>Dans certains cas, les distributions Linux ont été configurées pour
lancer <command>isapnp</command> automatiquement au démarrage. Il est
toujours utilisé en 2004 mais il n'est pas réellement nécessaire si les
pilotes de périphériques fonctionnent bien. Si vous avez besoin de le
configurer vous-même, la grande partie de la documentation d'isapnp est
difficile à comprendre sauf si vous possédez des notions de base de
<acronym>PnP</acronym>. Ce guide pratique devrait vous aider à le
comprendre, ainsi que la FAQ qui accompagne <command>isapnp</command>.
Lancer le programme <command>isapnp</command> au démarrage vous
permettra de configurer ces périphériques suivant les valeurs spécifiées
dans <filename>/etc/isapnp.conf</filename>. Il est possible de créer ce
fichier de configuration automatiquement mais vous devrez alors l'éditer
manuellement pour choisir entre les différentes options. Puis pour que
le pilote connaisse ces ressources, vous avez souvent besoin de les
spécifier en tant que paramètres pour les modules appropriés (pilotes).
Ceci se fait avec des fichiers de configuration, généralement dans le
répertoire <filename class="directory">/etc</filename>. Cherchez-y des
fichiers nommés <filename>mod*</filename>, et cætera. Si le pilote est intégré
au noyau, alors ils pourraient parfois être donnés comme paramètre du
noyau. Voir le <ulink url="&howto;/BootPrompt-HOWTO.html">guide pratique
des options de démarrage</ulink>.</para>
<para>Avec <command>isapnp</command>, il existait un risque qu'un pilote de
périphérique, intégré au noyau, soit lancé trop tôt, avant
qu'<command>isapnp</command> n'ait pu configurer les adresses, et cætera
au niveau matériel. En conséquence, le pilote de
périphérique ne serait plus capable de trouver le périphérique. Le pilote
essaie la bonne adresse mais cette adresse n'est pas configurée au
niveau matériel. Cela est-il toujours un problème ??</para>
<para>Si votre distribution Linux a automatiquement installé
<command>isapnptools</command>, <command>isapnp</command> est
probablement lancé au démarrage. Dans ce cas, il ne vous reste qu'à éditer
<filename>/etc/isapnp.conf</filename> suivant <userinput>man
isapnp.conf</userinput>. Notez que cela revient à configurer manuellement
<acronym>PnP</acronym> car vous prendrez les décisions sur la façon de configurer
lors de l'édition du fichier de configuration.</para>
<para>Si le fichier de configuration est mauvais ou n'existe pas, vous pouvez
utiliser le programme <command>pnpdump</command> pour vous aider à créer le
fichier de configuration. Il crée pour vous un fichier de configuration mais
vous devrez l'éditer avec intelligence avant de l'utiliser. Il contient
quelques commentaires pour vous aider. Alors que le <acronym>BIOS</acronym>
pourrait aussi avoir configuré les périphériques <acronym>ISA</acronym> (si
vous lui avez dit que vous ne disposez pas de système d'exploitation
<acronym>PnP</acronym>), <command>isapnp</command> le refera.</para>
<para>La terminologie utilisée dans le fichier
<filename>/etc/isapnp.conf</filename> peut sembler étrange au début. Par
exemple, pour une adresse d'entrée/sortie 0x3e8, vous pourriez voir <quote>(IO 0
(BASE 0x3e8))</quote> à la place. <quote>IO 0</quote> veut dire qu'il s'agit de
la première plage
d'adresses que ce périphérique utilise. Une autre façon d'exprimer ceci
serait :
<quote>IO[0] = 0x3e8</quote> mais <command>isapnp</command> ne le fait pas de
cette façon.
<quote>IO 1</quote> voudrait dire qu'il s'agit de la deuxième plage d'adresse
utilisée par
ce périphérique, et cætera. <quote>INT 0</quote> a une signification similaire
mais
pour les <acronym>IRQ</acronym> (interruptions). Une carte simple peut
contenir plusieurs périphériques physiques mais l'explication ci-dessus
était seulement pour un des périphériques.</para>
</sect2>
<sect2 id="pciutils_"><title>Les utilitaires <acronym>PCI</acronym></title>
<para>Le paquetage des utilitaires <acronym>PCI</acronym>
(<command>pciutils</command>, quelque fois appelé
<quote>pcitools</quote>) vous permet de configurer manuellement via
<acronym>PnP</acronym> le bus <acronym>PCI</acronym> (avec difficulté).
<command>lspci</command> ou <command>scanpci</command> liste les ressources bus
alors que <command>setpci</command> enregistre les allocations des ressources
(sauf les <acronym>IRQ</acronym>) dans les périphériques
physiques. Il semble que <command>setpci</command> soit principalement utilisé
dans des scripts et en fait, vous aurez besoin de comprendre le détail des
registres de configuration du <acronym>PCI</acronym> pour pouvoir l'utiliser. Ce
thème n'est pas expliqué ici, et pas plus dans la page de manuel de
<command>setpci</command>.</para>
<para>Les gens l'ont utilisé pour configurer les périphériques
<acronym>PCI</acronym> dont le pilote a échoué dans cette action. Un exemple
est disponible dans le guide pratique sur les modems et le guide pratique sur
les ports séries dans la sous-section <quote><acronym>PCI</acronym> :
Activer un port
désactivé</quote>. Néanmoins, activer un périphérique n'est d'aucune utilité si
vous
n'avez pas de pilote fonctionnel pour ce périphérique.</para>
</sect2>
<sect2 id="windows_conf"><title>Configuration de Windows</title>
<para>Cette méthode utilise MS Windows pour configurer et devrait être utilisée
seulement si tout le reste échoue. Si vous avez Windows 9x (ou 2k) sur le même
PC, alors lancez simplement Windows et laissez-le configurer
<acronym>PnP</acronym>. Puis lancez Linux à partir de Windows (ou DOS) en
utilisant, par exemple, <command>loadlin.exe</command>. Il peut y avoir un
problème avec les <acronym>IRQ</acronym> pour les périphériques
<acronym>PCI</acronym>. Quand Windows s'arrête (sans messages) pour laisser la
place à Linux, il pourrait écraser l'<acronym>IRQ</acronym> (en y mettant 0) qui
est stocké dans un des registres de configuration du périphérique
<acronym>PCI</acronym>. Linux se plaindra de trouver une <acronym>IRQ</acronym>
0.</para>
<para>Ce qu'on vient d'aborder arrive lorsque vous lancez Linux en utilisant un
raccourci (fichier PIF). Mais un moyen de contourner ce problème est connu si
vous utilisez toujours le raccourci PIF. Un raccourci est en quelque sorte
l'équivalent du lien symbolique sous Linux, mais il est en fait plus que ça car
il est paramétrable. Pour lancer Linux, à partir de DOS, vous créez un fichier
batch (script) qui lance Linux. (Le programme qui lance Linux est dans le
paquet appelé <application>loadlin</application>.) Ensuite, créez un raccourci
PIF vers ce fichier batch et allez dans la fenêtre des propriétés du raccourci.
Sélectionnez <quote>Avancé</quote>, puis vérifiez que le <quote>mode
MS-DOS</quote> est bien coché.</para>
<para>Maintenant, voici une astuce empêchant de mettre à zéro les
<acronym>IRQ</acronym> <acronym>PCI</acronym>. Cochez <quote>Spécifier une
nouvelle
configuration MS-DOS</quote>. Ensuite, soit vous acceptez la configuration par
défaut
qui vous est proposée soit vous cliquez sur <quote>Configuration</quote> pour la
modifier.
Maintenant, lorsque vous lancerez Linux en cliquant sur le raccourci, des
nouveaux fichiers de configurations (<filename>config.sys</filename> et
<filename>autoexec.bat</filename>) seront créés pour votre nouvelle
configuration.</para>
<para>Les anciens fichiers sont enregistrés comme
<filename>Config.wos</filename> et <filename>Autoexec.wos</filename>. Une fois
que vous avez terminé d'utiliser Linux et que vous avez arrêté votre PC, vous
aurez encore besoin de ces fichiers pour pouvoir lancer DIS la prochaine fois
que vous démarrerez votre PC. Vous devez vous assurer que les noms redeviennent
<filename>*.sys</filename> et <filename>*.bat</filename>. Lorsque vous quittez
Windows/DOS pour aller sous Linux, Windows s'attend que, une fois que vous avez
fini avec Linux, vous retourniez à Windows pour que celui-ci puisse restaurer
ces fichiers avec leur noms originaux. Mais ceci n'arrivera pas car lorsque
vous quitterez Linux, vous éteindrez votre PC et ne retournerez pas sous
Windows. Donc, comment renommer ces fichiers ? C'est facile, placez ces
commandes dans votre fichier batch de lancement de Linux pour qu'il renomme les
fichiers. Mettez ces commandes de renommage dans votre fichier batch juste
avant la ligne qui charge Linux.</para>
<para>De la même façon, il a été rapporté que vous devez cliquer sur l'onglet
<quote>Général</quote> (de la fenêtre <quote>Propriétés</quote> de votre
raccourci) et cochez <quote>Lecture
seule</quote>. Sinon, Windows pourrait remettre à zéro les <quote>Paramétrages
avancées</quote> en
<quote>Utilisez la configuration MS-DOS courante</quote> et les
<acronym>IRQ</acronym>
<acronym>PCI</acronym> se retrouveraient à zéro. Comme Windows efface les
<acronym>IRQ</acronym> lorsque vous utilisez la configuration MS-DOS courante
mais il n'efface pas une nouvelle configuration (qui peut configurer tout de
manière identique à l'ancienne configuration). Windows ne semble pas très
cohérent.</para>
</sect2>
<sect2 id="sw_and_docs"><title>Documents/Logiciels
<acronym>PnP</acronym></title>
<para>
<itemizedlist>
<listitem><para><ulink url="http://www.roestock.demon.co.uk/isapnptools/">Page
d'accueil d'<command>Isapnptools</command></ulink> ;
</para></listitem>
<listitem><para><ulink url="http://www.astarte.free-online.co.uk">Proposition
pour un gestionnaire de configuration pour Linux</ulink> 1999 (n'a jamais
fait partie du noyau) ;</para></listitem>
<listitem><para><ulink
url="http://www.microsoft.com/hwdev/tech/pnp/default.asp">
Spécifications <acronym>PnP</acronym> de Microsoft</ulink> ;
</para></listitem>
<listitem><para>Livre : <acronym>PCI</acronym> System Architecture,
quatrième
édition par Tom Shanley +, MindShare 1999. Couvre les fonctionnalités
<acronym>PnP</acronym> du bus
<acronym>PCI</acronym> ;</para></listitem>
<listitem><para id="pnp_book">Livre : Plug and Play System
Architecture, par Tom Shanley, Mind Share 1999. Détails sur
<acronym>PnP</acronym> pour le bus <acronym>ISA</acronym>. Une vue de
<acronym>PnP</acronym> avec le bus
<acronym>PCI</acronym> ;</para></listitem>
<listitem><para>Livre : Programming Plug and Play, par James Kelsey, Sams
1995.
Détails sur la programmation pour communiquer avec un
<acronym>BIOS</acronym> <acronym>PnP</acronym>. Couvre les bus
<acronym>ISA</acronym>, <acronym>PCI</acronym> et PCMCIA.</para></listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
<sect1 id="tell_driver_config"><title>Indiquer au pilote la
configuration ??</title>
<sect2><title>Introduction</title>
<para>Un pilote moderne trouvera pour un périphérique la configuration des
ressources bus sans que vous ayez besoin de lui dire quoi que ce soit. Il
pourrait même enregistrer les ressources bus au niveau matériel en utilisant
des méthodes <acronym>PnP</acronym>. Certains périphériques ont plus d'une
façon pour trouver comment leur périphérique physique est configuré. Dans le
pire des cas, vous devez coder en dur les ressources bus dans le noyau (ou un
module) et recompiler.</para>
<para>En un juste milieu, il existe des cas tels que le lancement d'un
programme pour donner les informations des ressources bus au pilote ou pour
mettre les informations dans un fichier de configuration. Dans certains cas,
le pilote peut chercher le périphérique aux adresses où il suppose qu'il réside
(mais il ne trouvera jamais un périphérique <acronym>PnP</acronym> s'il n'a
pas été activé par des méthodes <acronym>PnP</acronym>). Il peut même essayer
de tester différentes <acronym>IRQ</acronym> pour voir laquelle fonctionne.
Il peut, ou non, le faire automatiquement.</para>
<para>Dans d'autres cas, le pilote peut utiliser des méthodes
<acronym>PnP</acronym> pour trouver le périphérique et la façon dont les
ressources bus ont été configurées par le <acronym>BIOS</acronym>, et cætera
mais ne les modifiera pas. Il peut aussi regarder dans certains des
<quote>fichiers</quote> du répertoire <filename
class="directory">/proc</filename>.</para>
<para>
Il peut aussi dire <quote>manuellement</quote> au pilote les ressources
bus qu'il doit utiliser. Vous donnez ces ressources bus en tant que
paramètre au noyau ou à un module. Si le pilote est intégré au noyau,
vous passez les paramètres au noyau via l'invite du démarrage. Voir le
<ulink url="&howto;BootPrompt-HOWTO.html">Guide pratique sur l'invite de
démarrage (<foreignphrase>BootPrompt-HOWTO</foreignphrase>)</ulink> pour
la description de quelques ressources bus et autres paramètres. Une fois
que vous savez quels paramètres donner au noyau, vous pouvez les
enregistrer dans un fichier de configuration du chargeur. Par exemple,
mettez <userinput>append="…"</userinput> dans le fichier
<filename>lilo.conf</filename> puis lancez lilo pour qu'il mette à jour
les informations de lancement.
</para>
<para>
Si le pilote est chargé comme module, dans plusieurs cas, le module
trouvera les ressources bus nécessaires et les enregistrera dans le
périphérique. Dans les autres cas (généralement pour les anciens PC),
vous pouvez avoir besoin de donner les ressources bus comme paramètres
du module. Les paramètres d'un module peuvent être spécifiés dans
<filename>/etc/modules.conf</filename>. Ce sont généralement des outils
utilisé pour modifier ce fichier et qui sont dépendant de la
distribution. Les commentaires inclus dans ce fichier devraient vous
aider sur la façon de le modifier. De même, tout module que vous placez
dans <filename>/etc/modules</filename> se verra charger avec ses
paramètres.
</para>
<para>Bien qu'il ait une grande hétérogénéité sur la façon dont les pilotes
trouvent leur ressources bus, le but final est le même. Si vous avez des
problèmes avec un pilote, vous pouvez avoir besoin de regarder la documentation
du pilote (vérifier la documentation du noyau). Quelques exemples brefs de
pilotes sont présentés dans les sections suivantes :</para>
</sect2>
<sect2><title>Exemple de pilote de port série</title>
<para>Pour les ports séries <acronym>PCI</acronym> (et pour les ports série
<acronym>ISA</acronym> <acronym>PnP</acronym> après le noyau 2.4), le pilote série détecte le type de port
série et le configure via <acronym>PnP</acronym>. Malheureusement, quelques
ports série <acronym>PCI</acronym> ne sont pas encore gérés.</para>
<para>Pour le pilote du port série <acronym>ISA</acronym> standard avec les
anciennes versions du noyau et pour le pilote série (ne faisant pas partie des
cartes multiports), le pilote travaille sur deux adresses standards pour les
ports série. Il ne cherche pas d'IRQ mais il affecte l'IRQ <quote>standard</quote>
aux deux premiers ports séries. Ceci peut être mauvais.</para>
<para>Pour tout autre chose dans le fichier de configuration, le programme
<command>setserial</command> doit être modifié manuellement. Voir le <ulink
url="&howto;Serial-Programming-HOWTO.html">Guide pratique sur la programmation
des ports série</ulink> pour plus de détails. Vous utilisez
<command>setserial</command> pour informer le pilote de l'adresse
d'entrée/sortie et <command>setserial</command> est souvent exécuté à partir
d'un fichier de démarrage. Dans les versions récentes, il existe un fichier
<filename>/etc/serial.conf</filename> (ou
<filename>/var/lib/setserial/autoconfig</filename>) que vous <quote>éditez</quote>
en lançant simplement la commande <userinput>setserial</userinput> de façon
ordinaire et ce que vous configurez avec <command>setserial</command> est
sauvegardé dans le fichier de configuration <filename>serial.conf</filename>.
Le fichier <filename>serial.conf</filename> devrait être consulté lorsque la
commande <command>setserial</command> est lancée à partir d'un fichier de
démarrage. Votre distribution peut, ou non, avoir configuré ceci pour
vous.</para>
<para>Il existe deux façons d'utiliser <command>setserial</command> suivant les
options que vous lui donnez. Une possibilité est de dire manuellement au pilote
la configuration. L'autre méthode est de tester une adresse donnée et d'indiquer
si un port série existe à cet endroit. Il peut aussi tester cette adresse et
essayer de détecter l'<acronym>IRQ</acronym> utilisée par ce port.</para>
<para>Même avec des noyaux modernes, <command>setserial</command> est quelque
fois nécessaire si le pilote échoue lors de la détection du port série ou si
vous avez un très ancien matériel.</para>
</sect2>
</sect1>
<sect1 id="current_config"><title>Comment puis-je trouver les périphériques et
comment sont-ils configurés ?</title>
<sect2><title>La recherche des périphériques et la découverte de la
configuration sont liés</title>
<para>Une fois que vous avez trouvé votre matériel, le même programme qui l'a
trouvé vous indique normalement comment il est configuré. Donc, trouver
comment un matériel est configuré revient habituellement à trouver le matériel.
</para>
</sect2>
<sect2><title>Les périphériques pourraient avoir deux <quote>configurations</quote></title>
<para>Ici, <quote>configuration</quote> correspond à l'assignation des
ressources
bus <acronym>PnP</acronym> (adresses, <acronym>IRQ</acronym> et
<acronym>DMA</acronym>). Pour chaque périphérique, il existe deux parties à
cette question de configuration :
<itemizedlist>
<listitem><para>Que croit le pilote en ce qui concerne la configuration
matérielle ?</para></listitem>
<listitem><para>Quelle configuration (s'il y en a une) est réellement
enregistrée au niveau du matériel ?</para></listitem>
</itemizedlist>
Chaque partie devrait avoir la même réponse (la même configuration). La
configuration du périphérique physique et de son pilote devrait être évidemment
la même (elle l'est habituellement). Mais les choses ne fonctionnent
pas toujours bien et c'est pourquoi il existe une différence. Ceci veut dire
que le pilote dispose d'une mauvaise information sur la configuration actuelle
du matériel. Les problèmes arrivent. Si le logiciel que vous utilisez ne vous
dit pas exactement ce qui ne va pas (ou ne configure pas automatiquement
correctement), alors vous avez besoin de chercher comment vos périphériques
physiques et vos pilotes sont configurés. Alors que les pilotes de
périphériques Linux devraient tout vous dire, dans certains cas, il n'est pas
facile de déterminer ce qui a été enregistré au niveau matériel.</para>
<para>Un autre problème est que lors de la visualisation des messages de
configuration à l'écran, vous devez savoir si la configuration
affichée est celle du pilote, du périphérique physique ou des deux. Si le
pilote de périphérique a soit enregistré la configuration soit vérifié le
matériel, alors le pilote devrait avoir les bonnes informations.</para>
<para>Mais, quelquefois, le pilote a obtenu des ressources incorrectes par un
script ou un fichier de configuration, par des paramètres de ressources
incorrectes données à un module, ou peut-être même que la configuration ne lui a
pas été fournie complètement et qu'il essaie d'utiliser par défaut des ressources
incorrectes. Par exemple, quelqu'un peut utiliser <command>setserial</command>
pour indiquer au pilote de périphérique une configuration incorrecte des
ressources et le pilote les acceptera sans broncher. Mais le port série ne
fonctionne pas bien (s'il fonctionne tout court).</para>
</sect2>
<sect2><title>Trouver le matériel</title>
<para>Un problème habituel est que le logiciel ne détecte pas votre
périphérique ou ne détermine pas le bon pilote pour celui-ci. Pour les
périphériques <acronym>PnP</acronym>, les détecter est facile avec un
logiciel <acronym>PnP</acronym> sauf pour le cas inhabituel où le
matériel a été désactivé. Le <acronym>BIOS</acronym> peut parfois être
initialisé pour désactiver les périphériques <acronym>PnP</acronym> ou
un cavalier/interrupteur sur le périphérique physique lui-même pourrait
le désactiver. Dans ce cas, le matériel ne peut pas être détecté du tout
jusqu'à ce que vous re-configuriez le <acronym>BIOS</acronym> ou que
vous changiez le cavalier/interrupteur.</para>
<para>Comme le bus <acronym>PCI</acronym> est intrinsèquement
<acronym>PnP</acronym>, il n'y a pas de périphériques
cachés. Même si les périphériques <acronym>PnP</acronym> sont faciles à trouver
avec les méthodes
PnP, si le pilote n'utilise pas les méthodes <acronym>PnP</acronym> mais utilise
l'ancienne méthode
de recherche aux adresses supposées, ils pourraient ne pas être trouvés. Ceci
est dû au fait que, avant que les ressources bus aient été initialisées (par le
<acronym>BIOS</acronym> ou Linux), le périphérique pourrait ne pas avoir
d'adresses du tout, donc
parcourir les adresses habituelles n'apportera rien. Pour l'ancien bus
<acronym>ISA</acronym>,
quelques-uns des périphériques pourraient être non <acronym>PnP</acronym> et, de
ce fait, les
anciennes méthodes pourraient fonctionner. Donc, de nombreux pilotes continuent
à parcourir les adresses habituelles en plus d'utiliser les méthodes
<acronym>PnP</acronym>
(parcours <acronym>PnP</acronym>, quelquefois appelé simplement
parcours).</para>
<para>Façons de détecter des périphériques matériels (et leur configurations)
: (suivre le lien pour plus de détails)
<itemizedlist>
<listitem><para>Vérifier le <acronym>BIOS</acronym> pour vous assurer qu'ils
ne sont pas désactivés ;</para></listitem>
<listitem><para>Regarder les messages de démarrage à l'écran (voir <link
linkend="boot_time_msgs">les messages au démarrage</link>) ;
</para></listitem>
<listitem><para>Regarder dans <xref linkend="proc_dir"/> ;
</para></listitem>
<listitem><para><link linkend="hw_detect">Outils pour détecter et
configurer tout le matériel</link>... lsdev, hwinfo, discover,
kudzu ;</para></listitem>
<listitem><para><link linkend="hw_detect_one_type">Outils pour
détecter ou
configurer un type de matériel</link> ;</para></listitem>
<listitem><para><acronym>PCI</acronym> : <xref linkend="pci_"/>
</para></listitem>
<listitem><para>Bus <acronym>ISA</acronym> : <xref linkend="isa_bus"/>
</para></listitem>
<listitem><para>Bus <acronym>ISA</acronym> : <xref linkend="isa_pnp"/>
</para></listitem>
<listitem><para>Bus <acronym>ISA</acronym> : <xref linkend="non_pnp"/>
</para></listitem>
<listitem><para>Bus <acronym>ISA</acronym> : <xref linkend="jumpers_"/>
</para></listitem>
<listitem><para>Bus <acronym>ISA</acronym> : <xref linkend="neither_"/>
</para></listitem>
<listitem><para>Et <xref linkend="check_ms"/>
</para></listitem>
</itemizedlist>
</para>
</sect2>
<sect2 id="boot_time_msgs"><title>Messages de démarrage</title>
<para>Des informations significatives sur la configuration peuvent être obtenues
en lisant
les messages affichés par le <acronym>BIOS</acronym> et par Linux lors du
démarrage de l'ordinateur. Ces messages disparaissent souvent trop rapidement
pour être lus mais, une fois le défilement terminé, tapez
<keycombo><keycap>Majuscule</keycap><keycap>Page Suivante</keycap></keycombo>
plusieurs
fois pour revenir en arrière. Pour aller en avant, faites
<keycombo><keycap>Majuscule</keycap><keycap>Page Précédente</keycap></keycombo>.
Utilisez
<command>dmesg</command> à la console à n'importe quel moment pour afficher
seulement les messages du noyau. Vous ne verrez pas certains messages les plus
importants provenant généralement du <acronym>BIOS</acronym>. Les messages
affichés par Linux peuvent parfois n'afficher que ce que le pilote de
périphérique croit être configuré, peut-être à cause d'un mauvais fichier de
configuration. Vérifier les fichiers de traces dans <filename
class="directory">/var/log</filename> peut être utile.</para>
<para>Pour le bus <acronym>PCI</acronym>, la notation 00:1a:0 signifie le
bus <acronym>PCI</acronym> 00 (le bus <acronym>PCI</acronym> principal), la
carte <acronym>PCI</acronym> (ou le composant) 1a et la fonction 0 (le premier
périphérique) sur la carte ou le composant. Le deuxième périphérique sur la
carte (ou sur le composant) devrait être 00:08:1.</para>
<para>Les messages du <acronym>BIOS</acronym> s'affichent en premier et
montrent la configuration du matériel à ce moment, mais
<command>isapnp</command>, ou les utilitaires <acronym>PCI</acronym>, voire les
pilotes de
périphériques peuvent le changer plus tard. Dans certains cas, il n'affiche pas
les périphériques que le <acronym>BIOS</acronym> n'a pas configuré.</para>
<para id="pause_">Si les messages du <acronym>BIOS</acronym> ne s'affichent pas
en revenant au
début des messages du <acronym>BIOS</acronym> avec
<keycombo><keycap>Majuscule</keycap><keycap>Page Suivante</keycap></keycombo>,
essayez de mettre en pause lorsqu'ils apparaissent, en utilisant la touche
<keycombo><keycap>Pause</keycap></keycombo> dès que les premiers mots
apparaissent. Appuyez sur n'importe quelle touche pour continuer. Il est souvent
difficile d'appuyer sur <keycombo><keycap>Pause</keycap></keycombo> exactement
au bon moment. Assurez-vous d'appuyer continuellement sur la touche
<keycombo><keycap>Shift</keycap></keycombo> avant d'appuyer sur
<keycombo><keycap>Pause</keycap></keycombo> car
<keycombo><keycap>Pause</keycap></keycombo>
est une touche nécessitant l'utilisation de
<keycombo><keycap>Shift</keycap></keycombo>.
Si vous n'avez pas réussi, appuyez sur
<keycombo><keycap>Ctrl</keycap>
<keycap>Alt</keycap>
<keycap>Del</keycap></keycombo>
au lancement de Linux pour le relancer et essayer de nouveau. Une fois que les
messages de Linux commencent à être visibles, il est trop tard pour utiliser
<keycombo><keycap>Pause</keycap></keycombo> car cela ne gèlera pas les messages
de Linux.</para>
<para>Pour initialiser des éléments du <acronym>BIOS</acronym> comme les
<acronym>IRQ</acronym> réservés au matériel
propriétaire, aux adresses des ports série, et cætera vous aurez besoin d'entrer dans
les menus de configuration du <acronym>BIOS</acronym> (CMOS) au lancement.
Chaque marque de <acronym>BIOS</acronym> a
différentes touches pour ce faire. Il existe des listes sur Internet. Parfois
en gelant l'affichage des messages du <acronym>BIOS</acronym> ou en
regardant l'écran, la
touche que vous devez appuyer sera indiquée dans un message tel que
<quote>Press DEL for setup</quote> (<quote>Appuyez sur DEL pour la
configuration</quote>). Mais il pourrait disparaître si rapidement que vous ne
le
verrez pas. Bien sûr, vous ne modifiez rien dans le <acronym>BIOS</acronym> que
vous ne comprenez
pas. Le cas contraire, votre PC pourrait être désactivé.</para>
<para>Les messages du <acronym>BIOS</acronym> au démarrage vous indiquent
ce que fut la configuration du matériel. La configuration actuelle
pourrait toujours être la même que ce qu'a fait le
<acronym>BIOS</acronym> et que Linux devrait accepté si c'est bon. Les
messages de Linux pourraient provenir des pilotes utilisant les
fonctions <acronym>PnP</acronym> du noyau pour inspecter ou configurer
les ressources bus. Cela devrait être correct mais attention aux
messages qui affichent seulement ce que le pilote a lu de son fichier de
configuration. Cela pourrait être faux. Bien sûr, si le périphérique
fonctionne bien, alors il est configuré probablement de la même façon
par le pilote.</para>
</sect2>
<sect2 id="proc_dir"><title>Le répertoire /proc</title>
<para>Depuis le noyau 2.6, il existe aussi un répertoire <filename
class="directory">/sys</filename> en plus du répertoire <filename
class="directory">/proc</filename>. Ces répertoires sont utiles pour récupérer
les configurations des ressources et périphériques. Les fichiers qu'ils
contiennent représentent des données provenant de la mémoire du noyau et
n'existent pas du tout sur votre disque dur. Les programmes comme
<filename>lspci</filename> récupèrent leurs informations du répertoire
<filename class="directory">/proc</filename> et ils doivent les afficher
d'une façon plus lisible qu'en lisant directement le contenu des fichiers
de ce répertoire. Voici quatre fichiers provenant de <filename
class="directory">/proc</filename> qui montrent les ressources enregistrées
dans le noyau par les pilotes de périphériques.</para>
<para>Comme le Plug-And-Play de Linux fonctionne en laissant les pilotes de
périphériques alloués les ressources pour leur périphérique, il pourrait ne
pas y avoir de ressources utilisées par certains de vos matériels si le pilote
n'a pas encore réclamé que ces ressources lui soient réservées. Pour les cas
des modules du noyau (pilotes de périphérique chargeables), si le module n'est
pas encore chargé, le noyau ne connaît pas les ressources dont le module a
besoin. Quelque fois, le module se charge seulement quand vous lancez une
application qui en a besoin. Donc, si un certain matériel est manquant parmi
les fichiers de <filename class="directory">/proc</filename>, cela pourrait
signifier que le matériel n'a pas encore été utilisé. Par exemple, même si votre
lecteur de disquette dispose d'une disquette et est prêt à être utilisé, son
interruption n'apparaîtra tant que le lecteur n'est pas utilisé.</para>
<para><filename>/pts</filename> affiche les adresses d'entrée/sortie. S'il y a
une erreur (mauvaise adresse), cela pose problème car le périphérique n'obtiendra
pas les octets qui lui sont envoyés. <filename>/proc/iomem</filename> affiche
les adresses mémoires d'entrée/sortie qui sont réservées.
<filename>/proc/interrupts</filename> affiche les interruptions en cours
d'utilisation. <filename>/proc/dma</filename> affiche les allocations de canaux
DMA pour le bus ISA.</para>
<para>Dans le passé, l'auteur a observé une liste d'interruptions qui
n'existaient pas. Dans certains cas, cela montrait que quelques interruptions
étaient vraiment envoyées. Ceci peut être dû à des matériels défectueux envoyant
des interruptions erronées.</para>
<para><filename class="directory">/proc/bus/</filename> contient les
sous-répertoires <filename class="directory">/input/</filename>, <filename
class="directory">/pci/</filename> et <filename
class="directory">/isapnp/</filename>. Le format de la plupart des fichiers
dans ce répertoire est vraiment cryptique, souvent une simple copie des octets de
l'espace de configuration. Donc, utilisez-les seulement en dernier ressort. Le
sous-répertoire <filename class="directory">input/</filename> a des informations
sur les périphériques en entrée comme le clavier ou la souris. Elles ne sont pas
aussi complexes que les autres répertoires sous <filename
class="directory">/proc/bus</filename> et pourraient fournir des informations
utiles sur les périphériques d'entrées qui sont sur les ports <acronym>PS2</acronym>
ou sur le bus <acronym>LPC</acronym> (voir <xref linkend="lpc_"/>).
Malheureusement, ce que j'ai vu ne dit pas que c'est sur le bus
<acronym>LPC</acronym> où il est probablement. Dans
<filename class="directory">/pci/00/</filename> se trouve un fichier binaire pour
chaque périphérique <acronym>PCI</acronym> où les noms des fichiers sont les
numéros des emplacements <acronym>PCI</acronym>. Le 00 signifie le bus
<acronym>PCI</acronym> 0.</para>
</sect2>
<sect2 id="sys_dir"><title>Le répertoire /sys</title>
<para>À partir du noyau 2.6, il existe un nouveau répertoire /sys pour la
configuration de <acronym>PnP</acronym>. Il s'agit d'un système de fichiers de
type sysfs et c'est un équivalent du système de fichiers /proc car les
<quote>fichiers</quote> représentent une information de la mémoire du noyau et
non pas un vrai fichier de votre disque dur. Cependant, il n'est pas aussi utile
que le système de fichiers /proc. Au début (pour les noyaux 2.5), il s'appelait
le <quote>système de fichiers des pilotes</quote> et avait comme type
<quote>driverfs</quote>.</para>
<para>Dans ce système de fichiers, chaque périphérique existant sur votre
système a son propre répertoire contenant des fichiers spécifiant les
ressources qui lui sont affectées. Ces répertoires ont des noms comme
<filename>0000:00:12.0@</filename> ou <filename>00:06@</filename>. Quels sont
ces périphériques ? Le premier est une carte <acronym>PCI</acronym> dans
l'emplacement 12 de votre PC. L'emplacement pourrait être appelé
<acronym>PCI</acronym>2 dans votre PC (2 au lieu de 12) tout simplement parce
que les emplacements ayant des numéros fiables sont utilisés par les
emplacements intégrés à la carte mère et n'utilisent pas les emplacements
physiques. Dans cet exemple, les emplacements 1 à 10 seraient intégrés alors que
les emplacements 11 à 14 seraient appelés de 1 à 4. En exécutant
<command>lspci</command>, vous connaîtrez la correspondance entre les numéros
(comme 0000:00:12.0) et les noms (identique à l'interface IDE). Exécutez
la commande <command>lspci -vv</command>, ou <command>lspci -vv</command> si
vous voulez en voir plus.</para>
<para>Alors, qu'est-ce que <filename>00:06</filename> ? C'est une carte
<acronym>ISA</acronym> (ou un périphérique intégré) mais ce n'est pas
l'emplacement 6 du bus <acronym>ISA</acronym> (contrairement au numérotage
<acronym>PCI</acronym>). Quand une recherche est faite pour les périphériques
<acronym>PnP</acronym> <acronym>ISA</acronym>, il a été le sixième découvert.
Plus précisément, il était le septième trouvé car il existe un périphérique
numéroté 00:00. Donc, comment les identifier ? Vous pouvez lancer
<quote>cat */*</quote> et afficher tous les fichiers pour tous les périphériques
mais même à ce moment-là vous ne verrez pas les noms des périphériques (mais
vous verrez l'information qui vous permettra de l'identifier). Ce problème sera
corrigé dans le futur.</para>
<para>Non seulement ces fichiers apportent des informations sur la
configuration des ressources du bus (d'une manière un peu cryptée) et sur les
pilotes (dans les répertoires <quote>drivers</quote>) mais, dans le futur, vous
devriez être capable de les utiliser pour modifier la configuration des
ressources. Actuellement (août 2004), vous ne pouvez pas configurer le bus
<acronym>PCI</acronym> avec cela. Une sérieuse limitation est qu'avec le
<quote>modèle de pilote</quote> actuel, vous ne pouvez pas changer la ressource
d'un périphérique qui a été affecté à un pilote, ce qui signifie généralement
que vous aurez besoin de décharger le module du pilote pour pouvoir l'utiliser.
Si le pilote est intégré, il n'y a aucun espoir. Ces sérieuses limitations
seront éliminées dans le futur avec un peu de chance. Dans la documentation du
noyau se trouve un fichier <filename>pnp.txt</filename> indiquant comment
réaliser la configuration. En août 2004, il était obsolète mais
l'auteur travaille sur une mise à jour. Utiliser le répertoire <filename
class="directory">/sys</filename> pour configurer les ressources est connue
comme l'<quote>interface utilisateur pour le Plug and Play de
Linux</quote>.</para>
<para>L'autre partie de <quote>Linux Plug and Play</quote> est l'interface noyau
utilisée par les pilotes de périphériques. Elle a beaucoup changé depuis le
début du noyau 2.6 mais la plupart des pilotes utilisent toujours l'ancienne
interface (août 2004). Il est aussi possible pour les pilotes (ou vous)
d'utiliser l'interface utilisateur qui a besoin d'améliorations.</para>
</sect2>
<sect2 id="pci_"><title>Inspection du bus <acronym>PCI</acronym></title>
<para>Il est facile de trouver quelles ressources bus ont été assignées
aux périphériques du bus <acronym>PCI</acronym> avec les commandes
<command>lspci</command> et <command>scanpci</command>. Les options -v
et -vv vous donneront plus de détails. Dans certains cas,
<command>scanpci</command> trouvera un périphérique que
<command>lspci</command> ne peut pas trouver. Ceci est dû au fait que
<command>scanpci</command> recherche les périphériques directement sur
le bus <acronym>PCI</acronym> (via l'espace de configuration) et
n'utilise pas les données obtenues par le noyau (qui pourraient être
fausses à cause d'un bogue du noyau — je viens de trouver un tel
cas).</para>
<para>Cette information d'un format crypté est disponible dans les
<quote>fichiers</quote> situés dans les répertoires <filename
class="directory">/sys</filename> et <filename class="directory">/proc</filename>.
Dans <filename class="directory">/sys/bus/pci/devices</filename>, le fichier
<filename>vendor</filename> contiendra le numéro d'identifiant du vendeur, comme
0x4B8C, et cætera. Dans un format encore moins compréhensible, il se trouve dans
<filename class="directory">/proc/bus/pci</filename>. De telles informations dans
les anciens noyaux (avant le 2.6) se trouvaient dans <filename
class="directory">/proc/pci</filename> (compréhensible malgré que les
<acronym>IRQ</acronym> soient en hexadécimal) ou dans <filename
class="directory">/proc/buspci/devices</filename> (affichage non compréhensible).
</para>
<para>Dans la plupart des cas pour le <acronym>PCI</acronym>, vous verrez
seulement comment le matériel est maintenant configuré et pas quelles
ressources sont nécessaires. Dans certains cas, vous verrez seulement l'adresse
de base (le début des plages d'adresses) mais pas celle de fin. Si vous
disposez de l'espace complet, alors vous pourrez déterminer combien d'octets de
ressources sont nécessaires.</para>
</sect2>
<sect2 id="isa_bus"><title>Introduction au bus <acronym>ISA</acronym></title>
<para>Pour les cartes du bus <acronym>ISA</acronym>, ce n'est pas aussi simple
que pour le bus <acronym>PCI</acronym> qui est conçu pour le
<acronym>PnP</acronym>. Les cartes <acronym>ISA</acronym> récentes étaient
<acronym>PnP</acronym> contrairement aux anciennes. De même, certaines cartes
<acronym>PnP</acronym> ont leur partie <acronym>PnP</acronym> désactivée par
des logiciels spéciaux ne fonctionnant que sous MS Windows. Les cartes non
<acronym>PnP</acronym> sont configurées avec des cavaliers sur la carte ou par
des logiciels sous MS Windows.</para>
</sect2>
<sect2 id="isa_pnp"><title>Cartes <acronym>ISA</acronym>
<acronym>PnP</acronym></title>
<para>Si c'est une carte <acronym>PnP</acronym>, vous pouvez essayer
<userinput>pnpdump --dumpregs</userinput> mais ce n'est pas une certitude. Le
résultat peut sembler crypté mais il peut être déchiffré. Ne confondez pas les
adresses de port de lecture que <command>pnpdump</command> utilise pour
communiquer avec les cartes <acronym>PnP</acronym> avec l'adresse
d'entrées/sorties du périphérique trouvé. Elles ne sont pas identiques.</para>
</sect2>
<sect2 id="lpc_"><title>Bus <acronym>LPC</acronym></title>
<para><acronym>LPC</acronym> (acronyme de <foreignphrase>Low Pin
Count</foreignphrase>, soit petit nombre de connecteurs) est une interface
type bus souvent utilisée sur les portables et de plus en plus utilisée sur
les machines de bureau. Pour savoir si vous disposez d'un bus
<acronym>LPC</acronym>, saisissez la commande <command>lspci</command> et
cherchez quelque chose comme <quote>LPC</quote>. Il y a d'autres mots prêt de
<quote>LPC</quote> comme <quote>ISA Bridge ... LPC Interface Controller</quote>
ou <quote>LPC Bridge</quote>, et cætera. <acronym>LPC</acronym> n'est pas réellement
de l'<acronym>ISA</acronym> mais il se substitue à un bus
<acronym>ISA</acronym>.</para>
<para>L'ancien bus ISA était lent et les périphériques qui avaient besoin de
plus de rapidité étaient placés sur le nouveau bus PCI. Mais les périphériques
qui n'avaient pas besoin d'une grande vitesse étaient souvent implémentés par
des composants sur la carte mère et restaient sur le bus ISA même s'il n'y
avait aucun emplacement pour des cartes ISA. Puis le bus LPC est arrivé pour
remplacer les cartes ISA restantes. LPC est bien plus petit que l'ISA et aussi
rapide car son horloge est quatre fois plus rapide que celle du bus ISA. Son
bus multiplexé pour les données/adresses et le contrôle est composé de quatre
fils. Envoyer un octet requiert la séparation de l'octet en deux demi-octets
et leur réassemblage après. Cela explique la signification de l'acronyme
LPC : Low Pin Count (petit nombre de broches). Il y a aussi quelques lignes
sur le bus.</para>
<para>Cette petite interface LPC est utilisé pour les périphériques propriétaires
lents comme les ports séries, les ports parallèles et les lecteurs de disquette.
Donc, un ordinateur utilisant le bus LPC aura tous ces périphériques rapides sur
le bus PCI, et cætera et les périphériques lents sur le bus LPC. Tous les périphériques
LPC seront sur la carte : il n'existe pas d'emplacement pour carte LPC.</para>
<para>Un composant majeur du bus <acronym>LPC</acronym> est le composant
superio, contenant des périphériques d'entrées/sorties propriétaires :
ports série et parallèle, lecteur de disquette, contrôleur de clavier, et cætera. Le
<acronym>BIOS</acronym> pourrait même se trouver sur le bus
<acronym>LPC</acronym>. Le clavier et la souris (périphériques en entrée)
devraient être listés dans <filename>/proc/bus/input/devices</filename> mais,
au lieu de voir <quote>lpc</quote>, il semble afficher
<quote>isa0060/serio0</quote>, et cætera même s'ils se trouvent sur le bus LPC, et
non pas sur le bus ISA.</para>
</sect2>
<sect2><title>X-bus</title>
<para>Avant que le bus LPC devienne populaire, il existait un bus X (pas
couvert dans ce guide pratique) qui a servi dans le même but que le bus
LPC mais qui n'était pas aussi compact que le bus LPC. Certains PC
disposent des deux bus.</para>
</sect2>
<sect2 id="non_pnp"><title>Cartes non <acronym>PnP</acronym></title>
<para>En contraste avec les cartes <acronym>PnP</acronym>, les cartes non
<acronym>PnP</acronym> ont toujours leurs ressources configurées au niveau
matériel. C'est-à-dire qu'elles ont toujours une adresse et une
<acronym>IRQ</acronym> sauf s'il
existe une configuration par cavalier, et cætera pour désactiver le périphérique.
Quelquefois, le pilote du périphérique, ou un autre logiciel, peut trouver les
ressources utilisées simplement en cherchant sur chaque adresse. Par exemple,
<command>scanport</command> (Debian uniquement ?) cherche sur la plupart
des adresses d'entrées/sorties et peut trouver des périphériques
<acronym>ISA</acronym>. Mais, attention, cela peut bloquer votre PC. Quelque
fois, il échouera dans sa recherche du matériel disponible (car le matériel a
0xff dans ses registres). Même s'il trouve le matériel, il n'affichera pas
l'<acronym>IRQ</acronym> ou n'identifiera pas positivement le matériel.</para>
<para>Donc, une façon de trouver ce matériel est de lancer un pilote, qui
pourrait chercher un tel matériel. En regardant dans les messages du démarrage,
vous pourriez voir un pilote se lancer et découvrir le matériel. Sinon, vous
pourriez avoir besoin de trouver un pilote et de le lancer (par exemple, en le
chargeant comme un module).</para>
<para>Trouver le bon pilote peut être difficile. Quelquefois, il n'existe tout
simplement pas de pilote car certains périphériques ne sont pas (encore) gérés
par Linux. Pour déterminer le pilote dont vous avez besoin, jetez un œil
sur
toute documentation pouvant vous permettre d'identifier la carte. Si ceci
échoue, jetez un œil à la carte elle-même, avec les noms/numéros
importants
inscrits sur les composants. Mais l'identification du module de pilote dont vous
avez besoin pourrait n'être pas disponible sur la carte. Vous pouvez trouver
l'identifiant FCC sur la carte, puis chercher sur Internet avec ce numéro pour
essayer de trouver plus d'informations sur la carte (ou sur les composants en
faisant partie).</para>
</sect2>
<sect2 id="jumpers_"><title>Cartes non <acronym>PnP</acronym> avec
cavaliers</title>
<para>Si la carte dispose de cavaliers pour configurer les ressources, alors
vous pouvez regarder la façon dont ils sont installés. Il existe des cartes qui
ont à la fois le support de <acronym>PnP</acronym> et des cavaliers. Elles
fonctionnent comme des cartes à cavalier si <acronym>PnP</acronym> a été
désactivé d'une façon ou d'une autre. Vous pourriez avoir besoin de la
documentation (soit imprimée soit sur disquette) venant avec la carte. Peut-être
pourrez-vous la trouver sur Internet.</para>
</sect2>
<sect2 id="neither_"><title>Cartes non <acronym>PnP</acronym> et sans
cavaliers</title>
<para>Un des cas les plus difficiles est quand du logiciel fonctionnant sous MS
Windows a été utilisé pour configurer une carte non <acronym>PnP</acronym> ou
une carte <acronym>PnP</acronym> où la partie <acronym>PnP</acronym> a été
désactivée. Donc, vous ne pouvez la configurer par <acronym>PnP</acronym> ou par
des cavaliers. Dans ce cas, votre seul espoir est de chercher les adresses comme
décrit dans <xref linkend="non_pnp"/>. Ou essayez de trouver le logiciel MS qui
l'a configuré.</para>
</sect2>
<sect2 id="hw_detect">
<title>Outils pour détecter ou configurer le matériel</title>
<para>Dans un effort dupliqué, plusieurs distributions majeures de Linux
ont développé leur propre outil de détection et de configuration du
matériel. Ils configurent généralement bien plus que les ressources
Plug-and-Play. C'est une configuration générale qui est bien au-delà du
domaine couvert par ce guide pratique.</para>
<para>Puis, d'autres distributions, comme Debian, pouvaient obtenir des copies
des outils et les offrir à leurs utilisateurs comme option ou comme outil en
cas de problème. Ces outils utilisent généralement les outils Linux standard
pour détecter le matériel, comme par exemple <command>lspci</command>. Dans la
liste d'outils qui suit, le nom de la distribution qui l'a conçu est entre
parenthèses mais l'outil est certainement disponible aussi pour les autres
distributions.</para>
<itemizedlist>
<listitem><para><command>hardinfo</command> ;</para></listitem>
<listitem><para><command>hwinfo</command> (SuSE) détecte plus de choses que
<command>discover</command> ;</para></listitem>
<listitem><para><command>discover</command> (Progeny, utilisé par
Debian) ;</para></listitem>
<listitem><para><command>Kudzu</command> (RedHat) détecte et
configure ;</para></listitem>
<listitem><para><command>lsdev</command> (commande Linux
standard) ;</para></listitem>
<listitem><para><command>hwsetup-knoppix</command> (Knoppix, basé sur
Kudzu).</para></listitem>
</itemizedlist>
</sect2>
<sect2 id="hw_detect_one_type">
<title>Outils pour détecter et configurer un type de matériel</title>
<para>Il existe différents outils disponibles pour trouver et, quelque fois,
configurer différents types de périphériques. Cette configuration est
généraliste et n'est pas couverte dans ce guide pratique.</para>
<itemizedlist>
<listitem><para><command>read-edid</command> (<command>get-edid</command>) :
récupère les paramètres des moniteurs <acronym>VESA</acronym> (à part les
très anciens) ;</para></listitem>
<listitem><para><command>sndconfig</command> : pour les cartes
son ;</para></listitem>
<listitem><para><command>printtool</command> : imprimantes (X-window doit
être en cours d'exécution) ;</para></listitem>
<listitem><para><command>pconf-detect</command> : ports
parallèles ;</para></listitem>
<listitem><para><command>gpm-mouse-test</command> : détecte et teste les
souris</para></listitem>
<listitem><para><command>mdetect</command> : détecte et configure les
souris. Connaît-il les souris sur
<filename>/dev/input/</filename> ?</para></listitem>
<listitem><para><command>nictools-pci</command> (et <command>nictools-nopci</command>)
pour les cartes ethernet ;</para></listitem>
<listitem><para><command>hdparm</command> : configure les disques
durs ;</para></listitem>
<listitem><para><command>hotplug</command> : utilisé par le
noyau ;</para></listitem>
<listitem><para><command>xvidtune</command> : configure la vidéo avec
Xwindows (voir XFree86-Video-Timings-HOWTO).</para></listitem>
</itemizedlist>
</sect2>
<sect2 id="check_ms">
<title>Utilisez MS Windows</title>
<para>Quelques personnes ont essayé d'utiliser Windows pour voir comment
les ressources bus étaient configurées. Malheureusement, comme le
matériel <acronym>PnP</acronym> oublie sa configuration de ressources
bus à l'arrêt, la configuration peut ne pas être identique lors du
redémarrage sous Linux pour le matériel non <acronym>PnP</acronym> (ou
lorsque quelqu'un a désactivé <acronym>PnP</acronym> dans le
périphérique soit par des cavaliers soit en utilisant des logiciels
Windows). Même pour <acronym>PnP</acronym>, cela peut être le cas parce
que dans beaucoup de cas, Windows et Linux acceptent simplement ce que
le <acronym>BIOS</acronym> a fait. Mais là où Windows et Linux font une
configuration, ils peuvent le faire différemment. Donc ne comptez pas à
ce que les périphériques soient configurés de la même manière. </para>
</sect2>
</sect1>
<sect1 id="pci_int"><title>Interruptions PCI</title>
<sect2>
<title>Introduction</title>
<para>Chaque périphérique PCI qui a besoin d'une interruption vient avec une
interruption PCI fixe qui ne peut pas être modifié. Elle est désigné par un
numéro de slot et une lettre (A, B, C ou D), par exemple 3:B. Mais, cette
interruption PCI est redirigée vers un numéro d'interruption ISA, comme par
exemple 21 pour un composant sur la carte mère.</para>
<para>Ce routage est réalisé par un routeur programmable d'interruptions
(<acronym>PIR</acronym>, acronyme de <foreignphrase>programmable interrupt
router</foreignphrase>). Autrement, une ligne d'interruption pourrait être
routée directement (sans aucun PIR). Si un PIR est présent, il peut être
programmé par le BIOS ou par Linux. Donc, l'interruption d'un periphérique
PCI peut quelque fois être modifiée, non pas en envoyant l'interruption sur
un fil différent, mais en modifiant le routage d'un envoi sur ce film en
programmant le PIR. Quand le routage est modifié, l'interruption fournie
par ce nouveau routage est écrit dans un registre de configuration situé
dans le composant du périphérique.</para>
</sect2>
<sect2><title>Historique : des interruptions ISA aux PCI</title>
<para>Avant l'arrivée du bus PCI, les PC utilisaient le bus ISA. Ensuite, lors
de la transition vers le nouveau bus PCI, les PC utilisaient les bus ISA et PCI.
Le bus ISA est fait de telle façon que toutes les lignes d'interruption arrivent
sur chaque carte, donc toute carte peut modifier son numéro d'IRQ tout simplement
en envoyant son signal d'interruption sur la ligne souhaitée. Tous les signaux
d'interruption étaient envoyés au contrôleur d'interruption qui envoyait
ensuite un signal au processeur pour lui indiquer de stopper temporairement son
travail et de lancer le code du pilote pour répondre à l'interruption.</para>
<para>Quand le PCI est apparu, la solution simple était d'établir une
correspondance entre les interruptions PCI et les interruptions ISA qui
n'étaient pas utilisées. Ceci nécessite l'utilisation du PIR, routeur
programmable d'interruptions. Ce routeur réalise la correspondance. Comme
il n'y avait que 15 interruptions, il était commun de placer plusieurs
périphériques PCI sur les quelques interruptions disponibles. Résoudre ce
problème est simple : proposer un nouveau matériel pour augmenter le
nombre d'interruptions. Le résultat est l'APIC. Son adoption a été lente car
la capacité du bus PCI à partager les interruptions a diminué le problème.
En fait, l'APIC a été principalement utilisé avec les machines bi-processeurs.
</para>
</sect2>
<sect2><title>Contrôleur avancé d'interruptions programmées
(<acronym>APIC</acronym>, acronyme de <foreignphrase>Advanced Programmable
Interrupt Controller</foreignphrase>)</title>
<para>Un APIC peut fournir (suivant le modèle) 16, 24, 32 ou 64
interruptions, etc. Il peut aussi gérer le routage d'interruptions d'un
processeur vers un autre. Voir le fichier « IO-APIC » dans le répertoire
i386 de la documentation du noyau et le guide pratique sur l'ACPI.
Ne confondez pas APIC avec ACPI (Configuration avancée et interface pour la
gestion d'énergie) qui peut être utilisé par le noyau pour configurer l'APIC.
</para>
<para>Le contrôleur APIC actuel qui est connecté sur les lignes d'interruptions
est un APIC I/O (ou IO-APIC ou IOAPIC). En utilisant plus d'un IO-APIC, on
peut obtenir plus d'interruptions et elles sont numérotées de façon à être
uniques. Par exemple, le premier contrôleur peut les numéroter de 0 à 23 et le
second les appelera de 24 à 47, ce qui donne 48 interruptions numérotées de 0
à 47. Mais certaines personnes ont des numéros d'interruptions hauts. Se
pourrait-il que le deuxième IO-APIC commence la numérotation avec un numéro de
base haut, laissant ainsi beaucoup d'IRQ inexistants. ?</para>
<para>En plus des IO-APIC, il existe des APIC locaux (LAPIC) qui font partie de
chaque processeur. L'IO-APIC travaille en communiquant avec les LAPIC compris
dans les processeurs.</para>
<para>Quand APIC a été introduit, les anciens PIC ISA étaient aussi conservés
en laissant le choix d'utiliser ou non l'APIC ou le PIC ISA (qui est quelque fois
appelé PIC ou XT-PIC dans <emphasis>/proc/interrupts</emphasis> ; le
XT vient du PC XT d'IBM qui était le second modèle de PC d'IBM en 1983).
Il est possible de dire au noyau (sur la ligne de commande du noyau) de ne pas
utiliser APIC auquel cas il utilisera le vieux XT-PIC s'il est disponible. Comme
l'APIC peut avoir plus d'interruptions que les 15 fournies par XT-PIC, il pourrait
y avoir des problèmes ??</para>
<para>Pour savoir si vous utilisez PIC ou APIC, regardez dans <emphasis>/proc/interrupts</emphasis>.
Si vous voyez <emphasis>XT-PIC</emphasis> pour l'IRQ 2 seule et
<emphasis>IO-APIC</emphasis> pour les autres, cela pourrait signifier que vous
avez l'ancien XT-PIC mais qu'il n'est pas actuellement utilisé. En fait, l'IRQ
2 est utilisé pour la communication entre les deux anciens XT-PIC juste au cas
où vous en auriez besoin après avoir désactiver l'APIC. Deux XT-PIC sont
nécessaires car chacun supportent seulement huit interruptions.</para>
</sect2>
<sect2><title>Interruptions signalées par message (MSI)</title>
<para>Un autre nouveau développement concerne les interruptions signalées par
message (MSI, acronyme de <foreignphrase>Message Signalled
Interrupts</foreignphrase> (MSI) où l'interruption est juste un message
envoyé à une adresse spéciale sur le bus principal de l'ordinateur (pas
de ligne d'interruption nécessaire). Mais le périphérique qui envoie un
tel message doit tout d'abord obtenir le contrôle du bus principal de
façon à ce qu'il puisse envoyer le message d'interruption. Un tel
message contient plus d'informations que <quote>J'envoie une
interruption</quote>. Il contient un index pour l'adresse du programme qui
a besoin d'être exécuté pour remplir la mission de l'IRQ. Ce nombre, par
exemple 3, signifie que le processeur trouve l'adresse à laquelle il doit
se rendre dans le troisième élément d'une table spéciale connue du
processeur.</para>
<para>Comme le matériel du périphérique doit connaître MSI pour que le
périphérique utilise MSI, il est fréquent que certains périphériques
utilisent MSI alors que d'autres utilisent les interruptions traditionnelles.
Since for a device to use MSI the device hardware must support MSI,
Les méthodes conventionnelles du support matériel des interruptions (appelées
INTx) seront donc certainement présentes pendant longtemps encore. Les MSI
ont des numéros d'interruption comme les interruptions INTx mais ces nombres
sont souvent trop grands pour éviter toute réutilisation des nombres des
interruptions INTx.</para>
</sect2>
<sect2><title>Partage des interruptions PCI</title>
<para>Les interruptions PCI peuvent être partagées, signifiant que deux
périphériques voire plus utilisent la même IRQ. C'est faisable, il est
généralement préférable de ne pas les partager. Le partage ne fonctionne pas
bien pour les très anciens matériels PCI (avant 1995 ?) et pour les
matériels PCI défectueux dès l'usine (ils ont été créés ainsi). Par exemple,
si un périphérique PCI sur l'IRQ 9 réclamait par erreur que toute IRQ 9
était pour lui, alors les autres périphériques utilisant l'IRQ 9 verraient
toutes leurs demandes d'interruption ignorées. Sans partage, ce problème est
évité.</para>
<para>Pour un exemple de partage d'une même IRQ entre deux périphériques
PCI, voir <link linkend="pci_irq_share">Partage d'interruption
PCI</link>. Cette capacité de partage est intégrée au matériel et tous
les pilotes de périphériques sont supposés la supporter. Notez que vous
ne pouvez pas habituellement partager la même interruption entre le bus
PCI et le bus ISA. </para>
</sect2>
<sect2><title>Recherche dans les tables de routage</title>
<para>Certaines informations sont fournies par les messages au démarrage. Elles
sont visibles grâce à l'outil <quote>dmesg</quote>. Les façons de rechercher les
tables impliquent du logiciel que vous pourriez ne pas avoir (ou qui n'existe
pas encore). Pour vérifier le routage qu'effectue PCI vers les 16 interruptions
ISA, utiliser <quote>pirtool</quote> qui affiche la table de routage $PIR. Si
vous avez un APIC avec un routage en dur (pas de PIR), utiliser
<quote>mptable</quote> pour rechercher dans la table MP. Pour un APIC routable,
des méthodes ACPI _PRT sont utilisables pour accéder à une table (mais je ne sais
pas si un outil en ligne de commande existe pour cela ?)</para>
</sect2>
<sect2><title>Pour plus d'informations</title>
<para>Des informations techniques détaillées sur les interruptions sont
disponibles, par exemple « <ulink
url="http://people.freebsd.org/~jhb/papers/bsdcan/2007/article/article.html">Les
interruptions PCI pour les machines x86 sous FreeBSD</ulink>. Microsoft a
un document intitulé « <ulink
url="http://www.microsoft.com/whdc/system/sysperf/apic.mspx">L'importance de
l'implémentation des sous-systèmes d'interruptions basées sur APIC sur les PC
mono-processeur"</ulink> ».</para>
<!--
However, such illegal sharing may work provided that the PCI device is
in use only one of the two conflicting devices is in use at any given
time. "In use" here means that a program has "opened" the device (and
hasn't "closed" it) in its C programming code, even though such a
program could be temporarily sleeping, etc.
-->
</sect2>
</sect1>
<sect1><title>Lier les interruptions PCI</title>
<para>Voici quelques détails sur le système d'interruptions PCI. Chaque carte
PCI (et les périphériques montés sur la carte-mère) a quatre interruptions
possibles : INTA#, INTB#, INTC#, INTD#. À partir de maintenant, nous les
appelerons simplement A, B, C et D. Chacune a sa propre broche sur le connecteur
d'une carte PCI. Donc, pour un système comprenant sept emplacements (pour sept
cartes), il pourrait y avoir 28 (7 x 4) différentes lignes d'interruption pour
ces cartes. Les périphériques intégrés à la carte-mère ont aussi des
interruptions supplémentaires. Mais les spécifications permettent un nombre plus
réduit de lignes d'interruption, donc certains bus PCI semblent n'avoir que
quatre ou huit lignes d'interruption. Ceci n'est pas trop restrictif car les
interruptions pourraient être partagées. Pour une ligne à quatre interruptions
(LNKA, LNKB, LNKC, LNKD), il y a un composant appelé <quote>routeur programmable
d'interruptions</quote> qui redirige LNKA, LNKB, LNKC, LNKD vers les IRQ
sélectionnées. Ce routage peut être modifié par le BIOS ou par Linux. Par
exemple, LNKA peut être routé vers l'IRQ 5. Supposons que nous désignons
l'interruption B de l'emplacement 3 comme l'interruption 3B. Les interruptions
3B et 2A pourraient être connectées de façon permanente à LNKA qui est routé
vers l'IRQ 5. Ces deux interruptions, 3B et 2A, sont partagées en permanence
par le cablage sur la carte-mère.</para>
<para>Saisir <command>dmesg</command> sur la ligne de commande permet
de voir comment les lignes d'interruption style LNKA sont redirigées (ou
routées) vers les IRQ (*5 signifie que c'est lié à l'IRQ 5). Recherchez
<foreignphrase>PCI Interrupt Link</foreignphrase>. Notez que <quote>link</quote>
est utilisé ici avec deux significations : 1. le lien (routage) des lignes
d'interruptions PCI vers les les IRQ, 2. le label d'une ligne d'interruption
comme LNKB (lien B). Les labels de la ligne d'interruption semblent être fournis
par le BIOS (??) et pourraient avoir des noms différents comme : LNKC,
LNK2, APCF, LUBA, LIDE, et cætera. Question : quand un grand nombre de lignes
d'interruption sont affichées comme étant désactivées, existent-elles toutes
physiquement sur la carte-mère ? ou existent-elles seulement dans la partie
ACPI du BIOS pour que ce dernier puisse fonctionner avec les cartes-mères qui
ont un grand nombre de lignes d'interruption ?</para>
<para>Connecter toutes les interruptions A (INTA#) à la ligne LNKA, toutes les
B à la ligne LNKB, et cætera. est une méthode simple pour connecter en dur ces
lignes des périphériques PCI (comme le 3B) aux interruptions LNKA, et cætera.
Cette méthode a été utilisée une fois plusieurs années auparavarant mais
ce n'est pas la bonne solution. Voici pourquoi. Si une carte a seulement besoin
d'une interruption, elle doit utiliser A. Si elle a besoin de deux interruptions,
elle doit utiliser A et B. Du coup, INTA# est utilisé bien plus fréquemment que
INTD#. Donc, on va se trouver avec un nombre excessif d'interruptions
partageant la première ligne (LNKA connecté à toutes les INTA#). Pour dépasser
ce problème, il vaut mieux les connecter de façon aléatoire pour que chacune
des quatre lignes d'interruptions (LNKA, LNKB, LNKC, LNKD) partagent à peu près
le même nombre d'interruptions PCI.</para>
<para>Une façon de le faire est de lier en dur LNKA avec les interruptions
1A, 2B, 3C, 4D, 5A, 6B, 7C. Ceci se fait en connectant physiquement le fil W
aux fils 1A, 2B, et cætera. De la même façon, le fil LNKB pourrait être connecté aux
fils 1B, 2C, 3D, 4A, 5B, 6C, 7D, et cætera. Puis, au démarrage, le BIOS dirige les LNKB,
LNKA, LNKC, LNKD aux IRQ. Après cela, il écrit l'IRQ que chaque périphérique
utilise dans un registre de configuration du matériel dans chaque périphérique.
À partir de maintenant, tout programme interrogeant ce registre peut savoir l'IRQ
utilisée par le périphérique. Notez qu'écrire simplement l'IRQ dans un registre
sur une carte PCI ne configure en aucun cas l'IRQ pour ce périphérique.</para>
<para>Une utilisation pratique de cette information est qu'en dernier ressort,
une personne pourrait modifier les IRQ d'une carte PCI en l'insérant dans un
emplacement différent. Dans l'exemple ci-dessus, INTA# d'une carte PCI sera
connecté au fil LNKA si la carte est insérée dans l'emplacement 1 (1A correspond
à LNKA) mais INTA# sera connecté au fil LNKB si elle est insérée dans
l'emplacement 4 (4A correspond à LNKB).</para>
<para>Une carte dans un emplacement pourrait avoir jusqu'à huit périphériques
mais il n'y a que quatre interruptions PCI pour elle (A, B, C, D). Cela suffit
car les interruptions pourraient être partagées pour que chacun des huit
périphériques (s'ils existent) puisse avoir une interruption partagée. La lettre de
l'interruption PCI d'un périphérique est souvent fixée et codée en dur dans le
périphérique. L'affectation des interruptions est réalisée par soit le BIOS ou
par Linux, établissant une correspondance entre les interruptions PCI et les
interruptions ISA comme mentionné ci-dessus.</para>
<para>S'il n'existe que quatre lignes (LNKA, LNKB, LNKC, and LNKD) comme dans
l'exemple ci-dessus, les choix de correspondance pour le BIOS sont limités.
Certaines cartes-mère peuvent utiliser plus de lignes et ont donc plus de choix.
Par exemple, de LNKA à LNKH (8 lignes). Les messages au démarrage
(<command>dmesg</command>) peuvent les afficher et indiquer leur
correspondance. Le BIOS sait comment elles sont câblées.</para>
<para>Sur le bus PCI, le BIOS (ou Linux) affecte des IRQ (interruptions) de
façon à éviter les conflits avec les IRQ qu'il sait affectés au bus ISA.
Quelque fois, le menu du CMOS du BIOS peut vous autoriser à affecter des IRQ
aux cartes PCI ou indiquer au BIOS les IRQ réservées aux périphériques ISA.
Les affectations sont connues sous le nom d'une table de routage. Sous MS
WIndows, c'est appelé <foreignphrase>IRQ steering</foreignphrase> mais cela
couvre aussi le cas d'un routage dynamique des IRQ après le démarrage. Le
BIOS peut supporter son propre <foreignphrase>IRQ steering</foreignphrase>.
</para>
<para>Si votre PC utilise les interruptions PCI qui sont renvoyées vers des
interruptions ISA, vous auriez le droit de penser que les interruptions seront
lentes étant donné que le bus ISA était lent. Pas vraiment. Le
composant de contrôle des interruptions ISA a un fil d'interruption direct le
reliant au CPU pour qu'il obtienne une attention immédiate. Bien que les signaux
sur les bus d'adresses et de données de l'ancien ISA sont lents pour arriver au
CPU, les signaux d'interruptions y arrivent rapidement.</para>
</sect1>
<sect1><title><acronym>PnP</acronym> pour les périphériques externes et
ajoutés</title>
<sect2><title>Bus <acronym>USB</acronym></title>
<para>L'USB (<foreignphrase>Universal Serial Bus</foreignphrase>, c'est-à-dire
Bus Universel Série) est un bus à grande vitesse sur un câble externe qui se
connecte au PC. Le bus externe a ses propres protocoles de communication et
n'utilise pas les <acronym>IRQ</acronym>, adresses d'entrées/sorties (ou tout
autre ressource bus) sur les câbles bus externes. La communication se fait par
paquets comme sur Internet, seulement sur des allocations de tranches de temps,
ce qui empêche un périphérique de manger le bus si d'autres périphériques en ont
besoin. Il existe des tranches de temps libre qui permettent à tout périphérique
d'envoyer un message court au contrôleur de bus sans avoir besoin des
<acronym>IRQ</acronym> sur le bus.</para>
<para>Néanmoins, le contrôleur de bus <acronym>USB</acronym> intégré au PC a une
<acronym>IRQ</acronym> et une adresse sur le bus <acronym>PCI</acronym> (ou
<acronym>ISA</acronym>), utilisées pour la communication entre le CPU et tous
les périphériques <acronym>USB</acronym>. Donc, il n'y a pas d'allocations de
ressources nécessaires pour les périphériques individuels sur le bus
<acronym>USB</acronym>. Vous pouvez aussi imaginer que tous les périphériques
sur le bus <acronym>USB</acronym> partagent la même interruption et la même
adresse. Si un périphérique est sur l'USB, il a besoin d'un pilote qui
comprenne l'USB.</para>
<para>Mais, chaque périphérique <acronym>USB</acronym> a un identifiant, comme
les cartes du bus <acronym>PCI</acronym>. Linux maintient donc une table des
identifiants de façon
à ce que les pilotes de périphérique puissent les vérifier et trouver ainsi leur
périphérique. L'USB supporte aussi le <quote>hot plug</quote>. Pour trouver ce
qui est placé sur le bus <acronym>USB</acronym>, vous pouvez utiliser un outil
généraliste de détection de matériel comme <command>discover</command> ou
<command>hwinfo</command>.</para>
</sect2>
<sect2><title>Hot Plug</title>
<para><quote>Hot plug</quote> correspond à la connexion d'un périphérique sur un
PC (habituellement avec un câble) et à sa détection immédiate. Si nécessaire, il
est configuré avec les ressources bus. Son pilote est aussi lancé, peut-être en
chargeant le module correspondant. Pour que ceci fonctionne, le matériel utilisé
doit être conçu de façon approprié. Vous pouvez utiliser cette fonctionnalité
avec certaines cartes <acronym>PCI</acronym> (Cardbus), périphériques
<acronym>USB</acronym> et <acronym>IEEE</acronym> 1394 (Firewire).</para>
<para>Lorsqu'un nouveau périphérique est détecté, ses registres sont lus de
façon à récupérer un numéro d'identifiant du périphérique. Pour trouver un
pilote, Linux doit maintenir une table réalisant la correspondance entre numéro
de périphérique et pilote. Cette table existe dans le noyau depuis la version
2.4. Elle est nommée MODULE_DEVICE_TABLE.</para>
</sect2>
<sect2><title>Hot Swap</title>
<para><quote>Hot Swap</quote> vous permet de remplacer un ancien périphérique
en l'enlevant et en branchant le nouveau. Vous avez donc interverti
(<foreignphrase>swapped</foreignphrase>) les périphériques. Maintenant, en plus
d'être capable de détecter le branchement d'un nouveau périphérique, la
suppression d'un ancien périphérique doit aussi être détectée.</para>
</sect2>
<sect2><title><acronym>PnP</acronym> détecte les périphériques connectés aux
ports séries</title>
<para>Les périphériques externes connectés par le port série via un câble (comme
les modems externes) sont aussi appelé Plug-and-Play. Comme seul le port série a
besoin de ressources bus (une <acronym>IRQ</acronym> et une adresse
d'entrées/sorties), il n'y a pas de ressources bus à allouer pour ces
périphériques. Dans ce cas, <acronym>PnP</acronym> est utilisé uniquement pour
l'identification du modem (lire le numéro/code du modèle). Ceci est important
dans le cas où ce modem est un modem logiciel (linmodem) et requiert un pilote
spécifique. Il existe une spécification <acronym>PnP</acronym> pour de tels
périphériques séries externes (quelque chose connecté au port série).</para>
<para>Linux ne supporte pas encore ceci ? Pour un modem matériel, le pilote
série
ordinaire suffira, donc il n'y a pas besoin de chercher un pilote avec
<command>serialpnp</command>. Vous devez toujours indiquer au programme de
communication sur quel port se trouve le modem. Avec <acronym>PnP</acronym>,
vous n'auriez même pas besoin de faire ça. Avec l'arrivée des modems logiciels
disposant de pilotes Linux (linmodem), il serait bien que les pilotes appropriés
s'installent automatiquement via <acronym>PnP</acronym>.</para>
</sect2>
</sect1>
<sect1><title>Messages d'erreurs</title>
<sect2><title>Unexpected Interrupt (Interruption inattendue)</title>
<para>Ceci signifie qu'une interruption est survenue alors qu'aucun pilote ne
l'attendait. Il est improbable que le matériel ait généré une interruption par
erreur. Il est plus probable que le logiciel comporte un petit bogue et n'a pas
réalisé qu'un logiciel a fait quelque chose qui a généré cette interruption.
Dans la plupart des cas, vous pouvez ignorer ce message en toute sécurité,
et tout particulièrement si cela n'est arrivé qu'une ou deux fois lors du
démarrage. Pour les messages du démarrage, regardez les messages qui lui sont
proches pour trouver une indication sur ce qui s'est passé. Par exemple, si
une recherche était en cours, il est possible que cela ait activé un
périphérique physique qui en retour a généré une interruption, interruption que
le pilote n'attendait pas. Le pilote n'écoutait peut-être pas le bon numéro
d'<acronym>IRQ</acronym>.</para>
</sect2>
<sect2><title>Erreur de configuration Plug and Play (<acronym>BIOS</acronym>
Dell)</title>
<para>Le <acronym>BIOS</acronym> a été incapable de configurer les ressources
bus. Il peut exister un conflit d'interruptions qui ne peut être évité. Dell
vous suggère que vous enleviez certaines des cartes non essentielles pour voir
si le problème disparaît. Dans un cas, le problème était dû à une carte mère
défectueuse.</para>
</sect2>
<sect2><title>isapnp: Write Data Register 0xa79 already used (à partir des
journaux)</title>
<para>Si vous utilisez isa-pnp, l'adresse d'entrées/sorties 0xa79 ne doit jamais
être utilisée par un périphérique, quel qu'il soit. Donc, si un autre matériel
utilise 0xa79 lorsque vous essayez de charger le module isa-pnp, vous obtiendrez
ce message dans vos journaux de trace et isa-pnp quittera. Une façon de corriger
cela est de charger le module isa-pnp bien plus tôt avant que tout autre
matériel ne soit initialisé. Pour le PCMCIA, ceci impose de charger isa-pnp
avant de lancer les modules cb et le service associé.</para>
</sect2>
<sect2>
<title>Impossible d'allouer la région (<acronym>PCI</acronym>)</title>
<para>Ici, <quote>région</quote> signifie un ensemble d'adresses. Un
périphérique <acronym>PCI</acronym> qui a besoin de deux régions aura la
région 0 comme première adresse et la région 1 pour deuxième adresse. Utilisez
la commande <command>lspci --v</command> pour voir les différentes régions
de ressources (souvent appelé régions) et si l'adresse est de type
entrée/sortie ou mémoire. Dans le jargon <acronym>PCI</acronym>, la région 2
est l'<quote>adresse de base 2</quote> (ou <quote>registre d'adresse de base
2</quote>), et cætera.</para>
</sect2>
</sect1>
<sect1>
<title>Partage et conflit d'interruption</title>
<sect2>
<title>Introduction</title>
<para>Quand deux périphériques ou plus utilisent la même ligne d'interruption,
(et le même numéro d'IRQ), il s'agit soit d'un <quote>partage
d'interruption</quote> soit d'un <quote>conflit d'interruption</quote>.
Le bus PCI autorise tous les périphériques PCI à partager des interruptions
avec les autres, ce qui est appelé le partage. Mais si un périphérique ISA
(ou un périphérique LPC ??) utilise la même interruption
(IRQ) qu'un autre périphérique (PCI, ISA ou LPC ??), il y habituellement
un conflit d'interruption.</para>
<para>Il existe des exceptions. Certains périphériques PCI très anciens
(pré-1995) ne permettent pas le partage d'interruption. À contrario, quelques
périphériques ISA ont été conçus pour partager les interruptions (entre deux
périphériques ISA ?) mais ces deux périphériques ISA doivent être conçus
de cette façon et être pilotés par du logiciel au courant du partage des
interruptions. La carte-mère doit aussi le supporter. La discussion suivante
se rapporte aux PC qui ont un bus ISA.</para>
<para>Un conflit signifie que, quand une interruption survient, aucun pilote de
périphérique (ou le mauvais) ne sera appelé. Cela peut aboutir à de mauvaises
actions comme des dépassements de tampon (perte de données). Un périphérique
peut presque immobiliser sa ligne d'interruption quand il n'envoie pas son
interruption, et de ce fait empêcher tout autre dispositif d'employer cette
ligne d'interruption. Cela ne pose pas de problème seulement si seul ce
périphérique utilise cette interruption mais si un deuxième périphérique essaie
d'utiliser la même ligne d'interruption, il ne pourra plus le faire. Si ce
second périphérique immobilise aussi la ligne lorsqu'il n'envoyait pas
d'interruption, alors aucun des deux périphériques ne peut utiliser
l'interruption. Linux et les deux périphériques sont inconscients de ce conflit
et continuent à envoyer les interruptions qui vont nul part et sont donc
perdus.</para>
<para>Les conflits d'interruptions étaient communs quand les IRQ étaient
configurées grâce à des cavaliers sur les cartes (bus ISA), souvent parce que
le noyau ne connaissait pas la configuration de ces cavaliers. Le Plug-and-Play
ISA (aucun cavalier) a beaucoup aidé car le logiciel pouvait modifier les
IRQ. L'abandon d'ISA en faveur du PCI a pratiquement éliminé les conflits
IRQ. Malgré tout, votre PC peut toujours avoir des périphériques sur la
carte-mère (pas sur une carte fille) sur un bus ISA, LPC ou X. Mais le BIOS et
le noyau devraient savoir comment les configurer et donc éviter de les utiliser
pour les périphériques PCI, évitant ainsi les conflits d'interruption.
Mais il existe toujours un problème avec PCI car il peut manquer d'interruptions
disponibles, tout spécialement sur les anciens PC qui ont seulement 16
interruptions.</para>
<para>Mais, bien qu'ayant éliminé le problème des conflits, le partage d'IRQ
sur le bus PCI a introduit un nouveau problème qui est moins sérieux, le problème d'équilibre des
IRQ. Si des périphériques utilisant beaucoup les interruptions partagent la
même IRQ, cela pourrait amener des délais dans la récupération des IRQ et
pourrait même amener à des dépassements de tampon et d'autres erreurs. Ceci
n'est pas dû à la façon dont le logiciel détermine le périphérique qui a
lancé cette interruption.</para>
<para>Il existe deux types de conflits d'interruptions. Le premier est un
vrai conflit, celui décrit ci-dessus. Dans ce cas, les interruptions ne
fonctionnent plus et le pilote de périphérique continue d'essayer de contrôler
son périphérique et ne sait pas que les interruptions ne fonctionnent pas. Le
second type de conflit d'interruption arrive quand un pilote de périphérique
est lancé mais découvre que l'interruption dont il a besoin est déjà utilisé.
Il affiche un message d'erreur et quitte. Le message indique quelque chose
comme « ressource en cours d'utilisation » (« ressource busy ») mais ne
précise pas clairement qu'il s'agit d'un problème d'interruption.</para>
</sect2>
<sect2><title>Vrai conflit d'interruption</title>
<para>Le BIOS et le noyau ne vont pas permettre un conflit d'interruptions en
connaissance de cause. Alors comment cela peut-il arriver ? Une façon
d'y parvenir arrive quand quelqu'un a indiqué un mauvais IRQ dans un fichier
de configuration, par exemple en donnant un paramètre « irq=9 » à un module.
Dans cet exemple, supposons que l'IRQ du périphérique est réellement le 5.
Quand un autre pilote de périphérique se lance et trouve son périphérique à
l'IRQ 5, vous avez deux vrai périphériques utilisant la même IRQ, ce qui
aboutit à un vrai conflit. Le noyau a approuvé l'utilisation de l'IRQ 5 par
le second périphérique car il a été trompé et pensait que le premier
périphérique était sur l'IRQ 9.</para>
<para>Il existe d'autres cas où le noyau ne sait pas qu'une IRQ est utilisée.
Par exemple quand une ancienne carte ISA est configuré par un cavalier mais
que son pilote n'est pas encore lancé (il peut même ne pas voir de pilote).
Un autre cas, le BIOS configure un IRQ au niveau matériel mais aucun pilote
Linux n'est lancé pour ce matériel. Linux ne connaîtra donc pas cette IRQ.
Ceci peut même arriver pour une carte PCI, celle-ci s'affichera avec la
commande <emphasis>lspci -v</emphasis> mais ne sera pas disponible dans le
répertoire <emphasis>/proc/interrupts</emphasis> et n'est donc pas connue par
le noyau. Est-ce un bogue du noyau ?</para>
<para>Quels sont les symptômes d'un conflit d'interruption ?
On pourrait penser que les périphériques ne fonctionnent pas du tout mais
comme les adresses sont connues, le pilote peut communiquer. Les interruptions
sont souvent utilisées pour contrôler le flux de données provenant et allant
au périphérique. Sans les interruptions, le flux n'est pas contrôlé, ce qui
signifie des dépassements de tampon, voire même pas de flux du tout, les
interruptions pouvant aussi être utilisées pour initier le flux. Pour un modem
série, le résultat est un flux extrêmement lent avec de longues pauses et des
erreurs fréquentes. Pour une carte son, cela pourrait signifier qu'un mot ou
deux sont entendus, puis plus rien.</para>
</sect2>
<sect2><title>Aucune interruption disponible</title>
<para>Ceci arrive quand un pilote de périphérique est lancé mais quitte
immédiatement pour éviter un conflit d'interruption. Généralement, il
affiche un message d'erreur comme « ressource en cours d'utilisation » ou
l'enregistre dans un journal de trace.</para>
<para>Un cas où un périphérique ISA est activé et ne peut se voir
affecté une interruption (IRQ) car aucune n'est disponible. Ou une
interruption pourrait être disponible mais ne peut pas être utilisée car
le matériel du périphérique qui a besoin de cette interruption ne sait
pas gérer le numéro disponible ou la carte mère ne le supporte pas non
plus à cause de problèmes de routage (voir <link linkend="pci_int">PCI
Interrupts</link>). Si les périphériques ISA utilisent toutes les
interruptions, alors une ou plusieurs cartes PCI pourraient être en
conflit car elles ne peuvent pas obtenir d'IRQ.</para>
<para>Normalement, le <acronym>BIOS</acronym> affectera des interruptions et ne
créera pas de conflits. Mais il pourrait être forcé de créer des conflits
s'il tombe à court d'<acronym>IRQ</acronym>. Ceci peut survenir si quelqu'un a
configuré le <acronym>BIOS</acronym> pour réserver certaines <acronym>IRQ</acronym>
pour les périphériques <acronym>ISA</acronym> qui ne sont pas
<acronym>PnP</acronym>. Ces paramétrages pourraient être mauvais et devraient
être vérifiés, tout spécialement si vous avez des problèmes. Par exemple,
quelqu'un pourrait avoir réservé une <acronym>IRQ</acronym> pour une carte
<acronym>ISA</acronym> qui a été enlevé du PC depuis longtemps. Si vous récupérez
cette <acronym>IRQ</acronym>, alors elle est disponible et un conflit disparaît.
</para>
<para>Quelque fois, le <acronym>BIOS</acronym> résoudra le problème du manque
d'<acronym>IRQ</acronym> en utilisant ce qu'il appelle l'<acronym>IRQ</acronym>
0. Elle n'existe pas car la vrai <acronym>IRQ</acronym> 0 est affectée en
permanence à l'horloge de l'ordinateur mais signifie que le pilote devrait
utiliser la demande au lieu des
<acronym>IRQ</acronym>. Ceci signifie que le pilote devra vérifier fréquemment
le périphérique (lui demander) pour voir si le périphérique a besoin d'un service
de la routine d'interruptions. Bien sûr, cela gâche du temps processeur et il y
a plus de risques d'un dépassement de tampon du périphérique
car il pourrait ne pas être servi assez rapidement par le pilote.</para>
</sect2>
</sect1>
<sect1><title>Annexe</title>
<sect2 id="UPnP_"><title>Universal Plug and Play
(<acronym>UPnP</acronym>)</title>
<para>C'est en quelque sorte un réseau Plug-and-Play développé par Microsoft
mais utilisable sous Linux. Vous connectez quelque chose sur un réseau et ce
quelque chose n'a pas besoin d'être configuré mais ne va communiquer qu'avec des
périphériques <acronym>UPnP</acronym> du réseau. Ici, <quote>configurer</quote>
est utilisé
dans le sens large et ne signifie pas simplement configurer les ressources bus.
Un des objectifs est de permettre au gens connaissant peu de choses sur les
réseaux ou sur la configuration et l'installation d'un routeur, d'une
passerelle, d'une imprimante réseau, et cætera de le faire. Une
utilisation majeure de <acronym>UPnP</acronym> serait dans les réseaux
sans-fil.</para>
<para><acronym>UPnP</acronym> utilise :
<itemizedlist>
<listitem><para>un protocole de découverte des services (<foreignphrase>Simple
Service
Discovery Protocol</foreignphrase>) pour trouver les
périphériques,</para></listitem>
<listitem><para>une architecture de notification générale d'événements
(<foreignphrase>General Event Notification
Architecture</foreignphrase>),</para></listitem>
<listitem><para>un protocole d'accès aux objets (<foreignphrase>Simple Object
Access
Protocol</foreignphrase>) pour assurer le contrôle des
périphériques.</para></listitem>
</itemizedlist>
</para>
<para>
Ce guide pratique ne couvre pas U<acronym>PnP</acronym>.
<acronym>UPnP</acronym> pour Linux est supporté par Intel qui a
développé un logiciel spécifique. Il existe d'autres programmes qui font
à peu près la même chose que <acronym>UPnP</acronym>. Une comparaison de
ceux-ci est disponible sur <ulink
url="http://www.cs.umbc.edu/~dchakr1/papers/mcommerce.html"/>. Un projet
U<acronym>PnP</acronym> pour Linux se trouve sur Sourceforge : <ulink
url="http://sourceforge.net/projects/upnp/">Kit U<acronym>PnP</acronym> pour
Linux</ulink>
</para>
</sect2>
<sect2 id="address_details"><title>Détails des adresses</title>
<para>Il existe trois types d'adresses : adresses en mémoire principale,
adresses
d'entrées/sorties (ports) et adresses de configuration. Sur le bus
<acronym>PCI</acronym>, les adresses de configuration constituent une plage
d'adresses séparée un peu comme les adresses d'entrées/sorties. Sauf dans le
cas compliqué des adresses de configuration <acronym>ISA</acronym>, qu'une
adresse sur le bus soit ou non une adresse en mémoire principale, une adresse
d'entrées/sorties ou une adresse de configuration dépend seulement du voltage
sur certains fils du bus. Pour plus de détails sur les adresses de configuration
du bus
<acronym>ISA</acronym>, voir <xref linkend="isa_conf_addresses"/>.</para>
<sect3><title>Plages d'adresses</title>
<para>Le terme <quote>adresse</quote> est quelque fois utilisé dans ce document
pour
signifier un ensemble contigu d'adresses. Les adresses sont en unité d'octets.
Donc, par exemple, un port série sur l'espace d'adressage 3F8-3FF sera souvent
juste référencé par son adresse de base, 3F8. 3F8 est l'emplacement du premier
octet de la plage (espace d'adressage). Pour visualiser les espaces d'adressage,
jetez un œil à <filename>/proc/iomem</filename> et
<filename>/proc/ioports</filename>.</para>
</sect3>
<sect3><title>Plage d'adresses</title>
<para>Pour accéder à la fois aux espaces d'adresses mémoire principale et
d'entrées/sorties, le même bus d'adresses est utilisé (les fils utilisés pour
l'adresse sont partagés). Comment le périphérique sait-il si l'adresse
apparaissant sur le bus est une adresse mémoire ou d'entrées/sorties ?
En fait, pour l'<acronym>ISA</acronym> (pour le <acronym>PCI</acronym>, lisez
aussi ceci), il existe quatre fils dédiés sur le bus
qui amènent ce type d'informations. Si un de ces quatre fils est
<quote>activé</quote>, cela indique que le <acronym>CPU</acronym> veut lire une
adresse
d'entrées/sorties et la mémoire principale ignore l'adresse sur le bus. En tout,
les fils de lecture et écriture existent à la fois pour les adresses de mémoire
principale et pour les adresses d'entrées/sorties (quatre fils en tout).</para>
<para>Pour le bus <acronym>PCI</acronym>, il s'agit de la même idée de
base (utilisant aussi quatre fils) mais réalisée un peu différemment. Au
lieu d'avoir un seul des quatre fils activé, un nombre binaire est placé
sur les fils (d'où 16 possibilités différentes). Donc, il est possible
de véhiculer plus d'informations sur ces quatres fils. Quatre de ces 16
nombres sont utilisés pour les espaces en mémoire principale et
d'entrées/sorties comme indiqué dans le paragraphe ci-dessus. En plus,
il existe aussi un espace d'adressage de configuration qui utilise plus
de deux chiffres supplémentaires. Cela laisse dix autres nombres
disponibles pour d'autres utilisations.</para>
</sect3>
<sect3>
<title id="pci_conf">Espace d'adresses pour la configuration
<acronym>PCI</acronym></title>
<para>Ceci est différent des espaces d'adresses mémoire et d'entrées/sorties
parce que l'espace d'adresses de configuration est <quote>géographique</quote>.
Chaque emplacement d'une carte a un numéro d'emplacement faisant parti de
l'adresse. De cette façon, Linux (ou le <acronym>BIOS</acronym>) peut
adresser un certain emplacement et trouver le type de carte fiché dans
cet emplacement. Chaque périphérique a des registres standards de 64 bits
et quelques uns d'entre eux contiennent des numéros qui peuvent identifier
de façon non ambiguë le périphérique. Comme le nombre d'emplacements est limité
comme le sont le nombre de périphériques <acronym>PCI</acronym> construit
dans la carte mère, Linux (ou le <acronym>BIOS</acronym>) a besoin de
vérifier un nombre limité d'adresses pour trouver tous les périphériques
<acronym>PCI</acronym>. S'il ne lit que des uns (0xFF en hexadécimal) à partir
du premier registre d'un périphérique, alors cela signifie qu'aucun périphérique
n'est présent. Comme il n'y a aucune carte ou périphérique fournissant tous les
numéros un (0xFF), le <quote>host bridge</quote> <acronym>PCI</acronym> sur la
carte mère fournit ce numéro pour tous les périphériques inexistants.</para>
<para>Le numéro d'emplacement <acronym>PCI</acronym> est appelé (dans le jargon
<acronym>PCI</acronym> le numéro de périphérique et comme une carte peut avoir
au plus huit périphériques sur elle, un numéro de fonction (allant de 0 à 7)
identifie le périphérique qui se trouve sur une carte <acronym>PCI</acronym>.
Ces numéros font partie de l'adresse géographique. Les développeurs Linux
l'appellent <foreignphrase>pci-slot-name</foreignphrase>. Du coup, ce que
Linux appelle un périphérique est en fait une fonction dans le jargon
<acronym>PCI</acronym>. Le numéro du bus <acronym>PCI</acronym> (souvent 00)
devient aussi une partie de l'adresse géographique. Par exemple,
0000:00:0d.2 correspond au bus <acronym>PCI</acronym> 0, emplacement 0, fonction
2. Pour l'adresse géographique complète, vous devez inclure le numéro sur deux
mots des registres de configuration du périphérique auquel on veut l'accès. Les
0000 en tête (en 1999) étaient réservés pour une utilisation future.</para>
<para>Comment le processeur désigne-t-il qu'une lecture ou une écriture doit
se faire dans l'espace de configuration <acronym>PCI</acronym> ? Il ne le
fait pas, en tout cas pas directement. À la place lorsque l'accès à l'espace de
configuration est désiré, il fait une écriture sur 32 bits (un mot double) pour
écrire 0cf8-0cfb en espace d'entrées/sorties et écrit l'adresse géographique
complète ici. Le <foreignphrase>host bridge</foreignphrase> <acronym>PCI</acronym>
écoute à cette adresse et nous assure que la prochaine écriture de données sera
0cfc-0cff. C'est enregistré dans des registres de configuration du périphérique
spécifié. Le pont fait les deux en envoyant un signal spécial à la carte
<acronym>PCI</acronym> spécifiée (ou ce qui y ressemble) sur un fil dédié qui va
seulement à l'emplacement où la carte est connectée. Il place aussi des bits sur
le bus de contrôle indiquant que ce qui est sur le bus d'adresse maintenant est
une adresse géographique de l'espace de configuration.</para>
<para>Pourquoi ne pas faire simple et demander simplement au processeur de
placer les
bits sur le bus de contrôle pour indiquer que l'adresse sur le bus principal est
une adresse géographique pour la configuration du <acronym>PCI</acronym> ?
Et bien, la plupart des processeurs ne sont pas capables de le faire donc le
<quote>host bridge</quote> <acronym>PCI</acronym> le fait à la place.</para>
</sect3>
<sect3><title>Vérification de la plage (test <acronym>ISA</acronym> pour les
conflits d'adresses d'entrées/sorties)</title>
<para>Sur le bus <acronym>ISA</acronym>, il existe une méthode intégrée dans
chaque carte <acronym>PnP</acronym> pour vérifier qu'aucune autre carte n'utilise
la même adresse d'entrées/sorties. Si deux cartes ou plus utilisent la même
adresse d'entrées/sorties, les cartes ont peu de chance de fonctionner
correctement (voire de fonctionner tout court). Un bon logiciel
<acronym>PnP</acronym> devrait allouer les ressources bus de manière à éviter
ce conflit, mais même dans ce cas, une carte non <acronym>PnP</acronym>
pourrait avoir la même adresse.</para>
<para>Le test fonctionne par une carte plaçant un nombre de test connu dans ses
propres registres d'entrées/sorties. Puis, le logiciel <acronym>PnP</acronym>
le lit et vérifie que ce qu'il lit correspond bien au numéro de test connu. Il
répète le même test avec un autre numéro. Comme il vérifie l'ensemble des adresses
d'entrées/sorties allouées à la carte, il est appelé un vérificateur de plage.
Il pourrait être appelé plus logiquement un testeur de conflit d'adresses. Si un
conflit est détecté, vous obtenez un message d'erreur.</para>
</sect3>
<sect3><title>Communiquer directement via la mémoire</title>
<para>Traditionnellement, la plupart des périphériques d'entrées/sorties
utilisent seulement la mémoire d'entrées/sorties pour communiquer avec le
processeur (<acronym>CPU</acronym>). Le pilote de périphérique, exécuté sur le
processeur lira et écrira des données de/vers l'espace d'adressage des
entrées/sorties et la mémoire principale. Malheureusement, cela nécessite deux
étapes. Par exemple, 1. lire les données à partir d'un périphérique (en espace
d'adressage) et les stocker temporairement dans le CPU ; 2. écrire ces données
en mémoire principale. Une façon plus rapide serait que le périphérique place
lui-même les données directement en mémoire principale. Une façon de faire ceci
est d'utiliser <xref linkend="dma_"/> <acronym>ISA</acronym> ou la maîtrise
du bus <acronym>PCI</acronym>. Le périphérique physique peut aussi détenir un
peu de mémoire principale (aux adresses supérieures pour éviter
les conflits avec les adresses des composants de la mémoire principale). De
cette façon, le périphérique lit et écrit directement dans son espace mémoire
interne sans avoir à s'embêter avec le <acronym>DMA</acronym> ou la maîtrise
du bus. De tels périphériques pourraient aussi utiliser des adresses
d'entrées/sorties.</para>
</sect3>
</sect2>
<sect2 id="isa_conf_addresses"><title>Adresses de configuration du bus
<acronym>ISA</acronym> (Port de lecture et cætera)</title>
<para>Ces adresses sont aussi connues comme les <quote>ports
d'auto-configuration</quote>.
Pour le bus <acronym>ISA</acronym>, il n'existe pas techniquement de plage
d'adresses de configuration, mais le <acronym>CPU</acronym> utilise une façon
spéciale d'accéder aux registres de configuration <acronym>PnP</acronym> sur
les cartes <acronym>PnP</acronym>. Dans ce but, trois adresses
d'entrées/sorties sont allouées et chacune adresse un seul octet (il n'y a pas
à proprement parler d'espace ou de plage). Il ne s'agit pas de trois adresses
pour chaque carte mais de trois adresses partagées par toutes les cartes
<acronym>ISA</acronym>-<acronym>PnP</acronym>.</para>
<para>Ces trois adresses sont nommées port de lecture
(<foreignphrase>read-port</foreignphrase>), port d'écriture
(<foreignphrase>write-port</foreignphrase>) et port d'adresse
(<foreignphrase>address-port</foreignphrase>). Chaque port a une taille
d'un octet. Chaque carte <acronym>PnP</acronym> dispose d'un grand
nombre de registres de configuration, donc même les trois adresses ne
sont pas suffisantes pour les registres de configuration d'une seule
carte. Pour résoudre ce problème, chaque carte se voit affecter un
numéro de carte en utilisant une technique appelée
<quote>isolation</quote>. Voir <xref linkend="isolation_"/> pour des
détails plus complexes.</para>
<para>Ensuite, pour configurer une certaine carte, son numéro de carte est
envoyé via l'adresse du port d'écriture pour indiquer à cette carte qu'elle doit
écouter sur son port d'adresse. Toutes les autres cartes notent que ce n'est pas
leur numéro de carte et donc n'écoutent pas. Ensuite, l'adresse d'un registre de
configuration est envoyé sur le port d'adresse (à toutes les cartes, mais une
seule écoute). Enfin, le transfert de données prend place avec ce registre de
configuration sur cette carte soit en faisant une lecture sur le port de lecture
soit en faisant une écriture sur le port d'écriture.</para>
<para>Le port d'écriture est toujours A79 et le port d'adresse est toujours 279
(en hexadécimal). Le port de lecture n'est pas fixe mais dépend du logiciel de
configuration (tout en restant dans la plage 203-3FF) qui avec un peu de chance
n'entrera pas en conflit avec les autres cartes <acronym>ISA</acronym>. Si un
conflit se déclare, il changera l'adresse. Toutes les cartes
<acronym>PnP</acronym> sont <quote>programmées</quote> avec cette adresse. Donc,
si vous
utilisez <command>isapnp</command> pour enregistrer ou connaître la
configuration, celui-ci doit d'abord déterminer l'adresse du port de lecture.
</para>
</sect2>
<sect2 id="interrupt_detail"><title>Détails sur les interruptions</title>
<sect3><title>Interruptions sérialisées</title>
<para>Il a été dit précédemment qu'il existe un fil pour chaque interruption.
Mais l'interruption sérialisée (ou interruption série) est une exception. Un
seul fil est utilisé pour toutes les interruptions qui sont multiplexées sur
ce fil. Chaque interruption a un créneau horaire sur la ligne d'interruption.
Il est utilisé sur le bus LPC mais aussi sur le bus PCI bien que cela soit plus
rare pour ce dernier ?</para>
</sect3>
<sect3><title><acronym>DMA</acronym></title>
<para>Avant de se plonger dans le détail des interruptions, il existe
une autre façon pour que les périphériques initient la communication en
dehors de l'envoi d'une interruption. Cette méthode est une requête
<acronym>DMA</acronym>
(<foreignphrase>Direct Memory Access</foreignphrase>) pour prendre le contrôle
de l'ordinateur à partir du CPU pour un temps limité. Sur le bus
<acronym>PCI</acronym>, il
n'utilise aucune ressource. Tous les périphériques ne sont pas capables de
faire du <acronym>DMA</acronym>. Voir <xref linkend="dma_"/>.</para>
</sect3>
<sect3><title>Interruptions logicielles</title>
<para>Il existe aussi un autre type d'interruption nommée <quote>interruption
logicielle</quote>, non couverte par ce guide pratique et n'utilisant pas de
ressources. Alors qu'une interruption matérielle est générée par le matériel,
une interruption logicielle est initiée par le logiciel. Il existe plusieurs
façons pour ce faire. Une façon est que le logiciel dise au processeur
d'exécuter une interruption (une instruction d'interruption). Une autre façon
consiste, pour le logiciel, à envoyer des messages aux autres processus pour
les interrompre même s'il n'est pas clair qu'on puisse appeler ça une
interruption. Le processus ksoftirq process, que vous pouvez trouver dans la
liste des processus sur un PC Linux, est un programme qui lance ce type
d'interruption pour gérer les pilotes de périphériques. Le pilote de
périphérique commence à s'exécuter à cause d'une interruption matérielle mais,
plus tard, des interruptions logicielles sont utilisées pour la deuxième moitié
de la routine d'interruption du pilote. Donc, le processus ksoftirq est aussi
connu comme la <quote>seconde moitié</quote>. Pour plus de détails, voir la
documentation du noyau.</para>
</sect3>
<sect3><title>Interruptions matérielles</title>
<para>Les interruptions amènent beaucoup d'informations mais seulement
indirectement. Le signal de demande d'interruption (un voltage sur un fil)
envoyé par un matériel
indique seulement au composant, appelé le contrôleur d'interruption, qu'un
certain périphérique demande l'attention. Le contrôleur d'interruption envoie
le signal au <acronym>CPU</acronym>. Le <acronym>CPU</acronym> s'interrompt
dans ce qu'il faisait, trouve le pilote de ce périphérique et exécute une
partie de celui-ci nommée <quote>routine d'interruption</quote> (ou
<quote>gestionnaire
d'interruption</quote>). Cette <quote>routine</quote> essaie de trouver ce qui
est arrivé et gère
ensuite le problème. Par exemple, le périphérique peut avoir besoin
d'envoyer/recevoir des octets. Ce programme (cette routine) peut
facilement comprendre ce qui s'est passé car le périphérique dispose de
registres disponibles sur des adresses connues par le pilote (à condition que
le numéro d'<acronym>IRQ</acronym> et que les adresses d'entrées/sorties
soient correctement configurés). Ces registres contiennent l'état du
périphérique. Le logiciel lit le contenu de ces registres et en inspectant le
contenu, trouve ce qui est arrivé et réalise l'action appropriée.</para>
<para id="pci_irq_share">Donc, chaque pilote de périphérique a besoin de savoir
le numéro d'interruption (<acronym>IRQ</acronym>) où écouter. Sur le bus
<acronym>PCI</acronym> (et dans certains cas spéciaux, sur le bus
<acronym>ISA</acronym>), il est possible que deux (voire plus) périphériques
partagent le même numéro d'<acronym>IRQ</acronym>. Notez que vous ne pouvez pas
partager une interruption <acronym>PCI</acronym> avec une interruption
<acronym>ISA</acronym> (y a-t'il des exceptions ?). Quand une interruption
partagée est lancée, le processeur exécute toutes les routines du service
d'interruption séquentiellement pour tous les périphériques utilisant cette
interruption. La première action qu'entreprend la première routine lancée est
de vérifier les registres du périphérique pour voir si une interruption a été
générée par son périphérique. S'il se trouve que ce n'est pas le cas (fausse
alarme), il s'arrêtera immédiatement et la prochaine routine commence pour le
deuxième périphérique qui utilise cette même interruption, et cætera. Il vérifie le
périphérique comme décrit ci-dessus. Cette séquence est répétée jusqu'à la
découverte du périphérique qui a lancé cette interruption. Toutes les routines
d'interruption pour une interruption constituent une chaîne. Donc, la chaîne
est traversée jusqu'à ce qu'une routine de la chaîne réclame l'interruption en
disant : cette interruption est pour moi. Après avoir géré l'interruption,
les routines suivantes du service d'interruption ne sont pas exécutées.</para>
<para>Mettre un certain voltage sur une ligne <acronym>IRQ</acronym> revient
seulement à demander que le <acronym>CPU</acronym> s'interrompe de façon à
exécuter la routine du pilote du périphérique. Dans pratiquement tous les cas,
le <acronym>CPU</acronym> est interrompu par la requête. Mais les interruptions
du CPU peuvent être temporairement désactivées ou <quote>faire la queue</quote>, et
donc, dans de rares cas, une interruption peut ne pas être gérée (ou peut subir
un certain délai). Donc, ce qui a été auparavant appelé une interruption est plus
précisément une <quote>demande d'interruption</quote>, ce qui explique
l'acronyme d'<acronym>IRQ</acronym> (<quote>Interrupt ReQuest</quote>,
c'est-à-dire ReQuête d'Interruption).</para>
</sect3>
</sect2>
<sect2><title>Comment le pilote de périphérique récupère son
interruption</title>
<para>L'indication précédente, à savoir que les pilotes de périphérique
écoutent leur interruption, était une explication très simplifiée.
En fait, il s'agit d'un composant (ou d'une partie d'un composant) embarqué
sur la carte-mère, appelé le contrôleur d'interruptions. Il va écouter toutes
les interruptions. Quand le contrôleur récupère une interruption, il envoie
un signal au CPU pour lancer la routine du service d'interruption du pilote
de périphérique approprié pour gérer cette interruption.</para>
<para>Il existe différents types de contrôleurs d'interruptions. L'un d'entre
eux est l'APIC (acronyme de Advanced Programmable Interrupt Controller) qui a
habituellement des broches en entrée pour un grand nombre d'interruptions, y compris les interruptions
PCI. Les anciens contrôleurs ont seulement des broches pour les interruptions
ISA mais ils peuvent toujours gérer les interruptions PCI car il s'agit d'un
routeur programmable d'interruptions qui convertit les interruptions PCI en
interruptions ISA et les envoie vers certaines broches (c'est-à-dire vers
certaines IRQ).</para>
</sect2>
<sect2 id="isolation_"><title>Isolation <acronym>ISA</acronym></title>
<para>C'est uniquement pour l'ancien bus <acronym>ISA</acronym>. L'isolation est
une méthode complexe d'affectation d'un point temporaire (numéro
d'identifiant ou <acronym>CSN</acronym>, <foreignphrase>Card Select
Number</foreignphrase>) à chaque périphérique <acronym>PnP</acronym> du bus
<acronym>ISA</acronym>. Comme il existe des moyens plus efficaces (mais plus
complexes) de le faire, certains pourraient dire qu'il s'agit d'une méthode
simple. Seule une adresse d'écriture est utilisée pour les écritures
<acronym>PnP</acronym> vers tous les périphériques pour que toutes les
écritures vers cette adresse aillent sur tous les périphériques
<acronym>PnP</acronym>. Cette adresse d'écriture est utilisé pour envoyer
(affecter) un numéro de carte unique à chaque périphérique
<acronym>PnP</acronym>. Pour
être assigné, ce numéro de carte nécessite qu'un seul périphérique soit en
écoute
lorsque le numéro de carte est envoyé (écrit) à cette adresse commune. Tous les
périphériques <acronym>PnP</acronym> ont un numéro de série unique qu'ils
utilisent lors du processus d'isolation. Faire l'isolation est comme un jeu.
Cela se fait en utilisant l'équivalent d'un bus commun de fils connectant tous
les périphériques <acronym>PnP</acronym> au programme d'isolation.</para>
<para>Pour le premier tour du <quote>jeu</quote>, tous les périphériques
<acronym>PnP</acronym> écoutent sur ce fil et envoient simultanément une
séquence de bits sur le fil. Les bits autorisés sont soit un 1 (voltage positif)
soit un <quote>0 ouvert</quote> sans voltage (circuit ouvert ou trois-états).
Pour cela,
chaque périphérique <acronym>PnP</acronym> commence à envoyer séquentiellement
son numéro de série sur ce fil, voltage (circuit ouvert ou trois-états). Pour
faire cela, chaque périphérique <acronym>PnP</acronym> lance simplement son
numéro de série sur les fils, bit à bit, en commençant par le plus haut. Si
un périphérique envoie un 1, un 1 sera entendu par tous les autres
périphériques. Si tous les périphériques envoient un <quote>0 ouvert</quote>,
rien ne sera
entendu sur le fil. Le but est d'éliminer (à la fin du premier tour) tous les
périphériques sauf celui possédant le numéro de série le plus important.
<quote>Éliminer</quote> signifie enlever de ce tour du jeu et donc cesser
temporairement d'écouter tout ce qui passe sur le fil. (Notez que tous
les numéros de série ont la même taille.) Quand il ne reste qu'un seul
périphérique en écoute, un numéro de carte lui est donné.</para>
<para>Tout d'abord, considérez seulement le bit le plus haut du numéro de
série qui est placé sur le fil par tous les périphériques qui n'ont pas encore
de numéro de carte. Si un périphérique <acronym>PnP</acronym> envoie un 0 (0
ouvert)
mais entend un 1, cela signifie qu'un ou plusieurs autres périphériques
<acronym>PnP</acronym> a un numéro de série plus important, donc il se supprime
temporairement pour ce tour. Maintenant, les périphériques restant en jeu (pour
ce tour) ont tous le même bit de haut niveau (un 1), donc nous pouvons
supprimer ce bit et continuer avec le <quote>reste du numéro de série</quote>
pour la suite
du tour. Ensuite, recommencez depuis le début de ce paragraphe et répétez
jusqu'à ce que le numéro de série soit examiné en entier pour chaque
périphérique (voir plus bas pour les cas <quote>tous à 0</quote>).</para>
<para>Donc, il est clair que seules les cartes avec un petit numéro de série
sont éliminées lors d'un tour. Mais qu'arrive-t-il si tous les périphériques
du jeu envoient un 0 comme leur bit de haut niveau ? Dans ce cas, un
<quote>0 ouvert</quote>
est envoyé sur la ligne et tous les participants restent en lice. S'ils ont
tous un 0 au début, alors les 0 sont supprimés comme les 1 du paragraphe
ci-dessus. Le jeu continue alors avec le bit suivant du numéro de série).</para>
<para>A la fin du tour (après que le dernier bit ait été envoyé), seul un
périphérique <acronym>PnP</acronym>, celui possédant le plus haut numéro de
série, reste en jeu. Il se voit attribuer un numéro de carte et quitte le jeu
définitivement. Ensuite, tous les autres périphériques du tour précédent (qui
n'ont donc pas de numéro de carte) reviennent dans le jeu et un nouveau tour
commence,
avec un participant en moins. Éventuellement, tous les périphériques
<acronym>PnP</acronym> se voient assigner un numéro de carte. Il est facile de
prouver
que cet algorithme fonctionne. L'algorithme actuel est un peu plus complexe
que celui présenté ci-dessus car chaque étape est répétée deux fois pour
s'assurer, et ces répétitions sont faites d'une façon un peu différente (mais
en utilisant la même idée de base).</para>
<para>Une fois tous les numéros de carte assignés, ils sont utilisés pour
s'adresser à
chaque périphérique <acronym>PnP</acronym> pour envoyer/lire des données de
configuration. Notez que ces numéros de carte sont seulement utilisés pour la
configuration <acronym>PnP</acronym> et ne sont pas utilisés pour les
communications normales avec le périphérique <acronym>PnP</acronym>. Lorsque
l'ordinateur démarre, un <acronym>BIOS</acronym> <acronym>PnP</acronym> fera
l'isolation puis s'occupera de la configuration <acronym>PnP</acronym>. Après
ça, tous les numéros de carte sont <quote>perdus</quote> d'une telle façon que
si quelqu'un veut
changer (ou inspecter) la configuration une nouvelle fois, l'isolation devra
être refaite intégralement.</para>
</sect2>
<sect2><title>Maîtrise du bus et ressources <acronym>DMA</acronym></title>
<para>Si un bus dispose d'une fonctionnalité de maîtrise du bus, il est peu
probable que des ressources seront nécessaires pour le <acronym>DMA</acronym>
sur ce bus. Par exemple, le bus <acronym>PCI</acronym> n'a pas besoin des
ressources <acronym>DMA</acronym> car il dispose de cette fonctionnalité.
Néanmoins, la <quote>maîtrise du bus</quote> est souvent appelée
<acronym>DMA</acronym>. Mais, comme il ne s'agit pas strictement de
<acronym>DMA</acronym>, il ne nécessite aucune ressource <acronym>DMA</acronym>.
Les bus locaux <acronym>ISA</acronym> et VESA n'ont pas de maîtrise du bus. Les
anciens bus MCU et E<acronym>ISA</acronym> l'avaient.</para>
</sect2>
<sect2><title>Historique et obsolescence</title>
<sect3><title>Pilote son OSS-Lite</title>
<para>Vous devez donner l'adresse d'entrée/sortie, l'<acronym>IRQ</acronym> et
le canal <acronym>DMA</acronym> comme paramètres au module ou les compiler dans
le noyau. Mais certaines cartes <acronym>PCI</acronym> seront automatiquement
détectées. RedHat fournit un programme <command>sndconfig</command> qui détecte
les cartes <acronym>ISA</acronym> <acronym>PnP</acronym> et configure
automatiquement les modules en chargeant les ressources bus détectées.</para>
</sect3>
<sect3>
<title>ALSA (Architecture son avancée pour Linux) en l'an 2000</title>
<para>Ceci détectera la carte par des méthodes <acronym>PnP</acronym>, puis
sélectionnera le pilote et le chargera. Il configurera aussi les ressources
bus sur les cartes <acronym>ISA</acronym>-<acronym>PnP</acronym> et sur les
cartes <acronym>PCI</acronym>. Il remplace <acronym>OSS</acronym> (Open Sound
System), auparavant populaire.</para>
</sect3>
<sect3><title>Notes sur MS Windows Notes</title>
<para>Windows NT4 ne supportait pas <acronym>ISAPNP</acronym> mais dispose d'
un programme <acronym>PNPISA</acronym> que vous pouvez utiliser <quote>à vos
risques et périls</quote>. Pour NT4, les utilisateurs se sont vus conseiller de
ne pas configurer le <acronym>BIOS</acronym> avec l'indication que le système
d'exploitation est <acronym>PnP</acronym> de façon à ce que le
<acronym>BIOS</acronym> s'occupe de la configuration des ressources. Du coup,
MS Windows et Linux étaient auparavant dépendants de la configuration du
<acronym>BIOS</acronym> (et le sont toujours).</para>
</sect3>
</sect2>
</sect1>
<appendix>
<title>Adaptation française</title>
<section>
<title>Traduction</title>
<para>
La traduction française de ce document a été réalisée par Guillaume
Lelarge
<email>gleu CHEZ wanadoo POINT fr</email>.
</para>
</section>
<section>
<title>Préparation de la publication</title>
<para>
La publication de ce document a été préparée par Jean-Philippe Guérard
<email>fevrier CHEZ tigreraye POINT org</email>.
</para>
</section>
</appendix>
</article>
