En cas de problèmes avec PCMCIA sur certains ordinateurs portables ou avec
certaines cartes, vous réglerez la plupart de ces difficultés assez
facilement, dans la mesure où vous traiterez toujours le problème de
manière systématique. Tout d'abord, il faut déterminer si le problème
vient de la carte ou s'il s'agit d'un problème au niveau du système de base
PCMCIA. Vous devez donc, dans tous les cas, commencer par démarrer
l'ordinateur sans que la carte ne soit insérée. Ce n'est que quand le
système de base fonctionnera apparemment sans problème que vous pourrez
réinsérer la carte. Tous les messages sont enregistrés dans le fichier
journal /var/log/messages. Vous devez
donc particulièrement surveiller ce fichier avec
tail -f /var/log/messages pendant
les tests. Ainsi l'erreur se limite à l'un des deux cas suivants.
Lorsque le système reste bloqué lors de l'amorçage dès le message
PCMCIA: Starting services (démarrage des services)
ou que d'autres choses surprenantes se produisent, vous pouvez empêcher le
démarrage de PCMCIA lors du prochain amorçage en saisissant
NOPCMCIA=yes à l'invite d'amorçage. Pour limiter
encore plus le risque d'erreur, chargez ensuite les trois modules de base du
système PCMCIA utilisé, l'un après l'autre, manuellement.
Pour charger un module PCMCIA manuellement, utilisez, les commandes
modprobe pcmcia_core,
modprobe yenta_socket et
modprobe ds en tant qu'utilisateur
root. Dans quelques rares cas,
l'un des modules tcic, i82365 ou
i82092 doit être utilisé à la place de
yenta_scoket. Les modules critiques sont les deux premiers
chargés.
Si l'erreur survient lors du chargement de pcmcia_core,
reportez-vous à la page de manuel de pcmcia_core(4).
Les options qu'elle décrit peuvent tout
d'abord être testées avec la commande modprobe. Nous
pouvons, à titre d'exemple, utiliser la vérification de domaines d'E/S (I/O)
libres. Cette vérification isolée peut poser un problème si d'autres
composants matériels s'en trouvent perturbés. On peut éviter ce problème
à l'aide de l'option probe_io=0 :
modprobe pcmcia_core probe_io=0
Si l'option sélectionnée donne satisfaction, attribuez la valeur
probe_io=0 à la variable
PCMCIA_CORE_OPTS dans le fichier
/etc/sysconfig/pcmcia. Si vous souhaitez utiliser
plusieurs options, séparez-les par des espaces :
PCMCIA_CORE_OPTS="probe_io=0 setup_delay=10"
Une erreur lors du chargement du module yenta_socket
signifie un problème fondamental, tel que, par exemple, la répartition des
ressources par ACPI.
Les fichiers /etc/pcmcia/config et
/etc/pcmcia/config.opts sont exploités par le
gestionnaire de cartes. Les réglages qu'ils contiennent sont utiles en
partie lors du démarrage de cardmgr et en partie
lors du chargement des modules pilotes pour les cartes PC.
Vous pouvez aussi inclure ou exclure des IRQ, des ports d'E/S et des domaines
mémoire dans le fichier /etc/pcmcia/config.opts. Dans
quelques cas rares, l'accès à un mauvais domaine d'E/S peut planter tout
le système. Dans ce cas, limiter en partie le domaine peut résoudre le
problème.
Il existe à ce sujet essentiellement trois variantes d'erreur : la carte n'est pas reconnue, le pilote ne peut pas être chargé ou le port préparé par le pilote a été mal configuré. Vous devez vérifier si la carte est traitée par le gestionnaire de cartes ou par hotplug. Le gestionnaire de cartes gère les cartes PC Card et hotplug les cartes CardBUS.
Lorsque le système ne réagit pas à l'insertion d'une carte et que
même la saisie manuelle de cardctl insert
ne provoque aucune réaction, l'attribution des interruptions
aux périphériques PCI n'est peut-être pas correcte. Souvent, d'autres
périphériques PCI que la carte réseau ont des problèmes. Dans ce cas,
le paramètre d'amorçage pci=noacpi ou d'autres
paramètres PCI ou ACPI peuvent être utile.
Si la carte n'est pas détectée, le message unsupported Card in
Slot x apparaît dans le fichier
/var/log/messages. Ce message indique seulement que
le gestionnaire de cartes ne peut associer aucun pilote à la carte. Les
fichiers /etc/pcmcia/config ou
/etc/pcmcia/*.conf sont nécessaires pour réaliser
cette attribution. Ces fichiers sont, pour ainsi dire, la base de
données des pilotes. Cette base de données de pilotes peut facilement
être complétée en prenant ses entrées existantes comme modèle.
Vous pouvez utiliser la commande
cardctl ident pour découvrir
la manière dont la carte s'identifie. Vous trouverez plus d'informations
à ce sujet dans le HOWTO PCMCIA (section 6) et dans la page de
manuel de pcmcia(5). Une fois le fichier
/etc/pcmcia/config ou
/etc/pcmcia/*.conf modifié, l'attribution des
pilotes doit à nouveau être chargée ; cela se fait à l'aide de
la commande rcpcmcia reload .
L'une des raisons de ce type de problème est qu'une mauvaise attribution est enregistrée dans la base de données des pilotes. Cela peut, par exemple, être dû au fait qu'un fabricant a intégré une autre puce dans un modèle de carte apparemment non modifié. Parfois, il existe aussi d'autres pilotes qui fonctionnent mieux sur certains modèles que le pilote réglé par défaut (ou qui sont même les seuls à fonctionner d'ailleurs). Dans ces cas, vous avez besoin d'informations précises au sujet de la carte. Vous pouvez aussi obtenir de l'aide sur une liste de discussion ou en contactant le service d'assistance avancé (en anglais, Advanced Support Service).
Pour les cartes Cardbus, il faut saisir l'entrée
HOTPLUG_DEBUG=yes dans le fichier
/etc/sysconfig/hotplug. On obtient alors des
messages dans le journal du système qui indique si le pilote a été
chargé (avec succès).
Une autre raison peut être un conflit de ressources. Pour la plupart des
cartes PCMCIA, l'IRQ, le port d'E/S ou le domaine mémoire avec lesquels
elles sont exploitées n'ont aucune importance, mais il peut y avoir des exceptions.
Il convient donc de ne tester qu'une seule carte à la fois et
d'interrompre momentanément les autres composants système tels que, par
exemple, les cartes son, l'IrDA, le modem ou l'imprimante.
Vous pouvez, en tant qu'utilisateur
root, consulter la répartition
des ressources du système à l'aide de la commande
lsdev. Il est absolument normal que plusieurs
appareils PCI utilisent le même IRQ.
Une solution possible consiste à trouver une option appropriée pour le
module du pilote de la carte à l'aide de modinfo
pilote.
La plupart des modules ont une page de manuel qui leur est consacrée.
rpm -ql pcmcia | grep
man
énumère toutes les pages de manuel du paquetage
pcmcia. Pour tester les
options, les pilotes des cartes peuvent aussi être déchargés à la
main.
Lorsque vous avez trouvé une solution,
vous pouvez autoriser ou interdire l'utilisation d'une ressource
particulière de manière universelle dans le fichier
/etc/pcmcia/config.opts. Les options pour les
pilotes de cartes peuvent également être entrées dans ce fichier. Si,
par exemple, le module pcnet_cs doit exclusivement
être exploité avec l'IRQ 5, saisissez l'entrée suivante :
module pcnet_cs opts irq_list=5
Dans ce cas, nous vous conseillons de vérifier à nouveau la
configuration de l'interface et le nom de la configuration à l'aide de
getcfg pour exclure toute erreur de configuration
éventuelle. À cette fin, attribuez la valeur yes aux
variables DEBUG et
HOTPLUG_DEBUG
dans les fichiers respectifs
/etc/sysconfig/network/config et
/etc/sysconfig/hotplug. Pour les autres cartes ou si
cette modification n'est d'aucun secours, vous pouvez encore ajouter la ligne
set -vx
dans le script exécuté par le gestionnaire de cartes ou par hotplug
(reportez-vous à /var/log/messages). Cela permet d'ordonner
que chaque commande du script soit systématiquement enregistrée dans le
journal du système. Si vous avez détecté le point critique dans un
script, vous pouvez aussi saisir les commandes correspondantes dans un
terminal et les y tester.