Fichier:Acpi.jpg

2006-06-11T20:31:15Z

Ennael :

Découvrez les ressources de votre machine (La suite)

2006-06-11T20:30:44Z

Ennael : /* APIC es tu là ? */

= Découvrez les ressources de votre machine (La suite) =

== Introduction ==

A nouvelle année, nouvelles résolutions ! Paru dans le numéro 68, un premier article dédié à la découverte des outils disponibles pour la récupération des configurations de votre machine promettait une suite. Je vous propose donc de reprendre ce voyage au centre de votre ordinateur.

Cet article sera articulé autour du diagnostic de pannes et des correctifs associés mais aussi de « trucs & astuces » permettant d'optimiser votre configuration.

== Savez-vous planter les choux ? ==

Les choux peut-être pas mais les ordinateurs je pense que c'est arrivé au moins une fois à chaque lecteur qui lit cet article. Rien de plus énervant qu'un écran qui se fige, le pointeur de souris qui ne se déplace plus, le clavier qui ne répond plus non plus.... Planté ! Ce constat est assez facile à établir mais en trouver la cause reste un problème nettement plus complexe tellement le nombre de causes possibles est important.

Deux solutions : ignorer le problème et relancer le système en se disant que ça « passera », ou alors chercher la cause du problème en essayant de trouver une méthode reproduisant le « plantage » tant redouté.

La première solution fonctionne assez bien mais si l'on à faire à un « vrai » problème de configuration matérielle ou logicielle, on arrivera assez vite à ne plus pouvoir éviter la seconde voire la troisième. J'allais oublier cette troisième solution destinée aux plus riches d'entre vous : changer de matériel. Cette solution coûteuse peut parfois se révéler efficace, parfois pas du tout. A quoi bon changer un composant sans savoir si c'était bien celui-ci qui posait problème ?
Quelque soit la solution retenue, il sera de toute manière nécessaire de localiser la panne pour y apporter la réponse adéquate. Certaines sociétés ou particuliers se sont spécialisés dans ce dépannage ou l'utilisateur est « dépassé » par les événements.

Cet article vous fera, je l'espère, découvrir quelques outils et méthodes pour valider un par un les composants de votre ordinateur. Cela vous permettra j'espère d'être un peu moins dépourvu quand un problème surviendra. L'article reproduira les étapes qu'il faut suivre pour isoler le « fautif ».

== Les causes possibles d'un « plantage » ==

On retrouve deux grandes catégories de pannes provoquant des dysfonctionnements importants sur un système informatique.
* une panne du matériel
* une erreur logicielle au niveau du noyau et des pilotes (drivers)

Il faudra donc être capable de séparer la panne matérielle qui « force » l'ordinateur à entrer dans un mode de fonctionnement non prévu et instable, de l'erreur logicielle qui équivaut à demander à l'ordinateur de faire « n'importe quoi » et qui va donc se « planter ».

Le terme « planté » utilisé ici équivaut à un arrêt du système à cause d'erreurs sévères : instruction illégale ou composants défaillants. Le terme de « plantage » est aussi utilisé pour décrire le fonctionnement d'une application qui se ferme inopinément. Ce cas est plus souvent lié à une erreur de programmation de l'application qu'à une erreur du système. Nous ne parlerons donc pas de ce second cas dans cet article.

== La mémoire qui flanche ? ==

Une cause « classique » des dysfonctionnements se situe au niveau de la gestion de la mémoire de votre machine. Je ne parle pas d'allocation mémoire réalisée par votre système d'exploitation favori mais bien de la manière avec laquelle la carte mère configure et utilise vos barrettes de mémoire. Les applications chargent en mémoire des données et des instructions destinées au processeur. Voici un scénario qui peut provoquer l'arrêt de la machine.

Votre application favorite est lancée depuis la ligne de commande ou une interface graphique via un « clic » de souris. Votre système d'exploitation va donc charger ce programme en mémoire puis en exécuter les instructions. Au plus bas niveau de votre système, le processeur exécute des instructions en langage machine (assembleur) présente en mémoire.
Malheureusement, votre mémoire est défaillante et elle n'arrive pas à maintenir un état stable des informations qui lui sont confiées. Par exemple, la lettre C est représentée par le code 67, ou « 1000011 » en binaire. Si la zone mémoire change d'état, alors le contenu de la valeur stocké à cet endroit changera : on pourrait se retrouver avec « 1000010 ». Un seul bit a changé, mais on passe de la lettre 'C' (67) à la lettre 'B'(66). Le résultat ne se fait pas attendre, le processeur se retrouve à exécuter des instructions qui n'ont plus de sens, provoquant l'arrêt de la machine.

Les pannes de mémoires sont généralement dues à des composants endommagés, des barrettes incompatibles ou un « timing d'accès » à la mémoire (nommé CAS (Column Address Strobe) dans la plupart des BIOS) trop agressif permettant des lectures dans des zones mémoires avant que les écritures aient eu le temps de se stabiliser pour en garantir le contenu.

Il est assez simple de valider votre configuration mémoire grâce à l'utilitaire memtest (http://www.memtest.org). Cet utilitaire de taille très modeste, 96 Kilo-octets, est écrit en assembleur ce qui lui permet de s'exécuter indépendamment du système d'exploitation. Ceci garantit un test « proche » du matériel, sans sur-couche pouvant apporter d'autres problèmes.
La version 1.65 actuelle est téléchargeable sous deux formes : une iso que l'on peut graver sur un CDRW de préférence vu la petite taille du programme ou sous la forme d'une amorce système (pre-compiled bootable binary). Il suffira de décompresser l'archive puis d'exécuter la commande suivante :
<code>dd if=memtest.bin of=/dev/fda</code>

Ceci écrasera le contenu de votre disquette pour y copier memtest.
Rebootez l'ordinateur avec la disquette placée dans le lecteur, memtest devrait se lancer.

[[Image:memtest.jpg]]

La figure ci-dessus, est une capture d'écran de memtest en fonctionnement. Le barre de progression principale affichée en haut à droite de l'écran (2% dans cet exemple) permet de suivre la progression du test. Les erreurs apparaissent dans la partie inférieure de l'écran. Il suffit de laisser fonctionner memtest au moins une fois jusqu'à 100%. Si aucune ligne ne s'est affichée alors vou pouvez considérer que la mémoire est fonctionnelle. Dans le cas contraire, il faudra soit procéder à son remplacement s'il s'agit d'une seule barrette mémoire, soit tester les barrettes indépendamment (l'une puis l'autre) avec ce logiciel. Dans le cas de 2 ou 3 barrettes qui ne fonctionnement pas correctement ensemble mais qui fonctionnement correctement individuellement, il faudra vérifier qu'elles sont bien de même modèle/marque et remettre le Bios dans une configuration initiale.

Votre mémoire est bonne ? Testons les autres composants de votre machine pour traquer la source de ce plantage.

== Il ne fait pas un peu chaud là ? ==

Ces dix dernières années la puissance consommée et dissipée par nos ordinateurs a littéralement explosé ! Du 486 qui ne nécessitait quasiment pas de ventilateur, on est arrivé à des stations de travail/jeu avec des alimentations pouvant atteindre 1KiloWatt pour les dernières et 500watt pour des modèles plus « grand public ». Le processeur est un des composants gourmands de la machine. Certains modèles peuvent consommer plus de 130W ! Autant dire que si le système est mal ventilé, la montée en charge du processeur peut provoquer un échauffement important provoquant une surchauffe de celui-ci. S'il dépasse ces caractéristiques de fonctionnement, il va alors exécuter du code incorrect provocant un plantage du système.

Un bon test pour vérifier que votre processeur n'est pas la cause de votre instabilité : commencez par relever la température de votre machine au repos à l'aide des informations fournies soit par l'acpi soit pas lm_sensors.

<code>[erwan@R1 ~]$ cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 42 C
[erwan@R1 ~]$

[root@konilope ~]# sensors | grep Temp
M/B Temp: +39°C (low = +15°C, high = +40°C) sensor = thermistor
CPU Temp: +127°C (low = +15°C, high = +45°C) sensor = thermistor
Temp3: +44°C (low = +15°C, high = +45°C) sensor = thermistor
[root@konilope ~]</code>

La méthode utilisant lm_sensors nécessite une interprétation de la part de l'utilisateur. Dans cet exemple, il apparaît évidant que le processeur ne peut avoir une température de fonctionnement aussi élevée (127°C). L'erreur est du à un mauvais calcul de la part de lm_sensors. Il se base sur le type de capteurs thermiques utilisé par la carte mère pour calculer la température des différents composants. Malheureusement, le montage électrique autour du capteur de température peut varier d'un modèle de carte à un autre, ce qui fausse les calculs. On considéra donc, que pour cette machine (konilope) sa température se situe aux alentours de 42° : valeur moyenne entre les deux valeurs « cohérentes » relevées par lm_sensors. On pourra cependant vérifier cette approximation en relevant la température du disque sur à l'aide de smartmontools.

<code>[root@konilope ~]# smartctl -A /dev/hda | grep Temperature
194 Temperature_Celsius 0x0022 042 052 000 Old_age Always - 42
[root@konilope ~]# </code>

De manière générale, il est préférable de maintenir sa machine en dessous des 55° et celle de son processeur en dessous de 70°C. Au delà, le système risque d'être instable. Si ce n'est pas le cas, effectuez les modification nécessaire pour y parvenir : meilleure ventilation du processeur ou du boîtier par exemple.

Ensuite, téléchargez l'utilitaire cpuburn depuis un mirroir (http://pages.sbcglobal.net/redelm/cpuburn_1_4_tar.gz) ou depuis votre distribution linux favorite (oui, oui, urpmi cpuburn ça fonctionne ;o)).

Vous y trouverez plusieurs programmes nommés burnXX ou XX représente votre processeur. La version P6 sera à utiliser sur les processeurs Intel Pentium 4, la version K7 pour les processeurs Athlon x86. Pour les processeurs plus récents, utilisez la version P6.
Ce logiciel réalise des boucles en langage assembleur ayant pour but de stresser votre processeur de manière importante et donc le faire chauffer. Lancez cpuburn autant de fois que vous avez de processeur sur votre machine puis observez la température de votre machine. Si lors de la montée en température votre système se fige, alors vous avez un problème de thermie. Si cpuburn ne fait pas planter votre ordinateur au bout de 10mn, vous pouvez considérez que votre système est stable de ce coté là. Vous pouvez aussi utiliser ce test pour vérifier que vos ventilateurs d'ordinateurs portable se déclenchent bien en cas de surchauffe.
Sur un portable récent, on obtient le résultat suivant au bout de quelques minutes de cpuburn.

<code>[root@R1 ~]# cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 80 C
[root@R1 ~]# </code>

Malgré la température très élevée du processeur, le système est resté stable ce qui permet de valider qu'il est capable d'encaisser une montée en température élevée. Bien entendu, plus votre machine sera « chaude » plus elle s'usera rapidement. Il ne faut pas oublier que les autres composants peuvent souffrir de la chaleur dégagée par le processeur par exemple : les disques durs en sont un bon exemple car les plateaux ne supportent pas la chaleur.
Ce test est bon aussi ? A priori, les composants de base de votre système sont en bon état, vous pouvez commencer à regarder du coté configuration logicielle.

== APIC es tu là ? ==

Le manque de stabilité peut aussi s'expliquer par la gestion des interruptions.
L'architecture PIC (Programmable Interrupt Controllers) représentée par la famille de composants Intel 8259, permettait une gestion de 8 interruptions pour un unique processeur. On les associe par 2 pour obtenir les 16 niveaux d'interruptions nécessaire depuis nos vieux 80286 (milieu des années 80). Avec l'arrivée des systèmes multi-processeurs, l'architecture APIC (Advanced Programmable Interrupt Controllers) (Intel 82093) à été ajoutée pour permettre une gestion plus fine des interruptions. En effet, dans un contexte multi-processeurs, il est nécessaire de pouvoir choisir quel processeur traitera quelle interruption pour ne pas rester figé dans l'ancien modèle (PIC) où le processeur de « boot » est assigné à un ensemble d'interruptions.

De plus, l'architecture APIC apporte une gestion de 24 interruptions, une gestion de priorité des interruptions et le routage de l'interruption sur le bon processeur, contre un simple routage de 2*8 interruptions dans le modèle PIC sur un seul processeur. Depuis une dizaine d'années, Intel propose le modèle APIC comme nouvelle architecture, y compris pour les systèmes mono-processeurs. Les ordinateurs récents, y compris les portables, sont maintenant équipés uniquement de composants APIC même si l'on peut obtenir un comportement de type PIC avec ceux-ci.

L'architecture APIC est constituée d'un ou plusieurs composants situé physiquement dans le southbridge (IO-APIC), généralement un par bus, et un composant situé dans le processeur : le Local APIC (LAPIC). Le LAPIC va permettre la gestion des interruptions au niveau du processeur local. Il permet aussi de générer des interruptions par exemple pour transmettre des interruptions à des processeurs voisins dans le contexte d'un système multi-processeurs, ces messages sont appelés IPI (Inter Processor Interrupts).

De plus le Local APIC (LAPIC) inclut un « timer » de précision cadencé à la fréquence du bus, généralement il peut être utilisé par l'ordonnanceur de votre système d'exploitation favori ou d'autres outils de haut niveau (profiler kernel : oprofile, vtune). Les LAPIC et l'IO-APIC sont reliés par un bus spécifique pour permettre un échange rapide des informations.

Schema logique d'implémentation :

[[image:acpi.jpg]]

Les IO-APIC vont donc se charger de collecter les interruptions provenant des périphériques systèmes et d'en assurer le transfert vers le ou les processeur(s) suivant une route préalablement programmée par le BIOS et/ou le système d'exploitation.

Cependant, l'implémentation des APIC dans les BIOS peut provoquer certaines instabilités sur votre système Linux. Par expérience, il n'y a pas de règle pour trouver la configuration qui peut aider votre machine à se stabiliser car cela dépend de chaque machine. Des différences peuvent même exister entre deux versions de BIOS d'un même ordinateur. Cependant, dans la série 2.6 du noyau Linux et les version 2.4 récentes nous disposons d'outils permettant de re-paramétrer cette configuration en activant/désactivant les IO-APIC ou les LAPIC.

Chaque composant possède un activateur ou un inhibiteur, on aura donc d'un coté « apic » et « noapic » pour la gestion des IO-APIC, « nolapic » et « lapic » de l'autre pour la gestion des LAPIC. Ces 4 options sont à utiliser sur la ligne de commande du noyau, c'est à dire au moment où le « bootloader » (lilo ou grub par exemple) va charger le noyau en mémoire. L'utilisation de « apic » et « lapic » permet d'activer ces composants qui ne l'ont pas été par le BIOS. L'activateur « apic » n'est disponible que les architectures de type x86_64 car celui-ci est déjà activé sur les systèmes de type x86. On désactivera les APIC dans le cas où le système affiche des messages d'erreurs sur les APIC comme :

<code>« APIC error on CPU0: 40(40) »</code>

ou

<code>MP-BIOS bug: 8254 timer not connected to IO-APIC
failed.
timer doesn't work through the IO-APIC - disabling NMI Watchdog!</code>

La désactivation des IO-APIC permet par exemple de corriger le comportement parfois récalcitrant de certaines cartes vidéos qui ne parviennent pas à afficher correctement en mode 2D/3D (écran noir par exemple).

La non activation des LAPIC peut avoir comme conséquence un dysfonctionnement de l'ACPI (gestion d'énergie avancée). Ce cas est traité par le noyau, vous retrouverez dans les messages de démarrage la ligne suivante : « "Local APIC disabled by BIOS you can enable it with lapic ».

Pour résumer, si votre machine, en général à architecture mono-processeur, a tendance à se bloquer lors de l'utilisation de périphériques tels que le port usb, la carte graphique ou la carte son, essayez de désactiver le LAPIC puis l' IO-APIC puis les 2. Pour exemple, les cartes mère A7N8X de chez Asus ont largement tendance à se bloquer si l'on ne spécifie pas « nolapic » lors du boot. Sur certaines machines, il faudra faire le contraire à savoir forcer l'activation des LAPIC. Ceci dépendra de votre machine et de sa conception.

== A vos marques, rebootez ! ==

Certains machines peuvent présenter quelques soucis pour redémarrer. Encore une fois, on retrouve au coeur de ce problème l'interaction entre le noyau et le matériel notamment l'ACPI. Les ordinateurs portables dont le modèle HP nc6120 ont par exemple le bon goût de rester bloqués sur le message « No reboot fixup found for your hardware ». Ceci indique que le noyau ne connaît pas de contournement pour ce matériel (ce qui est le cas de la quasi totalité des ordinateurs) mais puisque vous voyez ce message c'est que votre machine n'a pas réussi à rebooter. Heureusement, il existe des contournements pour permettre un redémarrage plus « bas niveau ». Le noyau défini les modes suivants : « b » « c » « h » « s » et « w ».
Le mode de reboot peut être défini sur la ligne de commande du noyau suivant la forme « reboot=<mode> ». Le mode « s » est réservé au systèmes multi-processeurs, elle va réinitialiser chacun des processeurs.

Le mode « b » permet quant à lui de rebooter en faisant un appel direct au bios qui se chargera de faire redémarrer la machine. Ce mode fonctionne plutôt bien car dans le cas d'un BIOS posant problème sur l'ACPI, on peut espérer avoir un reboot correct. C'est le cas sur de notre portable cité précédement.

Le mode « h » se chargera de faire redémarrer la machine en réinitialisant le processeur. C'est l'équivalent du mode « s » pour les environnements mono-processeurs. Pour finir, les modes « c » et « w » correspondent aux modes « cold » et « warn » : ces modes sont plus connus sous le nom de « reboot à froid » et « reboot à chaud ». Le premier effectuera les tests de mémoire tandis que le second exécutera un reboot plus court.

De manière générale, on utilisera plutôt le mode « b » ou « h » pour les systèmes mono-processeurs récalcitrant et le mode « s » pour les systèmes multi-processeurs.

== Toujours plus de performance ==
Votre configuration est bien stable depuis un certain temps. Toutefois vous trouvez qu'elle est un peu lente, elle ne vous donne pas satisfaction par rapport à ce qu'elle devrait fournir.
Cette partie de l'article va explorer comment vérifier et corriger les problèmes de performance des différents composants.
Note: certaines configuration mono-processeur nécessitent de désactiver LAPIC (nolapic)

=== Le disque dur ===

Il arrive parfois que le disque dur semble un peu lent et pénalise le système dans son ensemble. Hdparm est là pour vous aider à y voir plus clair. Hdparm est à l'origine conçu pour les systèmes de disques IDE de type PATA. Le nouveau système de disque SATA, ne permet pas toujours en fonction de l'implémentation, l'appel à toutes ces astuces. Cependant les nouvelles séries de kernel à partir du 2.6.15 devrait permettre une gestion plus unifiée des systèmes de disques PATA et SATA.

Le test « hdparm -t /dev/<mon_device> » permet de tester la vitesse de lecture depuis le disque dur jusqu'en mémoire. Une valeur de 25Mo/sec est un minimum pour des machines récentes. Plusieurs paramètres peuvent influencer les performances d'un disque IDE.
La commande « hdparm -cd » permet de vérifier que les entrées/sorties sont réalisées en 16-bit (le mode 32-bit n'offre pas de performance supplémentaire) alors que le DMA (Direct Memory Access) est activé. Ceci permet la minimisation de l'utilisation du processeur pendant les accès au disque dur.

<code>[root@R1 ~]# hdparm -cd /dev/hda
/dev/hda:
IO_support = 0 (default 16-bit)
using_dma = 1 (on)
[root@R1 ~]# </code>

La commande « hdparm -c0d1 /dev/<mon_device> » permet de configurer le périphérique dans ce mode. Le noyau de votre distribution Linux devrait le réaliser de manière automatique.

L'option « -I » permet d'obtenir plus d'informations sur la configuration de votre disque dur.

<code>[root@R1 ~]# hdparm -I /dev/hda
/dev/hda:
ATA device, with non-removable media
Model Number: FUJITSU MHT2040AT
Serial Number: NN77T3C13KB9
Firmware Revision: 0022
Standards:
Used: ATA/ATAPI-6 T13 1410D revision 3a
Supported: 6 5 4 3
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 78140160
device size with M = 1024*1024: 38154 MBytes
device size with M = 1000*1000: 40007 MBytes (40 GB)
Capabilities:
LBA, IORDY(cannot be disabled)
bytes avail on r/w long: 4 Queue depth: 1
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 128 (0x80)
Recommended acoustic management value: 254, current value: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
* Look-ahead
* Write cache
* Power Management feature set
Security Mode feature set
* SMART feature set
* Mandatory FLUSH CACHE command
* Device Configuration Overlay feature set
* Automatic Acoustic Management feature set
* SET MAX security extension
Power-Up In Standby feature set
* Advanced Power Management feature set
* DOWNLOAD MICROCODE cmd
* SMART self-test
* SMART error logging
Security:
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase
40min for SECURITY ERASE UNIT.
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct
[root@R1 ~]#</code>

On y retrouve le modèle, le numéro de série et la version du firmware qui peuvent être utiles en cas de contact avec le Service Après-Vente ou de mise à jour pour une série de firmwares défaillante.

La ligne commençant par « DMA » dans la partie « Capabilities » permet d'afficher la vitesse de transfert négociée entre le disque dur et le driver IDE de Linux. L'étoile précède la valeur actuelle. Dans cet exemple, le mode udma5 est sélectionné : ceci est conforme aux machines disponibles sur le marché depuis environ 3 ans.

Pour rappel, voici le tableau de conversion entre le mode DMA et la vitesse maximale associée.

Type de fonctionnement
Vitesse Maximale en MO/sec
UltraDMA 0
16,6
UltraDMA 1
25
UltraDMA 2
33,3
UltraDMA 3
44,4
UltraDMA 4
66,6
UltraDMA 5
100
UltraDMA 6
133,33

Une configuration actuelle ne devrait pas être en dessous de UDMA5. Si ce n'était pas le cas, on peut essayer de renégocier la vitesse de transfert à l'aide de la commande :

<code>hdparm -X udma5 </code>

Celle-ci permet de forcer le mode UltraDMA5. Il faut utiliser cette commande avec précaution car elle pourrait générer des pertes ou de la corruption de données en cas de transfert pendant ce changement de mode.

Vous pouvez aussi impacter les performances de votre disque dur en modifiant sa vitesse de rotation. Cette fonctionnalité connue sous le nom de Automatic Acoustic Management (AAM) est utilisable avec l'option « -M » de hdparm. La valeur 128 représentera la vitesse la plus faible avec un disque silencieux, la valeur 254 la vitesse la plus élevée mais avec comme contre-partie un disque plus bruyant. On pourra noter des différences de quelques Mo/sec selon les configurations.

Il est aussi à noter que l'utilisation de logiciels permettant une meilleure gestion d'énergie (cpufreq, laptop-mode) peut dégrader les performances d'un disque dur de manière notable.

=== Configuration bas niveau du réseau ===

Le réseau local filaire peut parfois être un peu lent. Voici quelques tests pour vérifier si la lenteur provient du logiciel, du noyau ou du matériel. Tout d'abord, explorons la trousse à outils indispensable pour analyser votre carte réseau : ethtool. Digne successeur de mii-tool, il permet de s'informer sur la configuration de votre carte réseau.

Il suffit de lancer « ethtool <votre_interface> » » pour obtenir la configuration matérielle de votre carte. On y retrouve les modes supportés par votre carte (Supported Link Modes ainsi que la vitesse actuelle (Speed), obtenue par auto-négociation dans cet exemple.

On peut également savoir si le câble réseau est connecté à la carte grâce à la ligne « Link Detected ». Le type de « duplex » utilisé permet également de savoir si la négociation avec l' élément actif au bout de votre câble (commutateur, concentrateur ou une autre machine) a correctement fonctionné. Le duplex définit le mode de transmission : le mode half-duplex indique que l'on émet puis on reçoit des données, le mode full-duplex indique que l'on peut émettre et recevoir en même temps des données. Le mode full-duplex est donc plus que recommandé pour vos équipements réseaux.

<code>[root@konilope ~]# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Current message level: 0x000020c1 (8385)
Link detected: yes
[root@konilope ~]# </code>

=== Mesurer les {contre}performances de votre réseau ===

Une fois vérifiée la bonne configuration de votre matériel, nous pouvons passer à la vérification des performances entre deux machines.

L'utilitaire netpipe (http://www.scl.ameslab.gov/netpipe/) permet de réaliser des tests de performance mais aussi d'intégrité entre deux machines. Il permet de tester les performances du réseau au travers la couche IP et non pas depuis un mode plus bas niveau comme pourrait l'être un test utilisant directement le driver Ethernet. Ce test permet donc de valider que la configuration matérielle mais aussi logicielle est correcte.

Sur la première machine, exécutez « NPtcp » : netpipe se positionne en mode « serveur ».
Sur la seconde machine, exécutez « NPtcp -h <machine1> » : netpipe se connecte au serveur netpipe de la machine nommée machine1 pour effectuer le test de performance.

Le test par défaut teste les communication allant de 1 octet jusqu'à 8 Mo. Il peut prendre plusieurs minutes si le réseau est « lent ». Le test va montrer pour chaque taille de paquet la performance obtenue. Il est normal d'obtenir des performances faibles pour des paquets d'une taille inférieure à 8 Ko. Transporter des petits paquets nécessite de réaliser beaucoup d'opérations pour le processeur pour une quantité d'information minime. Les performances seront meilleures à partir d'environ 16 Ko et maximales à partir de 128 Ko. Sur un système utilisant du gigabit ethernet, on constatera une performance de 39Mbps à 256 octets, 287Mbps à 4Ko, 614Mbps à 16Ko, 845Mbps à 128Ko, 895Mbps à 8Mo.

Vous pouvez ainsi vérifier et comparer facilement les performances de votre configuration réseau. Netpipe permet également de tester la vitesse du réseau pour une taille de paquets définie entre la taille indiqué par l'option « -l » et la taille indiquée par l'option « -u ». Ainsi, NPtcp -l 16384 -u 16384 permet de tester la bande passante réseau pour une taille de paquet égale à 16Ko.

L'option « -n <nb-cycle> » permet de définir le nombre de boucles à réaliser pour le test (50 par défaut). Enfin, pour réaliser des tests « full-duplex », on utilisera l'option « -2 ». Ce test permet de s'assurer du bon fonctionnement du mode de communication permettant l'écriture et la lecture simultanées.

Attention, même si ce test donne de bons résultats, cela ne veut pas dire que la configuration est exempte d'erreur de configuration. Par exemple, les performances réseaux peuvent être très bonnes en point à point mais mauvaises lorsque l'on aura une charge réseau avec plusieurs clients. Dans cette situation, il faut vérifier que le contrôle de flux est bien activé sur toutes les machines. L'option « ethtool -a » permet de vérifier que les champs « rx » et « tx » sont placés sur « on ». Si ce n'était pas le cas activez-les avec la commande « ethtool -A eth0 rx on » et « ethtool -A eth0 tx on ».

Les cartes réseaux, des serveurs essentiellement, permettent maintenant de réaliser le « tcp segment offload ». Cette technique permet de décharger une partie du traitement TCP directement dans l'électronique de la carte réseau. Ceci à pour effet de décharger le processeur central d'un traitement fastidieux. L'option « -k » d'ethtool permet de consulter l'état de cette fonctionnalité (off/on). On pourra l'activer sur des serveurs générant un gros trafic réseau par exemple : « ethtool -K eth0 tso on ».

Vous voilà maintenant équipé de nouveau outils pour traquer la perte de performances de votre installation réseau. Ceci couplé aux habituels tcpdump/ethereal, voilà une belle panoplie du zorro du réseau.

=== Quand la latence s'en mêle ===

La latence représente le temps nécessaire à un système pour prendre en compte un événement.

Il arrive que certains périphériques de votre machine nécessitant des débits importants ou une latence assez faible sur le bus PCI soient « poussifs ». On retrouve dans cette catégorie les cartes vidéos accélératrice 3D, les cartes son et les cartes d'acquisition firewire ou DVB (récepteur de télévision numérique terrestre : TNT).

Un périphérique branché sur le bus PCI doit attendre que le bus soit libre pour émettre les données vers la mémoire centrale. Le bus PCI qui est le coeur de communication des périphériques est donc soumis en permanence à un arbitrage qui permet de décider qui doit émettre des données et qui doit attendre. Cet arbitrage est en partie réalisé grâce au « latency_timer ».

Chaque périphérique possède une valeur de « latency_timer » comprise en 0 et 248 cycles d'horloge du bus. Plus la valeur sera importante plus le périphérique disposera de temps pour transmettre des informations. Une latence de 248 cycles permet d'obtenir une priorité forte sur le bus, ce qui permet un débit important. A contrario, une latence de 0 indiquera au périphérique qu'il doit cesser ses transmissions si un autre composant à besoin du bus : ceci se traduira par une perte de bande passante importante.

La configuration réalisée par défaut sur votre machine doit être correcte mais il peut arriver qu'une carte 3D ou DVB soit configurée avec une latence trop faible, ce qui aurait pour conséquence d'offrir une image saccadée et peu fluide. Une carte son offrirait également le même type de symptômes avec un son hâché ou excessivement métallique.

Heureusement, une série d'outils est là pour vous aider à diagnostiquer le problème mais aussi à le résoudre. Le projet pciutils (http://atrey.karlin.mff.cuni.cz/~mj/linux.shtml#pciutils) contient deux outils indispensables: lspci et setpci. Bien entendu, votre distribution favorite devrait posséder ce logiciel, il vous suffira de l'installer avec votre gestionnaire de paquet favori (urpmi, apt, smart).

La commande « lspci » vous permet de lister les périphériques PCI disponibles sur votre ordinateur (cf article paru dans le numéro 68). Cet exemple se basera sur une carte vidéo ayant pour adresse sur le bus PCI « 01:00.0 ».

<code>[root@lagirafe] lspci -v -s 01:00.0
01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX Go5200 32M/64M] (rev a1) (prog-if 00 [VGA])
Subsystem: Samsung Electronics Co Ltd: Unknown device c00f
Flags: bus master, 66Mhz, medium devsel, latency 16, IRQ 11
Memory at c8000000 (32-bit, non-prefetchable) [size=16M]
Memory at d8000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 3.0
[root@lagirafe]</code>

On retiendra dans cette ligne, la valeur 'latency 16'. Ceci risque de poser problème lorsque celle-ci aura besoin d'un fort débit pendant un jeu par exemple. Augmenter la latence va donc se révéler nécessaire pour ce périphérique.

La commande setpci permet de modifier les paramètres PCI d'un périphérique ou d'un bus complet avec tous ses périphériques.

La commande « setpci -v -d 01:* latency_timer=20 » permet de positionner tous les périphériques du bus 01 à une valeur de 32 cycles. Il est à noter que la commande setpci utilise des valeurs en hexadécimal mais lspci affichera les valeurs en décimal.

Pour en revenir à nos moutons, la correction de la latence de cette carte graphique se fera avec la commande « setpci -v -d 01:00.0 latency_timer=f8 ». Ceci positionne donc la carte sur la plus grande valeur de latence possible, ce qui lui garantira la plus grande bande passante possible. Il est possible d'utiliser la valeur « ff » comme paramètre pour « latency_timer » mais celui-ci sera converti à la volée par la commande setpci en « 0xf8 ».

Attention, certains composants de votre machine doivent rester en « latency_timer=0 » pour garantir une bon fonctionnement de votre système : il ne faudra donc pas modifier les latences des contrôleurs mémoire et des ponts PCI connectés généralement sur le bus « 0:* ».

== DSDT : le cauchemar continue ! ==

Cette partie de l'article a pour but d'expliquer le problème que peut représenter la table DSDT pour un certain nombre de machines et surtout les ordinateurs portables.

La norme ACPI 3.0 de Septembre 2004 disponible gratuitement à l'adresse http://www.acpi.info/DOWNLOADS/ACPIspec30.pdf définit la DSDT comme une table remplie par un OEM permettant au système d'exploitation de découvrir les ressources pour la gestion de l'énergie avancée, de la gestion thermique ainsi que la gestion du Plug'nPlay des ressources définies par l'ACPI.

Voici une description certes un peu théorique mais nécessaire pour bien comprendre la problématique et ses conséquences. Le constructeur de l'ordinateur doit donc définir dans le BIOS une table contenant une liste de ressources et leurs configuration et ce pour que le système d'exploitation puisse s'en servir. Noble cause n'est il pas ? Tout au long des 618 pages de ce document sont spécifiés les éléments du langage à utiliser ainsi que sa syntaxe. L' « ACPI Source Language » permettra donc aux développeurs d'écrire des DSDT puis de les compiler dans un format nommé « ACPI Machine Language » en utilisant un compilateur adéquat. Le système d'exploitation utilisera la table compilée (AML) pour accéder aux ressources ACPI.
Sur la plupart des ordinateurs portables, la table DSDT ne respecte pas la norme ACPI dans sa syntaxe. Ceci est très gênant car cela bloque le code de l'interpréteur ACPI du noyau Linux qui essaie de la lire. Le résultat est sans appel, pas d'ACPI, pas de gestion d'énergie avancée, plus de ventilation automatique sur certains modèles d'ordinateurs, plus de touche de gestion de contraste/luminosité sur d'autres etc...

Ceci est très gênant sur un ordinateur portable. Alors que faire ? Dans un premier temps, prévenir le constructeur que son BIOS est incorrect et ne respecte pas la norme ACPI. La réponse se fait toujours attendre pour tous ceux qui « osent » poser la question au support technique : à savoir, les constructeurs ignorent tout simplement les mails de ce type.
La seconde étape puisque vous êtes devant le fait accompli d'une machine non conforme, il va falloir corriger cette table. Il suffit de récupérer la table actuelle via la commande 'cat /proc/acpi/dsdt > dsdt.aml' si vous avez la chance d'avoir un répertoire /proc/acpi malgré une table DSDT endommagée, sinon utilisez la commande 'acpidump -b -t dsdt -o dsdt.aml'. La commande acpidump est fournit dans le projet pmtools (ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20050926.tar.bz2)
Vous avez donc extrait la table DSDT de votre système. Il ne reste plus qu'à essayer de la recompiler. Pour cela, le compilateur IASL de la société Intel (http://developer.intel.com/technology/iapc/acpi/downloads.htm) offre sous Linux et Windows une plate-forme de compilation pour le langage ASL.

Suivez les instructions du site pour télécharger et compiler la version unix d'iasl. Ensuite, décompilez la table avec la commande « iasl -d dsdt.aml ». Le fichier dsdt.dsl vient d'être créé par le décompilateur. Il suffit de le recompiler avec la commande « iasl -tc dsdt.dsl » pour constater les dégâts ! La DSDT que vous avez dans votre BIOS est généralement compilée par le compilateur de Microsoft qui semble autoriser une syntaxe plus qu'approximative.
Si vous avez de la chance, votre DSDT s'est recompilée sans erreurs, vous obtenez donc un fichier dsdt.hex et un fichier dsdt.aml. Il ne reste plus qu'à injecter cette dsdt dans le noyau Linux et le tour sera joué.

Si vous avez moins de chance, votre DSDT est syntaxiquement incorrecte et génère des erreurs. Les expliquer plus en détails nécessiterait un article complet, il ne sera cité que les plus « habituelles » (sic).

<code>dsdt.dsl 2626: Field (ECR, DWordAcc, Lock, Preserve)
Error 1048 - ^ Host Operation Region requires ByteAcc access </code>

Cette erreur présente à ligne 2626 du fichier dsdt.asl indique une erreur de type dans la déclaration du champ ECR. Il suffit dans ce cas de changer le mot « DWordAcc » par « ByteAcc ». Celle-ci reste assez simple à corriger, on se demande donc pourquoi les constructeurs ne prennent pas le temps de vérifier et de corriger leur BIOS.

<code>dsdt.dsl 2672: Method (_GLK, 1, NotSerialized)
Warning 2024 - ^ Reserved method has too many arguments ( _GLK requires 0) </code>

La méthode _GLK n'a besoin que de 0 paramètre tandis que ce code en utilise 2 ! La correction est assez simple : il suffit de remplacer la ligne 2672 par « Method(_GLK) ».

Pour plus de détails sur la correction des erreurs de compilation de votre table dsdt, je vous recommande les tutoriaux disponibles depuis la page http://acpi.sourceforge.net/dsdt/index.php du projet ACPI.

Votre DSDT est compilée avec succès, il ne vous reste plus qu'à l'ajouter pour que votre noyau puisse l'utiliser à la place de celle fourni par le BIOS (modifiable uniquement par le constructeur, via une mise à jour).

Il existe trois possibilités pour inclure une table DSDT : la modification du noyau Linux ( noyau < 2.6.9), l'injection de la DSDT dans la configuration du noyau (noyau >= 2.6.9), l'intégration de la table DSDT dans l'initrd qui nécessite un patch kernel disponible à l'adresse http://gaugusch.at/kernel.shtml.

Pour les noyaux 2.6.9 et supérieur, copiez votre fichier dsdt.hex sous le nom «/usr/src/linux/include/acpi/dsdt_table.h » puis reconfigurez votre noyau.
Insérer « dsdt_table.h » dans l'option « Include you custom DSDT » disponible dans le menu « Power Management/ACPI/ ». Recompilez votre noyau et redémarrez avec votre nouveau noyau.
Pour les noyaux inférieurs à 2.6.9, il est possible de modifier le code source de votre noyau pour intégrer votre DSDT mais il est préférable d'utiliser le patch permettant l'insertion de la table DSDT dans l'initrd. Recompilez votre noyau avec ce patch, puis suivez la procédure décrite ci-dessous.

Certaines distributions Linux comme « Mandriva Linux » possèdent le patch qui permet de n'avoir qu'à reconstruire l'initrd avec la commande « mkinitrd –dsdt=/boot/dsdt.aml /boot/initrd-`uname -r`.img `uname -r` » puis de relancer lilo avant de redémarrer votre machine. Lors du démarrage de celle-ci vous devriez voir le message suivant :

<code>ACPI: Looking for DSDT in initrd... found (at offset 0x4f8d9).
ACPI-0294: *** Info: Table [DSDT] replaced by host OS</code>

Vous voilà maintenant avec une table DSDT correcte et un ACPI fonctionnel. La question qui reste ouverte est pourquoi les constructeurs n'utilisent pas un compilateur digne de ce nom pour permettre à leur clients de pouvoir utiliser d'autres systèmes d'exploitation que Windows de Microsoft.

Pour la petite histoire, si vous cherchez dans votre dsdt vous risquez de tomber ce genre de lignes :

<code>If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), Zero))
If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))
If (LEqual (SCMP (\_OS, "Microsoft WindowsME: Millennium Edition"), Zero))
If (LEqual (SizeOf (\_OS), 0x27)) </code>

Lorsque qu'un système d'exploitation souhaite utiliser les ressources ACPI du BIOS, il utilise son nom de système d'exploitation (acpi_os_name). On retrouve donc dans les bios des parties qui ne seront exécutées que pour certains systèmes d'exploitation de Microsoft. On retrouve même certains tests où c'est la longueur du nom qui compte...... Ceci prouve bien que les constructeurs d'ordinateurs savent corriger des tables DSDT pour les systèmes d'exploitation mais pas forcément pour le notre malheureusement. Depuis le noyau 2.6.9, le noyau Linux utilise « Windows NT » comme « acpi_os_name » pour assurer une meilleure compatibilité matérielle dixit Len Bron d'Intel dans le changelog de cette version.

== Comment trouver le pilote qui va avec votre matériel ? ==

Cette question on se la pose souvent mais uniquement lorsque l'on essaye de brancher un nouveau périphérique sur sa machine. Les distributions récentes permettent de détecter automatiquement votre matériel et de lui associer un pilote avec sa configuration. Ce mécanisme fonctionne plutôt bien mais cela n'évite pas les dysfonctionnements voir l'absence de fonctionnement.

Pour vérifier si votre noyau Linux est capable de supporter un nouveau périphérique PCI par exemple, il suffit d'en récupérer les identifiants PCI (constructeur et produit) puis de les rechercher dans le fichier « /lib/modules/`uname -r`/modules.pcimap » qui est auto-généré lors de la commande depmod.

L'utilitaire « lspcidrake -v » vous permet de trouver les identifiants PCI de votre carte, la commande « lspci » vous permet de trouver le nom de votre périphérique puis faites un « lspci -n » pour en trouver la correspondance numérique. On utilisera la position du périphérique sur le bus pour retrouver la correspondance numérique « 02:05.0 » dans cet exemple.
<code>[root@pumphome] lspci
[....]
02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01)
[root@pumphome] lspci -n
[...]
02:05.0 Class 0200: 14e4:4401 (rev 01)
[root@pumphome]</code>

Ainsi cette carte réseau possède les identifiants 14e4 (constructeur) et 4401 (produit). Il suffit de rechercher cette valeur dans le modules.pcimap, ce qui nous donnera la correspondance en module (pilote).

<code>[root@pumphome] grep "0x000014e4 0x00004401" /lib/modules/2.6.12-12mdk-i686-up-4GB/modules.pcimap
b44 0x000014e4 0x00004401 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
bcm4400 0x000014e4 0x00004401 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0</code>

On voit ici que cette carte peut utiliser le driver b44 ou le driver bcm4400. On ne trouve pas toujours les identifiants PCI de produit sous leur forme directe, on peut également trouver « 0Xffffffff » qui indique que tous les cartes du constructeur sont gérées par un module.
Il ne vous restera plus qu'à effectuer la configuration associée à ce périphérique pour qu'il fonctionne correctement.

== Conclusion ==

La fin de cet article conclut une toute petite série de deux articles ayant pour but de vulgariser l'architecture de nos machines, de découvrir les outils disponibles pour mieux comprendre leur configuration et au besoin régler les problèmes de configuration matérielle qui ont souvent le don de nous pourrir la vie.

Merci à LaurentJ de #Mandrivafr pour ses tests complémentaires sur les problèmes d'IO-APIC. Un énorme merci à Nicolas Planel pour sa relecture pointue et également Anne pour sa patience de girafe à relire et « quaurigé »mes « photes », ainsi qu'à tous ceux qui m'ont aidé à découvrir ce que je restitue dans cet article.

Cet article a été publié dans Linux Magazine France n°78. Il est publié sur Léa avec l'aimable autorisation de l'éditeur.

Découvrez les ressources de votre machine (La suite)

2006-06-11T20:30:12Z

Ennael : /* APIC es tu là ? */

= Découvrez les ressources de votre machine (La suite) =

== Introduction ==

A nouvelle année, nouvelles résolutions ! Paru dans le numéro 68, un premier article dédié à la découverte des outils disponibles pour la récupération des configurations de votre machine promettait une suite. Je vous propose donc de reprendre ce voyage au centre de votre ordinateur.

Cet article sera articulé autour du diagnostic de pannes et des correctifs associés mais aussi de « trucs & astuces » permettant d'optimiser votre configuration.

== Savez-vous planter les choux ? ==

Les choux peut-être pas mais les ordinateurs je pense que c'est arrivé au moins une fois à chaque lecteur qui lit cet article. Rien de plus énervant qu'un écran qui se fige, le pointeur de souris qui ne se déplace plus, le clavier qui ne répond plus non plus.... Planté ! Ce constat est assez facile à établir mais en trouver la cause reste un problème nettement plus complexe tellement le nombre de causes possibles est important.

Deux solutions : ignorer le problème et relancer le système en se disant que ça « passera », ou alors chercher la cause du problème en essayant de trouver une méthode reproduisant le « plantage » tant redouté.

La première solution fonctionne assez bien mais si l'on à faire à un « vrai » problème de configuration matérielle ou logicielle, on arrivera assez vite à ne plus pouvoir éviter la seconde voire la troisième. J'allais oublier cette troisième solution destinée aux plus riches d'entre vous : changer de matériel. Cette solution coûteuse peut parfois se révéler efficace, parfois pas du tout. A quoi bon changer un composant sans savoir si c'était bien celui-ci qui posait problème ?
Quelque soit la solution retenue, il sera de toute manière nécessaire de localiser la panne pour y apporter la réponse adéquate. Certaines sociétés ou particuliers se sont spécialisés dans ce dépannage ou l'utilisateur est « dépassé » par les événements.

Cet article vous fera, je l'espère, découvrir quelques outils et méthodes pour valider un par un les composants de votre ordinateur. Cela vous permettra j'espère d'être un peu moins dépourvu quand un problème surviendra. L'article reproduira les étapes qu'il faut suivre pour isoler le « fautif ».

== Les causes possibles d'un « plantage » ==

On retrouve deux grandes catégories de pannes provoquant des dysfonctionnements importants sur un système informatique.
* une panne du matériel
* une erreur logicielle au niveau du noyau et des pilotes (drivers)

Il faudra donc être capable de séparer la panne matérielle qui « force » l'ordinateur à entrer dans un mode de fonctionnement non prévu et instable, de l'erreur logicielle qui équivaut à demander à l'ordinateur de faire « n'importe quoi » et qui va donc se « planter ».

Le terme « planté » utilisé ici équivaut à un arrêt du système à cause d'erreurs sévères : instruction illégale ou composants défaillants. Le terme de « plantage » est aussi utilisé pour décrire le fonctionnement d'une application qui se ferme inopinément. Ce cas est plus souvent lié à une erreur de programmation de l'application qu'à une erreur du système. Nous ne parlerons donc pas de ce second cas dans cet article.

== La mémoire qui flanche ? ==

Une cause « classique » des dysfonctionnements se situe au niveau de la gestion de la mémoire de votre machine. Je ne parle pas d'allocation mémoire réalisée par votre système d'exploitation favori mais bien de la manière avec laquelle la carte mère configure et utilise vos barrettes de mémoire. Les applications chargent en mémoire des données et des instructions destinées au processeur. Voici un scénario qui peut provoquer l'arrêt de la machine.

Votre application favorite est lancée depuis la ligne de commande ou une interface graphique via un « clic » de souris. Votre système d'exploitation va donc charger ce programme en mémoire puis en exécuter les instructions. Au plus bas niveau de votre système, le processeur exécute des instructions en langage machine (assembleur) présente en mémoire.
Malheureusement, votre mémoire est défaillante et elle n'arrive pas à maintenir un état stable des informations qui lui sont confiées. Par exemple, la lettre C est représentée par le code 67, ou « 1000011 » en binaire. Si la zone mémoire change d'état, alors le contenu de la valeur stocké à cet endroit changera : on pourrait se retrouver avec « 1000010 ». Un seul bit a changé, mais on passe de la lettre 'C' (67) à la lettre 'B'(66). Le résultat ne se fait pas attendre, le processeur se retrouve à exécuter des instructions qui n'ont plus de sens, provoquant l'arrêt de la machine.

Les pannes de mémoires sont généralement dues à des composants endommagés, des barrettes incompatibles ou un « timing d'accès » à la mémoire (nommé CAS (Column Address Strobe) dans la plupart des BIOS) trop agressif permettant des lectures dans des zones mémoires avant que les écritures aient eu le temps de se stabiliser pour en garantir le contenu.

Il est assez simple de valider votre configuration mémoire grâce à l'utilitaire memtest (http://www.memtest.org). Cet utilitaire de taille très modeste, 96 Kilo-octets, est écrit en assembleur ce qui lui permet de s'exécuter indépendamment du système d'exploitation. Ceci garantit un test « proche » du matériel, sans sur-couche pouvant apporter d'autres problèmes.
La version 1.65 actuelle est téléchargeable sous deux formes : une iso que l'on peut graver sur un CDRW de préférence vu la petite taille du programme ou sous la forme d'une amorce système (pre-compiled bootable binary). Il suffira de décompresser l'archive puis d'exécuter la commande suivante :
<code>dd if=memtest.bin of=/dev/fda</code>

Ceci écrasera le contenu de votre disquette pour y copier memtest.
Rebootez l'ordinateur avec la disquette placée dans le lecteur, memtest devrait se lancer.

[[Image:memtest.jpg]]

La figure ci-dessus, est une capture d'écran de memtest en fonctionnement. Le barre de progression principale affichée en haut à droite de l'écran (2% dans cet exemple) permet de suivre la progression du test. Les erreurs apparaissent dans la partie inférieure de l'écran. Il suffit de laisser fonctionner memtest au moins une fois jusqu'à 100%. Si aucune ligne ne s'est affichée alors vou pouvez considérer que la mémoire est fonctionnelle. Dans le cas contraire, il faudra soit procéder à son remplacement s'il s'agit d'une seule barrette mémoire, soit tester les barrettes indépendamment (l'une puis l'autre) avec ce logiciel. Dans le cas de 2 ou 3 barrettes qui ne fonctionnement pas correctement ensemble mais qui fonctionnement correctement individuellement, il faudra vérifier qu'elles sont bien de même modèle/marque et remettre le Bios dans une configuration initiale.

Votre mémoire est bonne ? Testons les autres composants de votre machine pour traquer la source de ce plantage.

== Il ne fait pas un peu chaud là ? ==

Ces dix dernières années la puissance consommée et dissipée par nos ordinateurs a littéralement explosé ! Du 486 qui ne nécessitait quasiment pas de ventilateur, on est arrivé à des stations de travail/jeu avec des alimentations pouvant atteindre 1KiloWatt pour les dernières et 500watt pour des modèles plus « grand public ». Le processeur est un des composants gourmands de la machine. Certains modèles peuvent consommer plus de 130W ! Autant dire que si le système est mal ventilé, la montée en charge du processeur peut provoquer un échauffement important provoquant une surchauffe de celui-ci. S'il dépasse ces caractéristiques de fonctionnement, il va alors exécuter du code incorrect provocant un plantage du système.

Un bon test pour vérifier que votre processeur n'est pas la cause de votre instabilité : commencez par relever la température de votre machine au repos à l'aide des informations fournies soit par l'acpi soit pas lm_sensors.

<code>[erwan@R1 ~]$ cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 42 C
[erwan@R1 ~]$

[root@konilope ~]# sensors | grep Temp
M/B Temp: +39°C (low = +15°C, high = +40°C) sensor = thermistor
CPU Temp: +127°C (low = +15°C, high = +45°C) sensor = thermistor
Temp3: +44°C (low = +15°C, high = +45°C) sensor = thermistor
[root@konilope ~]</code>

La méthode utilisant lm_sensors nécessite une interprétation de la part de l'utilisateur. Dans cet exemple, il apparaît évidant que le processeur ne peut avoir une température de fonctionnement aussi élevée (127°C). L'erreur est du à un mauvais calcul de la part de lm_sensors. Il se base sur le type de capteurs thermiques utilisé par la carte mère pour calculer la température des différents composants. Malheureusement, le montage électrique autour du capteur de température peut varier d'un modèle de carte à un autre, ce qui fausse les calculs. On considéra donc, que pour cette machine (konilope) sa température se situe aux alentours de 42° : valeur moyenne entre les deux valeurs « cohérentes » relevées par lm_sensors. On pourra cependant vérifier cette approximation en relevant la température du disque sur à l'aide de smartmontools.

<code>[root@konilope ~]# smartctl -A /dev/hda | grep Temperature
194 Temperature_Celsius 0x0022 042 052 000 Old_age Always - 42
[root@konilope ~]# </code>

De manière générale, il est préférable de maintenir sa machine en dessous des 55° et celle de son processeur en dessous de 70°C. Au delà, le système risque d'être instable. Si ce n'est pas le cas, effectuez les modification nécessaire pour y parvenir : meilleure ventilation du processeur ou du boîtier par exemple.

Ensuite, téléchargez l'utilitaire cpuburn depuis un mirroir (http://pages.sbcglobal.net/redelm/cpuburn_1_4_tar.gz) ou depuis votre distribution linux favorite (oui, oui, urpmi cpuburn ça fonctionne ;o)).

Vous y trouverez plusieurs programmes nommés burnXX ou XX représente votre processeur. La version P6 sera à utiliser sur les processeurs Intel Pentium 4, la version K7 pour les processeurs Athlon x86. Pour les processeurs plus récents, utilisez la version P6.
Ce logiciel réalise des boucles en langage assembleur ayant pour but de stresser votre processeur de manière importante et donc le faire chauffer. Lancez cpuburn autant de fois que vous avez de processeur sur votre machine puis observez la température de votre machine. Si lors de la montée en température votre système se fige, alors vous avez un problème de thermie. Si cpuburn ne fait pas planter votre ordinateur au bout de 10mn, vous pouvez considérez que votre système est stable de ce coté là. Vous pouvez aussi utiliser ce test pour vérifier que vos ventilateurs d'ordinateurs portable se déclenchent bien en cas de surchauffe.
Sur un portable récent, on obtient le résultat suivant au bout de quelques minutes de cpuburn.

<code>[root@R1 ~]# cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 80 C
[root@R1 ~]# </code>

Malgré la température très élevée du processeur, le système est resté stable ce qui permet de valider qu'il est capable d'encaisser une montée en température élevée. Bien entendu, plus votre machine sera « chaude » plus elle s'usera rapidement. Il ne faut pas oublier que les autres composants peuvent souffrir de la chaleur dégagée par le processeur par exemple : les disques durs en sont un bon exemple car les plateaux ne supportent pas la chaleur.
Ce test est bon aussi ? A priori, les composants de base de votre système sont en bon état, vous pouvez commencer à regarder du coté configuration logicielle.

== APIC es tu là ? ==

Le manque de stabilité peut aussi s'expliquer par la gestion des interruptions.
L'architecture PIC (Programmable Interrupt Controllers) représentée par la famille de composants Intel 8259, permettait une gestion de 8 interruptions pour un unique processeur. On les associe par 2 pour obtenir les 16 niveaux d'interruptions nécessaire depuis nos vieux 80286 (milieu des années 80). Avec l'arrivée des systèmes multi-processeurs, l'architecture APIC (Advanced Programmable Interrupt Controllers) (Intel 82093) à été ajoutée pour permettre une gestion plus fine des interruptions. En effet, dans un contexte multi-processeurs, il est nécessaire de pouvoir choisir quel processeur traitera quelle interruption pour ne pas rester figé dans l'ancien modèle (PIC) où le processeur de « boot » est assigné à un ensemble d'interruptions.

De plus, l'architecture APIC apporte une gestion de 24 interruptions, une gestion de priorité des interruptions et le routage de l'interruption sur le bon processeur, contre un simple routage de 2*8 interruptions dans le modèle PIC sur un seul processeur. Depuis une dizaine d'années, Intel propose le modèle APIC comme nouvelle architecture, y compris pour les systèmes mono-processeurs. Les ordinateurs récents, y compris les portables, sont maintenant équipés uniquement de composants APIC même si l'on peut obtenir un comportement de type PIC avec ceux-ci.

L'architecture APIC est constituée d'un ou plusieurs composants situé physiquement dans le southbridge (IO-APIC), généralement un par bus, et un composant situé dans le processeur : le Local APIC (LAPIC). Le LAPIC va permettre la gestion des interruptions au niveau du processeur local. Il permet aussi de générer des interruptions par exemple pour transmettre des interruptions à des processeurs voisins dans le contexte d'un système multi-processeurs, ces messages sont appelés IPI (Inter Processor Interrupts).

De plus le Local APIC (LAPIC) inclut un « timer » de précision cadencé à la fréquence du bus, généralement il peut être utilisé par l'ordonnanceur de votre système d'exploitation favori ou d'autres outils de haut niveau (profiler kernel : oprofile, vtune). Les LAPIC et l'IO-APIC sont reliés par un bus spécifique pour permettre un échange rapide des informations.

Schema logique d'implémentation :

[image:acpi.jpg]

Les IO-APIC vont donc se charger de collecter les interruptions provenant des périphériques systèmes et d'en assurer le transfert vers le ou les processeur(s) suivant une route préalablement programmée par le BIOS et/ou le système d'exploitation.

Cependant, l'implémentation des APIC dans les BIOS peut provoquer certaines instabilités sur votre système Linux. Par expérience, il n'y a pas de règle pour trouver la configuration qui peut aider votre machine à se stabiliser car cela dépend de chaque machine. Des différences peuvent même exister entre deux versions de BIOS d'un même ordinateur. Cependant, dans la série 2.6 du noyau Linux et les version 2.4 récentes nous disposons d'outils permettant de re-paramétrer cette configuration en activant/désactivant les IO-APIC ou les LAPIC.

Chaque composant possède un activateur ou un inhibiteur, on aura donc d'un coté « apic » et « noapic » pour la gestion des IO-APIC, « nolapic » et « lapic » de l'autre pour la gestion des LAPIC. Ces 4 options sont à utiliser sur la ligne de commande du noyau, c'est à dire au moment où le « bootloader » (lilo ou grub par exemple) va charger le noyau en mémoire. L'utilisation de « apic » et « lapic » permet d'activer ces composants qui ne l'ont pas été par le BIOS. L'activateur « apic » n'est disponible que les architectures de type x86_64 car celui-ci est déjà activé sur les systèmes de type x86. On désactivera les APIC dans le cas où le système affiche des messages d'erreurs sur les APIC comme :

<code>« APIC error on CPU0: 40(40) »</code>

ou

<code>MP-BIOS bug: 8254 timer not connected to IO-APIC
failed.
timer doesn't work through the IO-APIC - disabling NMI Watchdog!</code>

La désactivation des IO-APIC permet par exemple de corriger le comportement parfois récalcitrant de certaines cartes vidéos qui ne parviennent pas à afficher correctement en mode 2D/3D (écran noir par exemple).

La non activation des LAPIC peut avoir comme conséquence un dysfonctionnement de l'ACPI (gestion d'énergie avancée). Ce cas est traité par le noyau, vous retrouverez dans les messages de démarrage la ligne suivante : « "Local APIC disabled by BIOS you can enable it with lapic ».

Pour résumer, si votre machine, en général à architecture mono-processeur, a tendance à se bloquer lors de l'utilisation de périphériques tels que le port usb, la carte graphique ou la carte son, essayez de désactiver le LAPIC puis l' IO-APIC puis les 2. Pour exemple, les cartes mère A7N8X de chez Asus ont largement tendance à se bloquer si l'on ne spécifie pas « nolapic » lors du boot. Sur certaines machines, il faudra faire le contraire à savoir forcer l'activation des LAPIC. Ceci dépendra de votre machine et de sa conception.

== A vos marques, rebootez ! ==

Certains machines peuvent présenter quelques soucis pour redémarrer. Encore une fois, on retrouve au coeur de ce problème l'interaction entre le noyau et le matériel notamment l'ACPI. Les ordinateurs portables dont le modèle HP nc6120 ont par exemple le bon goût de rester bloqués sur le message « No reboot fixup found for your hardware ». Ceci indique que le noyau ne connaît pas de contournement pour ce matériel (ce qui est le cas de la quasi totalité des ordinateurs) mais puisque vous voyez ce message c'est que votre machine n'a pas réussi à rebooter. Heureusement, il existe des contournements pour permettre un redémarrage plus « bas niveau ». Le noyau défini les modes suivants : « b » « c » « h » « s » et « w ».
Le mode de reboot peut être défini sur la ligne de commande du noyau suivant la forme « reboot=<mode> ». Le mode « s » est réservé au systèmes multi-processeurs, elle va réinitialiser chacun des processeurs.

Le mode « b » permet quant à lui de rebooter en faisant un appel direct au bios qui se chargera de faire redémarrer la machine. Ce mode fonctionne plutôt bien car dans le cas d'un BIOS posant problème sur l'ACPI, on peut espérer avoir un reboot correct. C'est le cas sur de notre portable cité précédement.

Le mode « h » se chargera de faire redémarrer la machine en réinitialisant le processeur. C'est l'équivalent du mode « s » pour les environnements mono-processeurs. Pour finir, les modes « c » et « w » correspondent aux modes « cold » et « warn » : ces modes sont plus connus sous le nom de « reboot à froid » et « reboot à chaud ». Le premier effectuera les tests de mémoire tandis que le second exécutera un reboot plus court.

De manière générale, on utilisera plutôt le mode « b » ou « h » pour les systèmes mono-processeurs récalcitrant et le mode « s » pour les systèmes multi-processeurs.

== Toujours plus de performance ==
Votre configuration est bien stable depuis un certain temps. Toutefois vous trouvez qu'elle est un peu lente, elle ne vous donne pas satisfaction par rapport à ce qu'elle devrait fournir.
Cette partie de l'article va explorer comment vérifier et corriger les problèmes de performance des différents composants.
Note: certaines configuration mono-processeur nécessitent de désactiver LAPIC (nolapic)

=== Le disque dur ===

Il arrive parfois que le disque dur semble un peu lent et pénalise le système dans son ensemble. Hdparm est là pour vous aider à y voir plus clair. Hdparm est à l'origine conçu pour les systèmes de disques IDE de type PATA. Le nouveau système de disque SATA, ne permet pas toujours en fonction de l'implémentation, l'appel à toutes ces astuces. Cependant les nouvelles séries de kernel à partir du 2.6.15 devrait permettre une gestion plus unifiée des systèmes de disques PATA et SATA.

Le test « hdparm -t /dev/<mon_device> » permet de tester la vitesse de lecture depuis le disque dur jusqu'en mémoire. Une valeur de 25Mo/sec est un minimum pour des machines récentes. Plusieurs paramètres peuvent influencer les performances d'un disque IDE.
La commande « hdparm -cd » permet de vérifier que les entrées/sorties sont réalisées en 16-bit (le mode 32-bit n'offre pas de performance supplémentaire) alors que le DMA (Direct Memory Access) est activé. Ceci permet la minimisation de l'utilisation du processeur pendant les accès au disque dur.

<code>[root@R1 ~]# hdparm -cd /dev/hda
/dev/hda:
IO_support = 0 (default 16-bit)
using_dma = 1 (on)
[root@R1 ~]# </code>

La commande « hdparm -c0d1 /dev/<mon_device> » permet de configurer le périphérique dans ce mode. Le noyau de votre distribution Linux devrait le réaliser de manière automatique.

L'option « -I » permet d'obtenir plus d'informations sur la configuration de votre disque dur.

<code>[root@R1 ~]# hdparm -I /dev/hda
/dev/hda:
ATA device, with non-removable media
Model Number: FUJITSU MHT2040AT
Serial Number: NN77T3C13KB9
Firmware Revision: 0022
Standards:
Used: ATA/ATAPI-6 T13 1410D revision 3a
Supported: 6 5 4 3
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 78140160
device size with M = 1024*1024: 38154 MBytes
device size with M = 1000*1000: 40007 MBytes (40 GB)
Capabilities:
LBA, IORDY(cannot be disabled)
bytes avail on r/w long: 4 Queue depth: 1
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 128 (0x80)
Recommended acoustic management value: 254, current value: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
* Look-ahead
* Write cache
* Power Management feature set
Security Mode feature set
* SMART feature set
* Mandatory FLUSH CACHE command
* Device Configuration Overlay feature set
* Automatic Acoustic Management feature set
* SET MAX security extension
Power-Up In Standby feature set
* Advanced Power Management feature set
* DOWNLOAD MICROCODE cmd
* SMART self-test
* SMART error logging
Security:
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase
40min for SECURITY ERASE UNIT.
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct
[root@R1 ~]#</code>

On y retrouve le modèle, le numéro de série et la version du firmware qui peuvent être utiles en cas de contact avec le Service Après-Vente ou de mise à jour pour une série de firmwares défaillante.

La ligne commençant par « DMA » dans la partie « Capabilities » permet d'afficher la vitesse de transfert négociée entre le disque dur et le driver IDE de Linux. L'étoile précède la valeur actuelle. Dans cet exemple, le mode udma5 est sélectionné : ceci est conforme aux machines disponibles sur le marché depuis environ 3 ans.

Pour rappel, voici le tableau de conversion entre le mode DMA et la vitesse maximale associée.

Type de fonctionnement
Vitesse Maximale en MO/sec
UltraDMA 0
16,6
UltraDMA 1
25
UltraDMA 2
33,3
UltraDMA 3
44,4
UltraDMA 4
66,6
UltraDMA 5
100
UltraDMA 6
133,33

Une configuration actuelle ne devrait pas être en dessous de UDMA5. Si ce n'était pas le cas, on peut essayer de renégocier la vitesse de transfert à l'aide de la commande :

<code>hdparm -X udma5 </code>

Celle-ci permet de forcer le mode UltraDMA5. Il faut utiliser cette commande avec précaution car elle pourrait générer des pertes ou de la corruption de données en cas de transfert pendant ce changement de mode.

Vous pouvez aussi impacter les performances de votre disque dur en modifiant sa vitesse de rotation. Cette fonctionnalité connue sous le nom de Automatic Acoustic Management (AAM) est utilisable avec l'option « -M » de hdparm. La valeur 128 représentera la vitesse la plus faible avec un disque silencieux, la valeur 254 la vitesse la plus élevée mais avec comme contre-partie un disque plus bruyant. On pourra noter des différences de quelques Mo/sec selon les configurations.

Il est aussi à noter que l'utilisation de logiciels permettant une meilleure gestion d'énergie (cpufreq, laptop-mode) peut dégrader les performances d'un disque dur de manière notable.

=== Configuration bas niveau du réseau ===

Le réseau local filaire peut parfois être un peu lent. Voici quelques tests pour vérifier si la lenteur provient du logiciel, du noyau ou du matériel. Tout d'abord, explorons la trousse à outils indispensable pour analyser votre carte réseau : ethtool. Digne successeur de mii-tool, il permet de s'informer sur la configuration de votre carte réseau.

Il suffit de lancer « ethtool <votre_interface> » » pour obtenir la configuration matérielle de votre carte. On y retrouve les modes supportés par votre carte (Supported Link Modes ainsi que la vitesse actuelle (Speed), obtenue par auto-négociation dans cet exemple.

On peut également savoir si le câble réseau est connecté à la carte grâce à la ligne « Link Detected ». Le type de « duplex » utilisé permet également de savoir si la négociation avec l' élément actif au bout de votre câble (commutateur, concentrateur ou une autre machine) a correctement fonctionné. Le duplex définit le mode de transmission : le mode half-duplex indique que l'on émet puis on reçoit des données, le mode full-duplex indique que l'on peut émettre et recevoir en même temps des données. Le mode full-duplex est donc plus que recommandé pour vos équipements réseaux.

<code>[root@konilope ~]# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Current message level: 0x000020c1 (8385)
Link detected: yes
[root@konilope ~]# </code>

=== Mesurer les {contre}performances de votre réseau ===

Une fois vérifiée la bonne configuration de votre matériel, nous pouvons passer à la vérification des performances entre deux machines.

L'utilitaire netpipe (http://www.scl.ameslab.gov/netpipe/) permet de réaliser des tests de performance mais aussi d'intégrité entre deux machines. Il permet de tester les performances du réseau au travers la couche IP et non pas depuis un mode plus bas niveau comme pourrait l'être un test utilisant directement le driver Ethernet. Ce test permet donc de valider que la configuration matérielle mais aussi logicielle est correcte.

Sur la première machine, exécutez « NPtcp » : netpipe se positionne en mode « serveur ».
Sur la seconde machine, exécutez « NPtcp -h <machine1> » : netpipe se connecte au serveur netpipe de la machine nommée machine1 pour effectuer le test de performance.

Le test par défaut teste les communication allant de 1 octet jusqu'à 8 Mo. Il peut prendre plusieurs minutes si le réseau est « lent ». Le test va montrer pour chaque taille de paquet la performance obtenue. Il est normal d'obtenir des performances faibles pour des paquets d'une taille inférieure à 8 Ko. Transporter des petits paquets nécessite de réaliser beaucoup d'opérations pour le processeur pour une quantité d'information minime. Les performances seront meilleures à partir d'environ 16 Ko et maximales à partir de 128 Ko. Sur un système utilisant du gigabit ethernet, on constatera une performance de 39Mbps à 256 octets, 287Mbps à 4Ko, 614Mbps à 16Ko, 845Mbps à 128Ko, 895Mbps à 8Mo.

Vous pouvez ainsi vérifier et comparer facilement les performances de votre configuration réseau. Netpipe permet également de tester la vitesse du réseau pour une taille de paquets définie entre la taille indiqué par l'option « -l » et la taille indiquée par l'option « -u ». Ainsi, NPtcp -l 16384 -u 16384 permet de tester la bande passante réseau pour une taille de paquet égale à 16Ko.

L'option « -n <nb-cycle> » permet de définir le nombre de boucles à réaliser pour le test (50 par défaut). Enfin, pour réaliser des tests « full-duplex », on utilisera l'option « -2 ». Ce test permet de s'assurer du bon fonctionnement du mode de communication permettant l'écriture et la lecture simultanées.

Attention, même si ce test donne de bons résultats, cela ne veut pas dire que la configuration est exempte d'erreur de configuration. Par exemple, les performances réseaux peuvent être très bonnes en point à point mais mauvaises lorsque l'on aura une charge réseau avec plusieurs clients. Dans cette situation, il faut vérifier que le contrôle de flux est bien activé sur toutes les machines. L'option « ethtool -a » permet de vérifier que les champs « rx » et « tx » sont placés sur « on ». Si ce n'était pas le cas activez-les avec la commande « ethtool -A eth0 rx on » et « ethtool -A eth0 tx on ».

Les cartes réseaux, des serveurs essentiellement, permettent maintenant de réaliser le « tcp segment offload ». Cette technique permet de décharger une partie du traitement TCP directement dans l'électronique de la carte réseau. Ceci à pour effet de décharger le processeur central d'un traitement fastidieux. L'option « -k » d'ethtool permet de consulter l'état de cette fonctionnalité (off/on). On pourra l'activer sur des serveurs générant un gros trafic réseau par exemple : « ethtool -K eth0 tso on ».

Vous voilà maintenant équipé de nouveau outils pour traquer la perte de performances de votre installation réseau. Ceci couplé aux habituels tcpdump/ethereal, voilà une belle panoplie du zorro du réseau.

=== Quand la latence s'en mêle ===

La latence représente le temps nécessaire à un système pour prendre en compte un événement.

Il arrive que certains périphériques de votre machine nécessitant des débits importants ou une latence assez faible sur le bus PCI soient « poussifs ». On retrouve dans cette catégorie les cartes vidéos accélératrice 3D, les cartes son et les cartes d'acquisition firewire ou DVB (récepteur de télévision numérique terrestre : TNT).

Un périphérique branché sur le bus PCI doit attendre que le bus soit libre pour émettre les données vers la mémoire centrale. Le bus PCI qui est le coeur de communication des périphériques est donc soumis en permanence à un arbitrage qui permet de décider qui doit émettre des données et qui doit attendre. Cet arbitrage est en partie réalisé grâce au « latency_timer ».

Chaque périphérique possède une valeur de « latency_timer » comprise en 0 et 248 cycles d'horloge du bus. Plus la valeur sera importante plus le périphérique disposera de temps pour transmettre des informations. Une latence de 248 cycles permet d'obtenir une priorité forte sur le bus, ce qui permet un débit important. A contrario, une latence de 0 indiquera au périphérique qu'il doit cesser ses transmissions si un autre composant à besoin du bus : ceci se traduira par une perte de bande passante importante.

La configuration réalisée par défaut sur votre machine doit être correcte mais il peut arriver qu'une carte 3D ou DVB soit configurée avec une latence trop faible, ce qui aurait pour conséquence d'offrir une image saccadée et peu fluide. Une carte son offrirait également le même type de symptômes avec un son hâché ou excessivement métallique.

Heureusement, une série d'outils est là pour vous aider à diagnostiquer le problème mais aussi à le résoudre. Le projet pciutils (http://atrey.karlin.mff.cuni.cz/~mj/linux.shtml#pciutils) contient deux outils indispensables: lspci et setpci. Bien entendu, votre distribution favorite devrait posséder ce logiciel, il vous suffira de l'installer avec votre gestionnaire de paquet favori (urpmi, apt, smart).

La commande « lspci » vous permet de lister les périphériques PCI disponibles sur votre ordinateur (cf article paru dans le numéro 68). Cet exemple se basera sur une carte vidéo ayant pour adresse sur le bus PCI « 01:00.0 ».

<code>[root@lagirafe] lspci -v -s 01:00.0
01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX Go5200 32M/64M] (rev a1) (prog-if 00 [VGA])
Subsystem: Samsung Electronics Co Ltd: Unknown device c00f
Flags: bus master, 66Mhz, medium devsel, latency 16, IRQ 11
Memory at c8000000 (32-bit, non-prefetchable) [size=16M]
Memory at d8000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 3.0
[root@lagirafe]</code>

On retiendra dans cette ligne, la valeur 'latency 16'. Ceci risque de poser problème lorsque celle-ci aura besoin d'un fort débit pendant un jeu par exemple. Augmenter la latence va donc se révéler nécessaire pour ce périphérique.

La commande setpci permet de modifier les paramètres PCI d'un périphérique ou d'un bus complet avec tous ses périphériques.

La commande « setpci -v -d 01:* latency_timer=20 » permet de positionner tous les périphériques du bus 01 à une valeur de 32 cycles. Il est à noter que la commande setpci utilise des valeurs en hexadécimal mais lspci affichera les valeurs en décimal.

Pour en revenir à nos moutons, la correction de la latence de cette carte graphique se fera avec la commande « setpci -v -d 01:00.0 latency_timer=f8 ». Ceci positionne donc la carte sur la plus grande valeur de latence possible, ce qui lui garantira la plus grande bande passante possible. Il est possible d'utiliser la valeur « ff » comme paramètre pour « latency_timer » mais celui-ci sera converti à la volée par la commande setpci en « 0xf8 ».

Attention, certains composants de votre machine doivent rester en « latency_timer=0 » pour garantir une bon fonctionnement de votre système : il ne faudra donc pas modifier les latences des contrôleurs mémoire et des ponts PCI connectés généralement sur le bus « 0:* ».

== DSDT : le cauchemar continue ! ==

Cette partie de l'article a pour but d'expliquer le problème que peut représenter la table DSDT pour un certain nombre de machines et surtout les ordinateurs portables.

La norme ACPI 3.0 de Septembre 2004 disponible gratuitement à l'adresse http://www.acpi.info/DOWNLOADS/ACPIspec30.pdf définit la DSDT comme une table remplie par un OEM permettant au système d'exploitation de découvrir les ressources pour la gestion de l'énergie avancée, de la gestion thermique ainsi que la gestion du Plug'nPlay des ressources définies par l'ACPI.

Voici une description certes un peu théorique mais nécessaire pour bien comprendre la problématique et ses conséquences. Le constructeur de l'ordinateur doit donc définir dans le BIOS une table contenant une liste de ressources et leurs configuration et ce pour que le système d'exploitation puisse s'en servir. Noble cause n'est il pas ? Tout au long des 618 pages de ce document sont spécifiés les éléments du langage à utiliser ainsi que sa syntaxe. L' « ACPI Source Language » permettra donc aux développeurs d'écrire des DSDT puis de les compiler dans un format nommé « ACPI Machine Language » en utilisant un compilateur adéquat. Le système d'exploitation utilisera la table compilée (AML) pour accéder aux ressources ACPI.
Sur la plupart des ordinateurs portables, la table DSDT ne respecte pas la norme ACPI dans sa syntaxe. Ceci est très gênant car cela bloque le code de l'interpréteur ACPI du noyau Linux qui essaie de la lire. Le résultat est sans appel, pas d'ACPI, pas de gestion d'énergie avancée, plus de ventilation automatique sur certains modèles d'ordinateurs, plus de touche de gestion de contraste/luminosité sur d'autres etc...

Ceci est très gênant sur un ordinateur portable. Alors que faire ? Dans un premier temps, prévenir le constructeur que son BIOS est incorrect et ne respecte pas la norme ACPI. La réponse se fait toujours attendre pour tous ceux qui « osent » poser la question au support technique : à savoir, les constructeurs ignorent tout simplement les mails de ce type.
La seconde étape puisque vous êtes devant le fait accompli d'une machine non conforme, il va falloir corriger cette table. Il suffit de récupérer la table actuelle via la commande 'cat /proc/acpi/dsdt > dsdt.aml' si vous avez la chance d'avoir un répertoire /proc/acpi malgré une table DSDT endommagée, sinon utilisez la commande 'acpidump -b -t dsdt -o dsdt.aml'. La commande acpidump est fournit dans le projet pmtools (ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20050926.tar.bz2)
Vous avez donc extrait la table DSDT de votre système. Il ne reste plus qu'à essayer de la recompiler. Pour cela, le compilateur IASL de la société Intel (http://developer.intel.com/technology/iapc/acpi/downloads.htm) offre sous Linux et Windows une plate-forme de compilation pour le langage ASL.

Suivez les instructions du site pour télécharger et compiler la version unix d'iasl. Ensuite, décompilez la table avec la commande « iasl -d dsdt.aml ». Le fichier dsdt.dsl vient d'être créé par le décompilateur. Il suffit de le recompiler avec la commande « iasl -tc dsdt.dsl » pour constater les dégâts ! La DSDT que vous avez dans votre BIOS est généralement compilée par le compilateur de Microsoft qui semble autoriser une syntaxe plus qu'approximative.
Si vous avez de la chance, votre DSDT s'est recompilée sans erreurs, vous obtenez donc un fichier dsdt.hex et un fichier dsdt.aml. Il ne reste plus qu'à injecter cette dsdt dans le noyau Linux et le tour sera joué.

Si vous avez moins de chance, votre DSDT est syntaxiquement incorrecte et génère des erreurs. Les expliquer plus en détails nécessiterait un article complet, il ne sera cité que les plus « habituelles » (sic).

<code>dsdt.dsl 2626: Field (ECR, DWordAcc, Lock, Preserve)
Error 1048 - ^ Host Operation Region requires ByteAcc access </code>

Cette erreur présente à ligne 2626 du fichier dsdt.asl indique une erreur de type dans la déclaration du champ ECR. Il suffit dans ce cas de changer le mot « DWordAcc » par « ByteAcc ». Celle-ci reste assez simple à corriger, on se demande donc pourquoi les constructeurs ne prennent pas le temps de vérifier et de corriger leur BIOS.

<code>dsdt.dsl 2672: Method (_GLK, 1, NotSerialized)
Warning 2024 - ^ Reserved method has too many arguments ( _GLK requires 0) </code>

La méthode _GLK n'a besoin que de 0 paramètre tandis que ce code en utilise 2 ! La correction est assez simple : il suffit de remplacer la ligne 2672 par « Method(_GLK) ».

Pour plus de détails sur la correction des erreurs de compilation de votre table dsdt, je vous recommande les tutoriaux disponibles depuis la page http://acpi.sourceforge.net/dsdt/index.php du projet ACPI.

Votre DSDT est compilée avec succès, il ne vous reste plus qu'à l'ajouter pour que votre noyau puisse l'utiliser à la place de celle fourni par le BIOS (modifiable uniquement par le constructeur, via une mise à jour).

Il existe trois possibilités pour inclure une table DSDT : la modification du noyau Linux ( noyau < 2.6.9), l'injection de la DSDT dans la configuration du noyau (noyau >= 2.6.9), l'intégration de la table DSDT dans l'initrd qui nécessite un patch kernel disponible à l'adresse http://gaugusch.at/kernel.shtml.

Pour les noyaux 2.6.9 et supérieur, copiez votre fichier dsdt.hex sous le nom «/usr/src/linux/include/acpi/dsdt_table.h » puis reconfigurez votre noyau.
Insérer « dsdt_table.h » dans l'option « Include you custom DSDT » disponible dans le menu « Power Management/ACPI/ ». Recompilez votre noyau et redémarrez avec votre nouveau noyau.
Pour les noyaux inférieurs à 2.6.9, il est possible de modifier le code source de votre noyau pour intégrer votre DSDT mais il est préférable d'utiliser le patch permettant l'insertion de la table DSDT dans l'initrd. Recompilez votre noyau avec ce patch, puis suivez la procédure décrite ci-dessous.

Certaines distributions Linux comme « Mandriva Linux » possèdent le patch qui permet de n'avoir qu'à reconstruire l'initrd avec la commande « mkinitrd –dsdt=/boot/dsdt.aml /boot/initrd-`uname -r`.img `uname -r` » puis de relancer lilo avant de redémarrer votre machine. Lors du démarrage de celle-ci vous devriez voir le message suivant :

<code>ACPI: Looking for DSDT in initrd... found (at offset 0x4f8d9).
ACPI-0294: *** Info: Table [DSDT] replaced by host OS</code>

Vous voilà maintenant avec une table DSDT correcte et un ACPI fonctionnel. La question qui reste ouverte est pourquoi les constructeurs n'utilisent pas un compilateur digne de ce nom pour permettre à leur clients de pouvoir utiliser d'autres systèmes d'exploitation que Windows de Microsoft.

Pour la petite histoire, si vous cherchez dans votre dsdt vous risquez de tomber ce genre de lignes :

<code>If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), Zero))
If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))
If (LEqual (SCMP (\_OS, "Microsoft WindowsME: Millennium Edition"), Zero))
If (LEqual (SizeOf (\_OS), 0x27)) </code>

Lorsque qu'un système d'exploitation souhaite utiliser les ressources ACPI du BIOS, il utilise son nom de système d'exploitation (acpi_os_name). On retrouve donc dans les bios des parties qui ne seront exécutées que pour certains systèmes d'exploitation de Microsoft. On retrouve même certains tests où c'est la longueur du nom qui compte...... Ceci prouve bien que les constructeurs d'ordinateurs savent corriger des tables DSDT pour les systèmes d'exploitation mais pas forcément pour le notre malheureusement. Depuis le noyau 2.6.9, le noyau Linux utilise « Windows NT » comme « acpi_os_name » pour assurer une meilleure compatibilité matérielle dixit Len Bron d'Intel dans le changelog de cette version.

== Comment trouver le pilote qui va avec votre matériel ? ==

Cette question on se la pose souvent mais uniquement lorsque l'on essaye de brancher un nouveau périphérique sur sa machine. Les distributions récentes permettent de détecter automatiquement votre matériel et de lui associer un pilote avec sa configuration. Ce mécanisme fonctionne plutôt bien mais cela n'évite pas les dysfonctionnements voir l'absence de fonctionnement.

Pour vérifier si votre noyau Linux est capable de supporter un nouveau périphérique PCI par exemple, il suffit d'en récupérer les identifiants PCI (constructeur et produit) puis de les rechercher dans le fichier « /lib/modules/`uname -r`/modules.pcimap » qui est auto-généré lors de la commande depmod.

L'utilitaire « lspcidrake -v » vous permet de trouver les identifiants PCI de votre carte, la commande « lspci » vous permet de trouver le nom de votre périphérique puis faites un « lspci -n » pour en trouver la correspondance numérique. On utilisera la position du périphérique sur le bus pour retrouver la correspondance numérique « 02:05.0 » dans cet exemple.
<code>[root@pumphome] lspci
[....]
02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01)
[root@pumphome] lspci -n
[...]
02:05.0 Class 0200: 14e4:4401 (rev 01)
[root@pumphome]</code>

Ainsi cette carte réseau possède les identifiants 14e4 (constructeur) et 4401 (produit). Il suffit de rechercher cette valeur dans le modules.pcimap, ce qui nous donnera la correspondance en module (pilote).

<code>[root@pumphome] grep "0x000014e4 0x00004401" /lib/modules/2.6.12-12mdk-i686-up-4GB/modules.pcimap
b44 0x000014e4 0x00004401 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
bcm4400 0x000014e4 0x00004401 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0</code>

On voit ici que cette carte peut utiliser le driver b44 ou le driver bcm4400. On ne trouve pas toujours les identifiants PCI de produit sous leur forme directe, on peut également trouver « 0Xffffffff » qui indique que tous les cartes du constructeur sont gérées par un module.
Il ne vous restera plus qu'à effectuer la configuration associée à ce périphérique pour qu'il fonctionne correctement.

== Conclusion ==

La fin de cet article conclut une toute petite série de deux articles ayant pour but de vulgariser l'architecture de nos machines, de découvrir les outils disponibles pour mieux comprendre leur configuration et au besoin régler les problèmes de configuration matérielle qui ont souvent le don de nous pourrir la vie.

Merci à LaurentJ de #Mandrivafr pour ses tests complémentaires sur les problèmes d'IO-APIC. Un énorme merci à Nicolas Planel pour sa relecture pointue et également Anne pour sa patience de girafe à relire et « quaurigé »mes « photes », ainsi qu'à tous ceux qui m'ont aidé à découvrir ce que je restitue dans cet article.

Cet article a été publié dans Linux Magazine France n°78. Il est publié sur Léa avec l'aimable autorisation de l'éditeur.

Découvrez les ressources de votre machine (La suite)

2006-06-11T20:28:20Z

Ennael : /* La mémoire qui flanche ? */

= Découvrez les ressources de votre machine (La suite) =

== Introduction ==

A nouvelle année, nouvelles résolutions ! Paru dans le numéro 68, un premier article dédié à la découverte des outils disponibles pour la récupération des configurations de votre machine promettait une suite. Je vous propose donc de reprendre ce voyage au centre de votre ordinateur.

Cet article sera articulé autour du diagnostic de pannes et des correctifs associés mais aussi de « trucs & astuces » permettant d'optimiser votre configuration.

== Savez-vous planter les choux ? ==

Les choux peut-être pas mais les ordinateurs je pense que c'est arrivé au moins une fois à chaque lecteur qui lit cet article. Rien de plus énervant qu'un écran qui se fige, le pointeur de souris qui ne se déplace plus, le clavier qui ne répond plus non plus.... Planté ! Ce constat est assez facile à établir mais en trouver la cause reste un problème nettement plus complexe tellement le nombre de causes possibles est important.

Deux solutions : ignorer le problème et relancer le système en se disant que ça « passera », ou alors chercher la cause du problème en essayant de trouver une méthode reproduisant le « plantage » tant redouté.

La première solution fonctionne assez bien mais si l'on à faire à un « vrai » problème de configuration matérielle ou logicielle, on arrivera assez vite à ne plus pouvoir éviter la seconde voire la troisième. J'allais oublier cette troisième solution destinée aux plus riches d'entre vous : changer de matériel. Cette solution coûteuse peut parfois se révéler efficace, parfois pas du tout. A quoi bon changer un composant sans savoir si c'était bien celui-ci qui posait problème ?
Quelque soit la solution retenue, il sera de toute manière nécessaire de localiser la panne pour y apporter la réponse adéquate. Certaines sociétés ou particuliers se sont spécialisés dans ce dépannage ou l'utilisateur est « dépassé » par les événements.

Cet article vous fera, je l'espère, découvrir quelques outils et méthodes pour valider un par un les composants de votre ordinateur. Cela vous permettra j'espère d'être un peu moins dépourvu quand un problème surviendra. L'article reproduira les étapes qu'il faut suivre pour isoler le « fautif ».

== Les causes possibles d'un « plantage » ==

On retrouve deux grandes catégories de pannes provoquant des dysfonctionnements importants sur un système informatique.
* une panne du matériel
* une erreur logicielle au niveau du noyau et des pilotes (drivers)

Il faudra donc être capable de séparer la panne matérielle qui « force » l'ordinateur à entrer dans un mode de fonctionnement non prévu et instable, de l'erreur logicielle qui équivaut à demander à l'ordinateur de faire « n'importe quoi » et qui va donc se « planter ».

Le terme « planté » utilisé ici équivaut à un arrêt du système à cause d'erreurs sévères : instruction illégale ou composants défaillants. Le terme de « plantage » est aussi utilisé pour décrire le fonctionnement d'une application qui se ferme inopinément. Ce cas est plus souvent lié à une erreur de programmation de l'application qu'à une erreur du système. Nous ne parlerons donc pas de ce second cas dans cet article.

== La mémoire qui flanche ? ==

Une cause « classique » des dysfonctionnements se situe au niveau de la gestion de la mémoire de votre machine. Je ne parle pas d'allocation mémoire réalisée par votre système d'exploitation favori mais bien de la manière avec laquelle la carte mère configure et utilise vos barrettes de mémoire. Les applications chargent en mémoire des données et des instructions destinées au processeur. Voici un scénario qui peut provoquer l'arrêt de la machine.

Votre application favorite est lancée depuis la ligne de commande ou une interface graphique via un « clic » de souris. Votre système d'exploitation va donc charger ce programme en mémoire puis en exécuter les instructions. Au plus bas niveau de votre système, le processeur exécute des instructions en langage machine (assembleur) présente en mémoire.
Malheureusement, votre mémoire est défaillante et elle n'arrive pas à maintenir un état stable des informations qui lui sont confiées. Par exemple, la lettre C est représentée par le code 67, ou « 1000011 » en binaire. Si la zone mémoire change d'état, alors le contenu de la valeur stocké à cet endroit changera : on pourrait se retrouver avec « 1000010 ». Un seul bit a changé, mais on passe de la lettre 'C' (67) à la lettre 'B'(66). Le résultat ne se fait pas attendre, le processeur se retrouve à exécuter des instructions qui n'ont plus de sens, provoquant l'arrêt de la machine.

Les pannes de mémoires sont généralement dues à des composants endommagés, des barrettes incompatibles ou un « timing d'accès » à la mémoire (nommé CAS (Column Address Strobe) dans la plupart des BIOS) trop agressif permettant des lectures dans des zones mémoires avant que les écritures aient eu le temps de se stabiliser pour en garantir le contenu.

Il est assez simple de valider votre configuration mémoire grâce à l'utilitaire memtest (http://www.memtest.org). Cet utilitaire de taille très modeste, 96 Kilo-octets, est écrit en assembleur ce qui lui permet de s'exécuter indépendamment du système d'exploitation. Ceci garantit un test « proche » du matériel, sans sur-couche pouvant apporter d'autres problèmes.
La version 1.65 actuelle est téléchargeable sous deux formes : une iso que l'on peut graver sur un CDRW de préférence vu la petite taille du programme ou sous la forme d'une amorce système (pre-compiled bootable binary). Il suffira de décompresser l'archive puis d'exécuter la commande suivante :
<code>dd if=memtest.bin of=/dev/fda</code>

Ceci écrasera le contenu de votre disquette pour y copier memtest.
Rebootez l'ordinateur avec la disquette placée dans le lecteur, memtest devrait se lancer.

[[Image:memtest.jpg]]

La figure ci-dessus, est une capture d'écran de memtest en fonctionnement. Le barre de progression principale affichée en haut à droite de l'écran (2% dans cet exemple) permet de suivre la progression du test. Les erreurs apparaissent dans la partie inférieure de l'écran. Il suffit de laisser fonctionner memtest au moins une fois jusqu'à 100%. Si aucune ligne ne s'est affichée alors vou pouvez considérer que la mémoire est fonctionnelle. Dans le cas contraire, il faudra soit procéder à son remplacement s'il s'agit d'une seule barrette mémoire, soit tester les barrettes indépendamment (l'une puis l'autre) avec ce logiciel. Dans le cas de 2 ou 3 barrettes qui ne fonctionnement pas correctement ensemble mais qui fonctionnement correctement individuellement, il faudra vérifier qu'elles sont bien de même modèle/marque et remettre le Bios dans une configuration initiale.

Votre mémoire est bonne ? Testons les autres composants de votre machine pour traquer la source de ce plantage.

== Il ne fait pas un peu chaud là ? ==

Ces dix dernières années la puissance consommée et dissipée par nos ordinateurs a littéralement explosé ! Du 486 qui ne nécessitait quasiment pas de ventilateur, on est arrivé à des stations de travail/jeu avec des alimentations pouvant atteindre 1KiloWatt pour les dernières et 500watt pour des modèles plus « grand public ». Le processeur est un des composants gourmands de la machine. Certains modèles peuvent consommer plus de 130W ! Autant dire que si le système est mal ventilé, la montée en charge du processeur peut provoquer un échauffement important provoquant une surchauffe de celui-ci. S'il dépasse ces caractéristiques de fonctionnement, il va alors exécuter du code incorrect provocant un plantage du système.

Un bon test pour vérifier que votre processeur n'est pas la cause de votre instabilité : commencez par relever la température de votre machine au repos à l'aide des informations fournies soit par l'acpi soit pas lm_sensors.

<code>[erwan@R1 ~]$ cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 42 C
[erwan@R1 ~]$

[root@konilope ~]# sensors | grep Temp
M/B Temp: +39°C (low = +15°C, high = +40°C) sensor = thermistor
CPU Temp: +127°C (low = +15°C, high = +45°C) sensor = thermistor
Temp3: +44°C (low = +15°C, high = +45°C) sensor = thermistor
[root@konilope ~]</code>

La méthode utilisant lm_sensors nécessite une interprétation de la part de l'utilisateur. Dans cet exemple, il apparaît évidant que le processeur ne peut avoir une température de fonctionnement aussi élevée (127°C). L'erreur est du à un mauvais calcul de la part de lm_sensors. Il se base sur le type de capteurs thermiques utilisé par la carte mère pour calculer la température des différents composants. Malheureusement, le montage électrique autour du capteur de température peut varier d'un modèle de carte à un autre, ce qui fausse les calculs. On considéra donc, que pour cette machine (konilope) sa température se situe aux alentours de 42° : valeur moyenne entre les deux valeurs « cohérentes » relevées par lm_sensors. On pourra cependant vérifier cette approximation en relevant la température du disque sur à l'aide de smartmontools.

<code>[root@konilope ~]# smartctl -A /dev/hda | grep Temperature
194 Temperature_Celsius 0x0022 042 052 000 Old_age Always - 42
[root@konilope ~]# </code>

De manière générale, il est préférable de maintenir sa machine en dessous des 55° et celle de son processeur en dessous de 70°C. Au delà, le système risque d'être instable. Si ce n'est pas le cas, effectuez les modification nécessaire pour y parvenir : meilleure ventilation du processeur ou du boîtier par exemple.

Ensuite, téléchargez l'utilitaire cpuburn depuis un mirroir (http://pages.sbcglobal.net/redelm/cpuburn_1_4_tar.gz) ou depuis votre distribution linux favorite (oui, oui, urpmi cpuburn ça fonctionne ;o)).

Vous y trouverez plusieurs programmes nommés burnXX ou XX représente votre processeur. La version P6 sera à utiliser sur les processeurs Intel Pentium 4, la version K7 pour les processeurs Athlon x86. Pour les processeurs plus récents, utilisez la version P6.
Ce logiciel réalise des boucles en langage assembleur ayant pour but de stresser votre processeur de manière importante et donc le faire chauffer. Lancez cpuburn autant de fois que vous avez de processeur sur votre machine puis observez la température de votre machine. Si lors de la montée en température votre système se fige, alors vous avez un problème de thermie. Si cpuburn ne fait pas planter votre ordinateur au bout de 10mn, vous pouvez considérez que votre système est stable de ce coté là. Vous pouvez aussi utiliser ce test pour vérifier que vos ventilateurs d'ordinateurs portable se déclenchent bien en cas de surchauffe.
Sur un portable récent, on obtient le résultat suivant au bout de quelques minutes de cpuburn.

<code>[root@R1 ~]# cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 80 C
[root@R1 ~]# </code>

Malgré la température très élevée du processeur, le système est resté stable ce qui permet de valider qu'il est capable d'encaisser une montée en température élevée. Bien entendu, plus votre machine sera « chaude » plus elle s'usera rapidement. Il ne faut pas oublier que les autres composants peuvent souffrir de la chaleur dégagée par le processeur par exemple : les disques durs en sont un bon exemple car les plateaux ne supportent pas la chaleur.
Ce test est bon aussi ? A priori, les composants de base de votre système sont en bon état, vous pouvez commencer à regarder du coté configuration logicielle.

== APIC es tu là ? ==

Le manque de stabilité peut aussi s'expliquer par la gestion des interruptions.
L'architecture PIC (Programmable Interrupt Controllers) représentée par la famille de composants Intel 8259, permettait une gestion de 8 interruptions pour un unique processeur. On les associe par 2 pour obtenir les 16 niveaux d'interruptions nécessaire depuis nos vieux 80286 (milieu des années 80). Avec l'arrivée des systèmes multi-processeurs, l'architecture APIC (Advanced Programmable Interrupt Controllers) (Intel 82093) à été ajoutée pour permettre une gestion plus fine des interruptions. En effet, dans un contexte multi-processeurs, il est nécessaire de pouvoir choisir quel processeur traitera quelle interruption pour ne pas rester figé dans l'ancien modèle (PIC) où le processeur de « boot » est assigné à un ensemble d'interruptions.

De plus, l'architecture APIC apporte une gestion de 24 interruptions, une gestion de priorité des interruptions et le routage de l'interruption sur le bon processeur, contre un simple routage de 2*8 interruptions dans le modèle PIC sur un seul processeur. Depuis une dizaine d'années, Intel propose le modèle APIC comme nouvelle architecture, y compris pour les systèmes mono-processeurs. Les ordinateurs récents, y compris les portables, sont maintenant équipés uniquement de composants APIC même si l'on peut obtenir un comportement de type PIC avec ceux-ci.

L'architecture APIC est constituée d'un ou plusieurs composants situé physiquement dans le southbridge (IO-APIC), généralement un par bus, et un composant situé dans le processeur : le Local APIC (LAPIC). Le LAPIC va permettre la gestion des interruptions au niveau du processeur local. Il permet aussi de générer des interruptions par exemple pour transmettre des interruptions à des processeurs voisins dans le contexte d'un système multi-processeurs, ces messages sont appelés IPI (Inter Processor Interrupts).

De plus le Local APIC (LAPIC) inclut un « timer » de précision cadencé à la fréquence du bus, généralement il peut être utilisé par l'ordonnanceur de votre système d'exploitation favori ou d'autres outils de haut niveau (profiler kernel : oprofile, vtune). Les LAPIC et l'IO-APIC sont reliés par un bus spécifique pour permettre un échange rapide des informations.
Schema logique d'implémentation :

Les IO-APIC vont donc se charger de collecter les interruptions provenant des périphériques systèmes et d'en assurer le transfert vers le ou les processeur(s) suivant une route préalablement programmée par le BIOS et/ou le système d'exploitation.

Cependant, l'implémentation des APIC dans les BIOS peut provoquer certaines instabilités sur votre système Linux. Par expérience, il n'y a pas de règle pour trouver la configuration qui peut aider votre machine à se stabiliser car cela dépend de chaque machine. Des différences peuvent même exister entre deux versions de BIOS d'un même ordinateur. Cependant, dans la série 2.6 du noyau Linux et les version 2.4 récentes nous disposons d'outils permettant de re-paramétrer cette configuration en activant/désactivant les IO-APIC ou les LAPIC.

Chaque composant possède un activateur ou un inhibiteur, on aura donc d'un coté « apic » et « noapic » pour la gestion des IO-APIC, « nolapic » et « lapic » de l'autre pour la gestion des LAPIC. Ces 4 options sont à utiliser sur la ligne de commande du noyau, c'est à dire au moment où le « bootloader » (lilo ou grub par exemple) va charger le noyau en mémoire. L'utilisation de « apic » et « lapic » permet d'activer ces composants qui ne l'ont pas été par le BIOS. L'activateur « apic » n'est disponible que les architectures de type x86_64 car celui-ci est déjà activé sur les systèmes de type x86. On désactivera les APIC dans le cas où le système affiche des messages d'erreurs sur les APIC comme :

<code>« APIC error on CPU0: 40(40) »</code>

ou

<code>MP-BIOS bug: 8254 timer not connected to IO-APIC
failed.
timer doesn't work through the IO-APIC - disabling NMI Watchdog!</code>

La désactivation des IO-APIC permet par exemple de corriger le comportement parfois récalcitrant de certaines cartes vidéos qui ne parviennent pas à afficher correctement en mode 2D/3D (écran noir par exemple).

La non activation des LAPIC peut avoir comme conséquence un dysfonctionnement de l'ACPI (gestion d'énergie avancée). Ce cas est traité par le noyau, vous retrouverez dans les messages de démarrage la ligne suivante : « "Local APIC disabled by BIOS you can enable it with lapic ».

Pour résumer, si votre machine, en général à architecture mono-processeur, a tendance à se bloquer lors de l'utilisation de périphériques tels que le port usb, la carte graphique ou la carte son, essayez de désactiver le LAPIC puis l' IO-APIC puis les 2. Pour exemple, les cartes mère A7N8X de chez Asus ont largement tendance à se bloquer si l'on ne spécifie pas « nolapic » lors du boot. Sur certaines machines, il faudra faire le contraire à savoir forcer l'activation des LAPIC. Ceci dépendra de votre machine et de sa conception.

== A vos marques, rebootez ! ==

Certains machines peuvent présenter quelques soucis pour redémarrer. Encore une fois, on retrouve au coeur de ce problème l'interaction entre le noyau et le matériel notamment l'ACPI. Les ordinateurs portables dont le modèle HP nc6120 ont par exemple le bon goût de rester bloqués sur le message « No reboot fixup found for your hardware ». Ceci indique que le noyau ne connaît pas de contournement pour ce matériel (ce qui est le cas de la quasi totalité des ordinateurs) mais puisque vous voyez ce message c'est que votre machine n'a pas réussi à rebooter. Heureusement, il existe des contournements pour permettre un redémarrage plus « bas niveau ». Le noyau défini les modes suivants : « b » « c » « h » « s » et « w ».
Le mode de reboot peut être défini sur la ligne de commande du noyau suivant la forme « reboot=<mode> ». Le mode « s » est réservé au systèmes multi-processeurs, elle va réinitialiser chacun des processeurs.

Le mode « b » permet quant à lui de rebooter en faisant un appel direct au bios qui se chargera de faire redémarrer la machine. Ce mode fonctionne plutôt bien car dans le cas d'un BIOS posant problème sur l'ACPI, on peut espérer avoir un reboot correct. C'est le cas sur de notre portable cité précédement.

Le mode « h » se chargera de faire redémarrer la machine en réinitialisant le processeur. C'est l'équivalent du mode « s » pour les environnements mono-processeurs. Pour finir, les modes « c » et « w » correspondent aux modes « cold » et « warn » : ces modes sont plus connus sous le nom de « reboot à froid » et « reboot à chaud ». Le premier effectuera les tests de mémoire tandis que le second exécutera un reboot plus court.

De manière générale, on utilisera plutôt le mode « b » ou « h » pour les systèmes mono-processeurs récalcitrant et le mode « s » pour les systèmes multi-processeurs.

== Toujours plus de performance ==
Votre configuration est bien stable depuis un certain temps. Toutefois vous trouvez qu'elle est un peu lente, elle ne vous donne pas satisfaction par rapport à ce qu'elle devrait fournir.
Cette partie de l'article va explorer comment vérifier et corriger les problèmes de performance des différents composants.
Note: certaines configuration mono-processeur nécessitent de désactiver LAPIC (nolapic)

=== Le disque dur ===

Il arrive parfois que le disque dur semble un peu lent et pénalise le système dans son ensemble. Hdparm est là pour vous aider à y voir plus clair. Hdparm est à l'origine conçu pour les systèmes de disques IDE de type PATA. Le nouveau système de disque SATA, ne permet pas toujours en fonction de l'implémentation, l'appel à toutes ces astuces. Cependant les nouvelles séries de kernel à partir du 2.6.15 devrait permettre une gestion plus unifiée des systèmes de disques PATA et SATA.

Le test « hdparm -t /dev/<mon_device> » permet de tester la vitesse de lecture depuis le disque dur jusqu'en mémoire. Une valeur de 25Mo/sec est un minimum pour des machines récentes. Plusieurs paramètres peuvent influencer les performances d'un disque IDE.
La commande « hdparm -cd » permet de vérifier que les entrées/sorties sont réalisées en 16-bit (le mode 32-bit n'offre pas de performance supplémentaire) alors que le DMA (Direct Memory Access) est activé. Ceci permet la minimisation de l'utilisation du processeur pendant les accès au disque dur.

<code>[root@R1 ~]# hdparm -cd /dev/hda
/dev/hda:
IO_support = 0 (default 16-bit)
using_dma = 1 (on)
[root@R1 ~]# </code>

La commande « hdparm -c0d1 /dev/<mon_device> » permet de configurer le périphérique dans ce mode. Le noyau de votre distribution Linux devrait le réaliser de manière automatique.

L'option « -I » permet d'obtenir plus d'informations sur la configuration de votre disque dur.

<code>[root@R1 ~]# hdparm -I /dev/hda
/dev/hda:
ATA device, with non-removable media
Model Number: FUJITSU MHT2040AT
Serial Number: NN77T3C13KB9
Firmware Revision: 0022
Standards:
Used: ATA/ATAPI-6 T13 1410D revision 3a
Supported: 6 5 4 3
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 78140160
device size with M = 1024*1024: 38154 MBytes
device size with M = 1000*1000: 40007 MBytes (40 GB)
Capabilities:
LBA, IORDY(cannot be disabled)
bytes avail on r/w long: 4 Queue depth: 1
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 128 (0x80)
Recommended acoustic management value: 254, current value: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
* Look-ahead
* Write cache
* Power Management feature set
Security Mode feature set
* SMART feature set
* Mandatory FLUSH CACHE command
* Device Configuration Overlay feature set
* Automatic Acoustic Management feature set
* SET MAX security extension
Power-Up In Standby feature set
* Advanced Power Management feature set
* DOWNLOAD MICROCODE cmd
* SMART self-test
* SMART error logging
Security:
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase
40min for SECURITY ERASE UNIT.
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct
[root@R1 ~]#</code>

On y retrouve le modèle, le numéro de série et la version du firmware qui peuvent être utiles en cas de contact avec le Service Après-Vente ou de mise à jour pour une série de firmwares défaillante.

La ligne commençant par « DMA » dans la partie « Capabilities » permet d'afficher la vitesse de transfert négociée entre le disque dur et le driver IDE de Linux. L'étoile précède la valeur actuelle. Dans cet exemple, le mode udma5 est sélectionné : ceci est conforme aux machines disponibles sur le marché depuis environ 3 ans.

Pour rappel, voici le tableau de conversion entre le mode DMA et la vitesse maximale associée.

Type de fonctionnement
Vitesse Maximale en MO/sec
UltraDMA 0
16,6
UltraDMA 1
25
UltraDMA 2
33,3
UltraDMA 3
44,4
UltraDMA 4
66,6
UltraDMA 5
100
UltraDMA 6
133,33

Une configuration actuelle ne devrait pas être en dessous de UDMA5. Si ce n'était pas le cas, on peut essayer de renégocier la vitesse de transfert à l'aide de la commande :

<code>hdparm -X udma5 </code>

Celle-ci permet de forcer le mode UltraDMA5. Il faut utiliser cette commande avec précaution car elle pourrait générer des pertes ou de la corruption de données en cas de transfert pendant ce changement de mode.

Vous pouvez aussi impacter les performances de votre disque dur en modifiant sa vitesse de rotation. Cette fonctionnalité connue sous le nom de Automatic Acoustic Management (AAM) est utilisable avec l'option « -M » de hdparm. La valeur 128 représentera la vitesse la plus faible avec un disque silencieux, la valeur 254 la vitesse la plus élevée mais avec comme contre-partie un disque plus bruyant. On pourra noter des différences de quelques Mo/sec selon les configurations.

Il est aussi à noter que l'utilisation de logiciels permettant une meilleure gestion d'énergie (cpufreq, laptop-mode) peut dégrader les performances d'un disque dur de manière notable.

=== Configuration bas niveau du réseau ===

Le réseau local filaire peut parfois être un peu lent. Voici quelques tests pour vérifier si la lenteur provient du logiciel, du noyau ou du matériel. Tout d'abord, explorons la trousse à outils indispensable pour analyser votre carte réseau : ethtool. Digne successeur de mii-tool, il permet de s'informer sur la configuration de votre carte réseau.

Il suffit de lancer « ethtool <votre_interface> » » pour obtenir la configuration matérielle de votre carte. On y retrouve les modes supportés par votre carte (Supported Link Modes ainsi que la vitesse actuelle (Speed), obtenue par auto-négociation dans cet exemple.

On peut également savoir si le câble réseau est connecté à la carte grâce à la ligne « Link Detected ». Le type de « duplex » utilisé permet également de savoir si la négociation avec l' élément actif au bout de votre câble (commutateur, concentrateur ou une autre machine) a correctement fonctionné. Le duplex définit le mode de transmission : le mode half-duplex indique que l'on émet puis on reçoit des données, le mode full-duplex indique que l'on peut émettre et recevoir en même temps des données. Le mode full-duplex est donc plus que recommandé pour vos équipements réseaux.

<code>[root@konilope ~]# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Current message level: 0x000020c1 (8385)
Link detected: yes
[root@konilope ~]# </code>

=== Mesurer les {contre}performances de votre réseau ===

Une fois vérifiée la bonne configuration de votre matériel, nous pouvons passer à la vérification des performances entre deux machines.

L'utilitaire netpipe (http://www.scl.ameslab.gov/netpipe/) permet de réaliser des tests de performance mais aussi d'intégrité entre deux machines. Il permet de tester les performances du réseau au travers la couche IP et non pas depuis un mode plus bas niveau comme pourrait l'être un test utilisant directement le driver Ethernet. Ce test permet donc de valider que la configuration matérielle mais aussi logicielle est correcte.

Sur la première machine, exécutez « NPtcp » : netpipe se positionne en mode « serveur ».
Sur la seconde machine, exécutez « NPtcp -h <machine1> » : netpipe se connecte au serveur netpipe de la machine nommée machine1 pour effectuer le test de performance.

Le test par défaut teste les communication allant de 1 octet jusqu'à 8 Mo. Il peut prendre plusieurs minutes si le réseau est « lent ». Le test va montrer pour chaque taille de paquet la performance obtenue. Il est normal d'obtenir des performances faibles pour des paquets d'une taille inférieure à 8 Ko. Transporter des petits paquets nécessite de réaliser beaucoup d'opérations pour le processeur pour une quantité d'information minime. Les performances seront meilleures à partir d'environ 16 Ko et maximales à partir de 128 Ko. Sur un système utilisant du gigabit ethernet, on constatera une performance de 39Mbps à 256 octets, 287Mbps à 4Ko, 614Mbps à 16Ko, 845Mbps à 128Ko, 895Mbps à 8Mo.

Vous pouvez ainsi vérifier et comparer facilement les performances de votre configuration réseau. Netpipe permet également de tester la vitesse du réseau pour une taille de paquets définie entre la taille indiqué par l'option « -l » et la taille indiquée par l'option « -u ». Ainsi, NPtcp -l 16384 -u 16384 permet de tester la bande passante réseau pour une taille de paquet égale à 16Ko.

L'option « -n <nb-cycle> » permet de définir le nombre de boucles à réaliser pour le test (50 par défaut). Enfin, pour réaliser des tests « full-duplex », on utilisera l'option « -2 ». Ce test permet de s'assurer du bon fonctionnement du mode de communication permettant l'écriture et la lecture simultanées.

Attention, même si ce test donne de bons résultats, cela ne veut pas dire que la configuration est exempte d'erreur de configuration. Par exemple, les performances réseaux peuvent être très bonnes en point à point mais mauvaises lorsque l'on aura une charge réseau avec plusieurs clients. Dans cette situation, il faut vérifier que le contrôle de flux est bien activé sur toutes les machines. L'option « ethtool -a » permet de vérifier que les champs « rx » et « tx » sont placés sur « on ». Si ce n'était pas le cas activez-les avec la commande « ethtool -A eth0 rx on » et « ethtool -A eth0 tx on ».

Les cartes réseaux, des serveurs essentiellement, permettent maintenant de réaliser le « tcp segment offload ». Cette technique permet de décharger une partie du traitement TCP directement dans l'électronique de la carte réseau. Ceci à pour effet de décharger le processeur central d'un traitement fastidieux. L'option « -k » d'ethtool permet de consulter l'état de cette fonctionnalité (off/on). On pourra l'activer sur des serveurs générant un gros trafic réseau par exemple : « ethtool -K eth0 tso on ».

Vous voilà maintenant équipé de nouveau outils pour traquer la perte de performances de votre installation réseau. Ceci couplé aux habituels tcpdump/ethereal, voilà une belle panoplie du zorro du réseau.

=== Quand la latence s'en mêle ===

La latence représente le temps nécessaire à un système pour prendre en compte un événement.

Il arrive que certains périphériques de votre machine nécessitant des débits importants ou une latence assez faible sur le bus PCI soient « poussifs ». On retrouve dans cette catégorie les cartes vidéos accélératrice 3D, les cartes son et les cartes d'acquisition firewire ou DVB (récepteur de télévision numérique terrestre : TNT).

Un périphérique branché sur le bus PCI doit attendre que le bus soit libre pour émettre les données vers la mémoire centrale. Le bus PCI qui est le coeur de communication des périphériques est donc soumis en permanence à un arbitrage qui permet de décider qui doit émettre des données et qui doit attendre. Cet arbitrage est en partie réalisé grâce au « latency_timer ».

Chaque périphérique possède une valeur de « latency_timer » comprise en 0 et 248 cycles d'horloge du bus. Plus la valeur sera importante plus le périphérique disposera de temps pour transmettre des informations. Une latence de 248 cycles permet d'obtenir une priorité forte sur le bus, ce qui permet un débit important. A contrario, une latence de 0 indiquera au périphérique qu'il doit cesser ses transmissions si un autre composant à besoin du bus : ceci se traduira par une perte de bande passante importante.

La configuration réalisée par défaut sur votre machine doit être correcte mais il peut arriver qu'une carte 3D ou DVB soit configurée avec une latence trop faible, ce qui aurait pour conséquence d'offrir une image saccadée et peu fluide. Une carte son offrirait également le même type de symptômes avec un son hâché ou excessivement métallique.

Heureusement, une série d'outils est là pour vous aider à diagnostiquer le problème mais aussi à le résoudre. Le projet pciutils (http://atrey.karlin.mff.cuni.cz/~mj/linux.shtml#pciutils) contient deux outils indispensables: lspci et setpci. Bien entendu, votre distribution favorite devrait posséder ce logiciel, il vous suffira de l'installer avec votre gestionnaire de paquet favori (urpmi, apt, smart).

La commande « lspci » vous permet de lister les périphériques PCI disponibles sur votre ordinateur (cf article paru dans le numéro 68). Cet exemple se basera sur une carte vidéo ayant pour adresse sur le bus PCI « 01:00.0 ».

<code>[root@lagirafe] lspci -v -s 01:00.0
01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX Go5200 32M/64M] (rev a1) (prog-if 00 [VGA])
Subsystem: Samsung Electronics Co Ltd: Unknown device c00f
Flags: bus master, 66Mhz, medium devsel, latency 16, IRQ 11
Memory at c8000000 (32-bit, non-prefetchable) [size=16M]
Memory at d8000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 3.0
[root@lagirafe]</code>

On retiendra dans cette ligne, la valeur 'latency 16'. Ceci risque de poser problème lorsque celle-ci aura besoin d'un fort débit pendant un jeu par exemple. Augmenter la latence va donc se révéler nécessaire pour ce périphérique.

La commande setpci permet de modifier les paramètres PCI d'un périphérique ou d'un bus complet avec tous ses périphériques.

La commande « setpci -v -d 01:* latency_timer=20 » permet de positionner tous les périphériques du bus 01 à une valeur de 32 cycles. Il est à noter que la commande setpci utilise des valeurs en hexadécimal mais lspci affichera les valeurs en décimal.

Pour en revenir à nos moutons, la correction de la latence de cette carte graphique se fera avec la commande « setpci -v -d 01:00.0 latency_timer=f8 ». Ceci positionne donc la carte sur la plus grande valeur de latence possible, ce qui lui garantira la plus grande bande passante possible. Il est possible d'utiliser la valeur « ff » comme paramètre pour « latency_timer » mais celui-ci sera converti à la volée par la commande setpci en « 0xf8 ».

Attention, certains composants de votre machine doivent rester en « latency_timer=0 » pour garantir une bon fonctionnement de votre système : il ne faudra donc pas modifier les latences des contrôleurs mémoire et des ponts PCI connectés généralement sur le bus « 0:* ».

== DSDT : le cauchemar continue ! ==

Cette partie de l'article a pour but d'expliquer le problème que peut représenter la table DSDT pour un certain nombre de machines et surtout les ordinateurs portables.

La norme ACPI 3.0 de Septembre 2004 disponible gratuitement à l'adresse http://www.acpi.info/DOWNLOADS/ACPIspec30.pdf définit la DSDT comme une table remplie par un OEM permettant au système d'exploitation de découvrir les ressources pour la gestion de l'énergie avancée, de la gestion thermique ainsi que la gestion du Plug'nPlay des ressources définies par l'ACPI.

Voici une description certes un peu théorique mais nécessaire pour bien comprendre la problématique et ses conséquences. Le constructeur de l'ordinateur doit donc définir dans le BIOS une table contenant une liste de ressources et leurs configuration et ce pour que le système d'exploitation puisse s'en servir. Noble cause n'est il pas ? Tout au long des 618 pages de ce document sont spécifiés les éléments du langage à utiliser ainsi que sa syntaxe. L' « ACPI Source Language » permettra donc aux développeurs d'écrire des DSDT puis de les compiler dans un format nommé « ACPI Machine Language » en utilisant un compilateur adéquat. Le système d'exploitation utilisera la table compilée (AML) pour accéder aux ressources ACPI.
Sur la plupart des ordinateurs portables, la table DSDT ne respecte pas la norme ACPI dans sa syntaxe. Ceci est très gênant car cela bloque le code de l'interpréteur ACPI du noyau Linux qui essaie de la lire. Le résultat est sans appel, pas d'ACPI, pas de gestion d'énergie avancée, plus de ventilation automatique sur certains modèles d'ordinateurs, plus de touche de gestion de contraste/luminosité sur d'autres etc...

Ceci est très gênant sur un ordinateur portable. Alors que faire ? Dans un premier temps, prévenir le constructeur que son BIOS est incorrect et ne respecte pas la norme ACPI. La réponse se fait toujours attendre pour tous ceux qui « osent » poser la question au support technique : à savoir, les constructeurs ignorent tout simplement les mails de ce type.
La seconde étape puisque vous êtes devant le fait accompli d'une machine non conforme, il va falloir corriger cette table. Il suffit de récupérer la table actuelle via la commande 'cat /proc/acpi/dsdt > dsdt.aml' si vous avez la chance d'avoir un répertoire /proc/acpi malgré une table DSDT endommagée, sinon utilisez la commande 'acpidump -b -t dsdt -o dsdt.aml'. La commande acpidump est fournit dans le projet pmtools (ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20050926.tar.bz2)
Vous avez donc extrait la table DSDT de votre système. Il ne reste plus qu'à essayer de la recompiler. Pour cela, le compilateur IASL de la société Intel (http://developer.intel.com/technology/iapc/acpi/downloads.htm) offre sous Linux et Windows une plate-forme de compilation pour le langage ASL.

Suivez les instructions du site pour télécharger et compiler la version unix d'iasl. Ensuite, décompilez la table avec la commande « iasl -d dsdt.aml ». Le fichier dsdt.dsl vient d'être créé par le décompilateur. Il suffit de le recompiler avec la commande « iasl -tc dsdt.dsl » pour constater les dégâts ! La DSDT que vous avez dans votre BIOS est généralement compilée par le compilateur de Microsoft qui semble autoriser une syntaxe plus qu'approximative.
Si vous avez de la chance, votre DSDT s'est recompilée sans erreurs, vous obtenez donc un fichier dsdt.hex et un fichier dsdt.aml. Il ne reste plus qu'à injecter cette dsdt dans le noyau Linux et le tour sera joué.

Si vous avez moins de chance, votre DSDT est syntaxiquement incorrecte et génère des erreurs. Les expliquer plus en détails nécessiterait un article complet, il ne sera cité que les plus « habituelles » (sic).

<code>dsdt.dsl 2626: Field (ECR, DWordAcc, Lock, Preserve)
Error 1048 - ^ Host Operation Region requires ByteAcc access </code>

Cette erreur présente à ligne 2626 du fichier dsdt.asl indique une erreur de type dans la déclaration du champ ECR. Il suffit dans ce cas de changer le mot « DWordAcc » par « ByteAcc ». Celle-ci reste assez simple à corriger, on se demande donc pourquoi les constructeurs ne prennent pas le temps de vérifier et de corriger leur BIOS.

<code>dsdt.dsl 2672: Method (_GLK, 1, NotSerialized)
Warning 2024 - ^ Reserved method has too many arguments ( _GLK requires 0) </code>

La méthode _GLK n'a besoin que de 0 paramètre tandis que ce code en utilise 2 ! La correction est assez simple : il suffit de remplacer la ligne 2672 par « Method(_GLK) ».

Pour plus de détails sur la correction des erreurs de compilation de votre table dsdt, je vous recommande les tutoriaux disponibles depuis la page http://acpi.sourceforge.net/dsdt/index.php du projet ACPI.

Votre DSDT est compilée avec succès, il ne vous reste plus qu'à l'ajouter pour que votre noyau puisse l'utiliser à la place de celle fourni par le BIOS (modifiable uniquement par le constructeur, via une mise à jour).

Il existe trois possibilités pour inclure une table DSDT : la modification du noyau Linux ( noyau < 2.6.9), l'injection de la DSDT dans la configuration du noyau (noyau >= 2.6.9), l'intégration de la table DSDT dans l'initrd qui nécessite un patch kernel disponible à l'adresse http://gaugusch.at/kernel.shtml.

Pour les noyaux 2.6.9 et supérieur, copiez votre fichier dsdt.hex sous le nom «/usr/src/linux/include/acpi/dsdt_table.h » puis reconfigurez votre noyau.
Insérer « dsdt_table.h » dans l'option « Include you custom DSDT » disponible dans le menu « Power Management/ACPI/ ». Recompilez votre noyau et redémarrez avec votre nouveau noyau.
Pour les noyaux inférieurs à 2.6.9, il est possible de modifier le code source de votre noyau pour intégrer votre DSDT mais il est préférable d'utiliser le patch permettant l'insertion de la table DSDT dans l'initrd. Recompilez votre noyau avec ce patch, puis suivez la procédure décrite ci-dessous.

Certaines distributions Linux comme « Mandriva Linux » possèdent le patch qui permet de n'avoir qu'à reconstruire l'initrd avec la commande « mkinitrd –dsdt=/boot/dsdt.aml /boot/initrd-`uname -r`.img `uname -r` » puis de relancer lilo avant de redémarrer votre machine. Lors du démarrage de celle-ci vous devriez voir le message suivant :

<code>ACPI: Looking for DSDT in initrd... found (at offset 0x4f8d9).
ACPI-0294: *** Info: Table [DSDT] replaced by host OS</code>

Vous voilà maintenant avec une table DSDT correcte et un ACPI fonctionnel. La question qui reste ouverte est pourquoi les constructeurs n'utilisent pas un compilateur digne de ce nom pour permettre à leur clients de pouvoir utiliser d'autres systèmes d'exploitation que Windows de Microsoft.

Pour la petite histoire, si vous cherchez dans votre dsdt vous risquez de tomber ce genre de lignes :

<code>If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), Zero))
If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))
If (LEqual (SCMP (\_OS, "Microsoft WindowsME: Millennium Edition"), Zero))
If (LEqual (SizeOf (\_OS), 0x27)) </code>

Lorsque qu'un système d'exploitation souhaite utiliser les ressources ACPI du BIOS, il utilise son nom de système d'exploitation (acpi_os_name). On retrouve donc dans les bios des parties qui ne seront exécutées que pour certains systèmes d'exploitation de Microsoft. On retrouve même certains tests où c'est la longueur du nom qui compte...... Ceci prouve bien que les constructeurs d'ordinateurs savent corriger des tables DSDT pour les systèmes d'exploitation mais pas forcément pour le notre malheureusement. Depuis le noyau 2.6.9, le noyau Linux utilise « Windows NT » comme « acpi_os_name » pour assurer une meilleure compatibilité matérielle dixit Len Bron d'Intel dans le changelog de cette version.

== Comment trouver le pilote qui va avec votre matériel ? ==

Cette question on se la pose souvent mais uniquement lorsque l'on essaye de brancher un nouveau périphérique sur sa machine. Les distributions récentes permettent de détecter automatiquement votre matériel et de lui associer un pilote avec sa configuration. Ce mécanisme fonctionne plutôt bien mais cela n'évite pas les dysfonctionnements voir l'absence de fonctionnement.

Pour vérifier si votre noyau Linux est capable de supporter un nouveau périphérique PCI par exemple, il suffit d'en récupérer les identifiants PCI (constructeur et produit) puis de les rechercher dans le fichier « /lib/modules/`uname -r`/modules.pcimap » qui est auto-généré lors de la commande depmod.

L'utilitaire « lspcidrake -v » vous permet de trouver les identifiants PCI de votre carte, la commande « lspci » vous permet de trouver le nom de votre périphérique puis faites un « lspci -n » pour en trouver la correspondance numérique. On utilisera la position du périphérique sur le bus pour retrouver la correspondance numérique « 02:05.0 » dans cet exemple.
<code>[root@pumphome] lspci
[....]
02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01)
[root@pumphome] lspci -n
[...]
02:05.0 Class 0200: 14e4:4401 (rev 01)
[root@pumphome]</code>

Ainsi cette carte réseau possède les identifiants 14e4 (constructeur) et 4401 (produit). Il suffit de rechercher cette valeur dans le modules.pcimap, ce qui nous donnera la correspondance en module (pilote).

<code>[root@pumphome] grep "0x000014e4 0x00004401" /lib/modules/2.6.12-12mdk-i686-up-4GB/modules.pcimap
b44 0x000014e4 0x00004401 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
bcm4400 0x000014e4 0x00004401 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0</code>

On voit ici que cette carte peut utiliser le driver b44 ou le driver bcm4400. On ne trouve pas toujours les identifiants PCI de produit sous leur forme directe, on peut également trouver « 0Xffffffff » qui indique que tous les cartes du constructeur sont gérées par un module.
Il ne vous restera plus qu'à effectuer la configuration associée à ce périphérique pour qu'il fonctionne correctement.

== Conclusion ==

La fin de cet article conclut une toute petite série de deux articles ayant pour but de vulgariser l'architecture de nos machines, de découvrir les outils disponibles pour mieux comprendre leur configuration et au besoin régler les problèmes de configuration matérielle qui ont souvent le don de nous pourrir la vie.

Merci à LaurentJ de #Mandrivafr pour ses tests complémentaires sur les problèmes d'IO-APIC. Un énorme merci à Nicolas Planel pour sa relecture pointue et également Anne pour sa patience de girafe à relire et « quaurigé »mes « photes », ainsi qu'à tous ceux qui m'ont aidé à découvrir ce que je restitue dans cet article.

Cet article a été publié dans Linux Magazine France n°78. Il est publié sur Léa avec l'aimable autorisation de l'éditeur.

Découvrez les ressources de votre machine (La suite)

2006-06-11T20:27:40Z

Ennael : /* La mémoire qui flanche ? */

= Découvrez les ressources de votre machine (La suite) =

== Introduction ==

A nouvelle année, nouvelles résolutions ! Paru dans le numéro 68, un premier article dédié à la découverte des outils disponibles pour la récupération des configurations de votre machine promettait une suite. Je vous propose donc de reprendre ce voyage au centre de votre ordinateur.

Cet article sera articulé autour du diagnostic de pannes et des correctifs associés mais aussi de « trucs & astuces » permettant d'optimiser votre configuration.

== Savez-vous planter les choux ? ==

Les choux peut-être pas mais les ordinateurs je pense que c'est arrivé au moins une fois à chaque lecteur qui lit cet article. Rien de plus énervant qu'un écran qui se fige, le pointeur de souris qui ne se déplace plus, le clavier qui ne répond plus non plus.... Planté ! Ce constat est assez facile à établir mais en trouver la cause reste un problème nettement plus complexe tellement le nombre de causes possibles est important.

Deux solutions : ignorer le problème et relancer le système en se disant que ça « passera », ou alors chercher la cause du problème en essayant de trouver une méthode reproduisant le « plantage » tant redouté.

La première solution fonctionne assez bien mais si l'on à faire à un « vrai » problème de configuration matérielle ou logicielle, on arrivera assez vite à ne plus pouvoir éviter la seconde voire la troisième. J'allais oublier cette troisième solution destinée aux plus riches d'entre vous : changer de matériel. Cette solution coûteuse peut parfois se révéler efficace, parfois pas du tout. A quoi bon changer un composant sans savoir si c'était bien celui-ci qui posait problème ?
Quelque soit la solution retenue, il sera de toute manière nécessaire de localiser la panne pour y apporter la réponse adéquate. Certaines sociétés ou particuliers se sont spécialisés dans ce dépannage ou l'utilisateur est « dépassé » par les événements.

Cet article vous fera, je l'espère, découvrir quelques outils et méthodes pour valider un par un les composants de votre ordinateur. Cela vous permettra j'espère d'être un peu moins dépourvu quand un problème surviendra. L'article reproduira les étapes qu'il faut suivre pour isoler le « fautif ».

== Les causes possibles d'un « plantage » ==

On retrouve deux grandes catégories de pannes provoquant des dysfonctionnements importants sur un système informatique.
* une panne du matériel
* une erreur logicielle au niveau du noyau et des pilotes (drivers)

Il faudra donc être capable de séparer la panne matérielle qui « force » l'ordinateur à entrer dans un mode de fonctionnement non prévu et instable, de l'erreur logicielle qui équivaut à demander à l'ordinateur de faire « n'importe quoi » et qui va donc se « planter ».

Le terme « planté » utilisé ici équivaut à un arrêt du système à cause d'erreurs sévères : instruction illégale ou composants défaillants. Le terme de « plantage » est aussi utilisé pour décrire le fonctionnement d'une application qui se ferme inopinément. Ce cas est plus souvent lié à une erreur de programmation de l'application qu'à une erreur du système. Nous ne parlerons donc pas de ce second cas dans cet article.

== La mémoire qui flanche ? ==

Une cause « classique » des dysfonctionnements se situe au niveau de la gestion de la mémoire de votre machine. Je ne parle pas d'allocation mémoire réalisée par votre système d'exploitation favori mais bien de la manière avec laquelle la carte mère configure et utilise vos barrettes de mémoire. Les applications chargent en mémoire des données et des instructions destinées au processeur. Voici un scénario qui peut provoquer l'arrêt de la machine.

Votre application favorite est lancée depuis la ligne de commande ou une interface graphique via un « clic » de souris. Votre système d'exploitation va donc charger ce programme en mémoire puis en exécuter les instructions. Au plus bas niveau de votre système, le processeur exécute des instructions en langage machine (assembleur) présente en mémoire.
Malheureusement, votre mémoire est défaillante et elle n'arrive pas à maintenir un état stable des informations qui lui sont confiées. Par exemple, la lettre C est représentée par le code 67, ou « 1000011 » en binaire. Si la zone mémoire change d'état, alors le contenu de la valeur stocké à cet endroit changera : on pourrait se retrouver avec « 1000010 ». Un seul bit a changé, mais on passe de la lettre 'C' (67) à la lettre 'B'(66). Le résultat ne se fait pas attendre, le processeur se retrouve à exécuter des instructions qui n'ont plus de sens, provoquant l'arrêt de la machine.

Les pannes de mémoires sont généralement dues à des composants endommagés, des barrettes incompatibles ou un « timing d'accès » à la mémoire (nommé CAS (Column Address Strobe) dans la plupart des BIOS) trop agressif permettant des lectures dans des zones mémoires avant que les écritures aient eu le temps de se stabiliser pour en garantir le contenu.

Il est assez simple de valider votre configuration mémoire grâce à l'utilitaire memtest (http://www.memtest.org). Cet utilitaire de taille très modeste, 96 Kilo-octets, est écrit en assembleur ce qui lui permet de s'exécuter indépendamment du système d'exploitation. Ceci garantit un test « proche » du matériel, sans sur-couche pouvant apporter d'autres problèmes.
La version 1.65 actuelle est téléchargeable sous deux formes : une iso que l'on peut graver sur un CDRW de préférence vu la petite taille du programme ou sous la forme d'une amorce système (pre-compiled bootable binary). Il suffira de décompresser l'archive puis d'exécuter la commande suivante :
<code>dd if=memtest.bin of=/dev/fda</code>

Ceci écrasera le contenu de votre disquette pour y copier memtest.
Rebootez l'ordinateur avec la disquette placée dans le lecteur, memtest devrait se lancer.

[[Image:memtest.jpg]]

La figure 1, est une capture d'écran de memtest en fonctionnement. Le barre de progression principale affichée en haut à droite de l'écran (2% dans cet exemple) permet de suivre la progression du test. Les erreurs apparaissent dans la partie inférieure de l'écran. Il suffit de laisser fonctionner memtest au moins une fois jusqu'à 100%. Si aucune ligne ne s'est affichée alors vou pouvez considérer que la mémoire est fonctionnelle. Dans le cas contraire, il faudra soit procéder à son remplacement s'il s'agit d'une seule barrette mémoire, soit tester les barrettes indépendamment (l'une puis l'autre) avec ce logiciel. Dans le cas de 2 ou 3 barrettes qui ne fonctionnement pas correctement ensemble mais qui fonctionnement correctement individuellement, il faudra vérifier qu'elles sont bien de même modèle/marque et remettre le Bios dans une configuration initiale.

Votre mémoire est bonne ? Testons les autres composants de votre machine pour traquer la source de ce plantage.

== Il ne fait pas un peu chaud là ? ==

Ces dix dernières années la puissance consommée et dissipée par nos ordinateurs a littéralement explosé ! Du 486 qui ne nécessitait quasiment pas de ventilateur, on est arrivé à des stations de travail/jeu avec des alimentations pouvant atteindre 1KiloWatt pour les dernières et 500watt pour des modèles plus « grand public ». Le processeur est un des composants gourmands de la machine. Certains modèles peuvent consommer plus de 130W ! Autant dire que si le système est mal ventilé, la montée en charge du processeur peut provoquer un échauffement important provoquant une surchauffe de celui-ci. S'il dépasse ces caractéristiques de fonctionnement, il va alors exécuter du code incorrect provocant un plantage du système.

Un bon test pour vérifier que votre processeur n'est pas la cause de votre instabilité : commencez par relever la température de votre machine au repos à l'aide des informations fournies soit par l'acpi soit pas lm_sensors.

<code>[erwan@R1 ~]$ cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 42 C
[erwan@R1 ~]$

[root@konilope ~]# sensors | grep Temp
M/B Temp: +39°C (low = +15°C, high = +40°C) sensor = thermistor
CPU Temp: +127°C (low = +15°C, high = +45°C) sensor = thermistor
Temp3: +44°C (low = +15°C, high = +45°C) sensor = thermistor
[root@konilope ~]</code>

La méthode utilisant lm_sensors nécessite une interprétation de la part de l'utilisateur. Dans cet exemple, il apparaît évidant que le processeur ne peut avoir une température de fonctionnement aussi élevée (127°C). L'erreur est du à un mauvais calcul de la part de lm_sensors. Il se base sur le type de capteurs thermiques utilisé par la carte mère pour calculer la température des différents composants. Malheureusement, le montage électrique autour du capteur de température peut varier d'un modèle de carte à un autre, ce qui fausse les calculs. On considéra donc, que pour cette machine (konilope) sa température se situe aux alentours de 42° : valeur moyenne entre les deux valeurs « cohérentes » relevées par lm_sensors. On pourra cependant vérifier cette approximation en relevant la température du disque sur à l'aide de smartmontools.

<code>[root@konilope ~]# smartctl -A /dev/hda | grep Temperature
194 Temperature_Celsius 0x0022 042 052 000 Old_age Always - 42
[root@konilope ~]# </code>

De manière générale, il est préférable de maintenir sa machine en dessous des 55° et celle de son processeur en dessous de 70°C. Au delà, le système risque d'être instable. Si ce n'est pas le cas, effectuez les modification nécessaire pour y parvenir : meilleure ventilation du processeur ou du boîtier par exemple.

Ensuite, téléchargez l'utilitaire cpuburn depuis un mirroir (http://pages.sbcglobal.net/redelm/cpuburn_1_4_tar.gz) ou depuis votre distribution linux favorite (oui, oui, urpmi cpuburn ça fonctionne ;o)).

Vous y trouverez plusieurs programmes nommés burnXX ou XX représente votre processeur. La version P6 sera à utiliser sur les processeurs Intel Pentium 4, la version K7 pour les processeurs Athlon x86. Pour les processeurs plus récents, utilisez la version P6.
Ce logiciel réalise des boucles en langage assembleur ayant pour but de stresser votre processeur de manière importante et donc le faire chauffer. Lancez cpuburn autant de fois que vous avez de processeur sur votre machine puis observez la température de votre machine. Si lors de la montée en température votre système se fige, alors vous avez un problème de thermie. Si cpuburn ne fait pas planter votre ordinateur au bout de 10mn, vous pouvez considérez que votre système est stable de ce coté là. Vous pouvez aussi utiliser ce test pour vérifier que vos ventilateurs d'ordinateurs portable se déclenchent bien en cas de surchauffe.
Sur un portable récent, on obtient le résultat suivant au bout de quelques minutes de cpuburn.

<code>[root@R1 ~]# cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 80 C
[root@R1 ~]# </code>

Malgré la température très élevée du processeur, le système est resté stable ce qui permet de valider qu'il est capable d'encaisser une montée en température élevée. Bien entendu, plus votre machine sera « chaude » plus elle s'usera rapidement. Il ne faut pas oublier que les autres composants peuvent souffrir de la chaleur dégagée par le processeur par exemple : les disques durs en sont un bon exemple car les plateaux ne supportent pas la chaleur.
Ce test est bon aussi ? A priori, les composants de base de votre système sont en bon état, vous pouvez commencer à regarder du coté configuration logicielle.

== APIC es tu là ? ==

Le manque de stabilité peut aussi s'expliquer par la gestion des interruptions.
L'architecture PIC (Programmable Interrupt Controllers) représentée par la famille de composants Intel 8259, permettait une gestion de 8 interruptions pour un unique processeur. On les associe par 2 pour obtenir les 16 niveaux d'interruptions nécessaire depuis nos vieux 80286 (milieu des années 80). Avec l'arrivée des systèmes multi-processeurs, l'architecture APIC (Advanced Programmable Interrupt Controllers) (Intel 82093) à été ajoutée pour permettre une gestion plus fine des interruptions. En effet, dans un contexte multi-processeurs, il est nécessaire de pouvoir choisir quel processeur traitera quelle interruption pour ne pas rester figé dans l'ancien modèle (PIC) où le processeur de « boot » est assigné à un ensemble d'interruptions.

De plus, l'architecture APIC apporte une gestion de 24 interruptions, une gestion de priorité des interruptions et le routage de l'interruption sur le bon processeur, contre un simple routage de 2*8 interruptions dans le modèle PIC sur un seul processeur. Depuis une dizaine d'années, Intel propose le modèle APIC comme nouvelle architecture, y compris pour les systèmes mono-processeurs. Les ordinateurs récents, y compris les portables, sont maintenant équipés uniquement de composants APIC même si l'on peut obtenir un comportement de type PIC avec ceux-ci.

L'architecture APIC est constituée d'un ou plusieurs composants situé physiquement dans le southbridge (IO-APIC), généralement un par bus, et un composant situé dans le processeur : le Local APIC (LAPIC). Le LAPIC va permettre la gestion des interruptions au niveau du processeur local. Il permet aussi de générer des interruptions par exemple pour transmettre des interruptions à des processeurs voisins dans le contexte d'un système multi-processeurs, ces messages sont appelés IPI (Inter Processor Interrupts).

De plus le Local APIC (LAPIC) inclut un « timer » de précision cadencé à la fréquence du bus, généralement il peut être utilisé par l'ordonnanceur de votre système d'exploitation favori ou d'autres outils de haut niveau (profiler kernel : oprofile, vtune). Les LAPIC et l'IO-APIC sont reliés par un bus spécifique pour permettre un échange rapide des informations.
Schema logique d'implémentation :

Les IO-APIC vont donc se charger de collecter les interruptions provenant des périphériques systèmes et d'en assurer le transfert vers le ou les processeur(s) suivant une route préalablement programmée par le BIOS et/ou le système d'exploitation.

Cependant, l'implémentation des APIC dans les BIOS peut provoquer certaines instabilités sur votre système Linux. Par expérience, il n'y a pas de règle pour trouver la configuration qui peut aider votre machine à se stabiliser car cela dépend de chaque machine. Des différences peuvent même exister entre deux versions de BIOS d'un même ordinateur. Cependant, dans la série 2.6 du noyau Linux et les version 2.4 récentes nous disposons d'outils permettant de re-paramétrer cette configuration en activant/désactivant les IO-APIC ou les LAPIC.

Chaque composant possède un activateur ou un inhibiteur, on aura donc d'un coté « apic » et « noapic » pour la gestion des IO-APIC, « nolapic » et « lapic » de l'autre pour la gestion des LAPIC. Ces 4 options sont à utiliser sur la ligne de commande du noyau, c'est à dire au moment où le « bootloader » (lilo ou grub par exemple) va charger le noyau en mémoire. L'utilisation de « apic » et « lapic » permet d'activer ces composants qui ne l'ont pas été par le BIOS. L'activateur « apic » n'est disponible que les architectures de type x86_64 car celui-ci est déjà activé sur les systèmes de type x86. On désactivera les APIC dans le cas où le système affiche des messages d'erreurs sur les APIC comme :

<code>« APIC error on CPU0: 40(40) »</code>

ou

<code>MP-BIOS bug: 8254 timer not connected to IO-APIC
failed.
timer doesn't work through the IO-APIC - disabling NMI Watchdog!</code>

La désactivation des IO-APIC permet par exemple de corriger le comportement parfois récalcitrant de certaines cartes vidéos qui ne parviennent pas à afficher correctement en mode 2D/3D (écran noir par exemple).

La non activation des LAPIC peut avoir comme conséquence un dysfonctionnement de l'ACPI (gestion d'énergie avancée). Ce cas est traité par le noyau, vous retrouverez dans les messages de démarrage la ligne suivante : « "Local APIC disabled by BIOS you can enable it with lapic ».

Pour résumer, si votre machine, en général à architecture mono-processeur, a tendance à se bloquer lors de l'utilisation de périphériques tels que le port usb, la carte graphique ou la carte son, essayez de désactiver le LAPIC puis l' IO-APIC puis les 2. Pour exemple, les cartes mère A7N8X de chez Asus ont largement tendance à se bloquer si l'on ne spécifie pas « nolapic » lors du boot. Sur certaines machines, il faudra faire le contraire à savoir forcer l'activation des LAPIC. Ceci dépendra de votre machine et de sa conception.

== A vos marques, rebootez ! ==

Certains machines peuvent présenter quelques soucis pour redémarrer. Encore une fois, on retrouve au coeur de ce problème l'interaction entre le noyau et le matériel notamment l'ACPI. Les ordinateurs portables dont le modèle HP nc6120 ont par exemple le bon goût de rester bloqués sur le message « No reboot fixup found for your hardware ». Ceci indique que le noyau ne connaît pas de contournement pour ce matériel (ce qui est le cas de la quasi totalité des ordinateurs) mais puisque vous voyez ce message c'est que votre machine n'a pas réussi à rebooter. Heureusement, il existe des contournements pour permettre un redémarrage plus « bas niveau ». Le noyau défini les modes suivants : « b » « c » « h » « s » et « w ».
Le mode de reboot peut être défini sur la ligne de commande du noyau suivant la forme « reboot=<mode> ». Le mode « s » est réservé au systèmes multi-processeurs, elle va réinitialiser chacun des processeurs.

Le mode « b » permet quant à lui de rebooter en faisant un appel direct au bios qui se chargera de faire redémarrer la machine. Ce mode fonctionne plutôt bien car dans le cas d'un BIOS posant problème sur l'ACPI, on peut espérer avoir un reboot correct. C'est le cas sur de notre portable cité précédement.

Le mode « h » se chargera de faire redémarrer la machine en réinitialisant le processeur. C'est l'équivalent du mode « s » pour les environnements mono-processeurs. Pour finir, les modes « c » et « w » correspondent aux modes « cold » et « warn » : ces modes sont plus connus sous le nom de « reboot à froid » et « reboot à chaud ». Le premier effectuera les tests de mémoire tandis que le second exécutera un reboot plus court.

De manière générale, on utilisera plutôt le mode « b » ou « h » pour les systèmes mono-processeurs récalcitrant et le mode « s » pour les systèmes multi-processeurs.

== Toujours plus de performance ==
Votre configuration est bien stable depuis un certain temps. Toutefois vous trouvez qu'elle est un peu lente, elle ne vous donne pas satisfaction par rapport à ce qu'elle devrait fournir.
Cette partie de l'article va explorer comment vérifier et corriger les problèmes de performance des différents composants.
Note: certaines configuration mono-processeur nécessitent de désactiver LAPIC (nolapic)

=== Le disque dur ===

Il arrive parfois que le disque dur semble un peu lent et pénalise le système dans son ensemble. Hdparm est là pour vous aider à y voir plus clair. Hdparm est à l'origine conçu pour les systèmes de disques IDE de type PATA. Le nouveau système de disque SATA, ne permet pas toujours en fonction de l'implémentation, l'appel à toutes ces astuces. Cependant les nouvelles séries de kernel à partir du 2.6.15 devrait permettre une gestion plus unifiée des systèmes de disques PATA et SATA.

Le test « hdparm -t /dev/<mon_device> » permet de tester la vitesse de lecture depuis le disque dur jusqu'en mémoire. Une valeur de 25Mo/sec est un minimum pour des machines récentes. Plusieurs paramètres peuvent influencer les performances d'un disque IDE.
La commande « hdparm -cd » permet de vérifier que les entrées/sorties sont réalisées en 16-bit (le mode 32-bit n'offre pas de performance supplémentaire) alors que le DMA (Direct Memory Access) est activé. Ceci permet la minimisation de l'utilisation du processeur pendant les accès au disque dur.

<code>[root@R1 ~]# hdparm -cd /dev/hda
/dev/hda:
IO_support = 0 (default 16-bit)
using_dma = 1 (on)
[root@R1 ~]# </code>

La commande « hdparm -c0d1 /dev/<mon_device> » permet de configurer le périphérique dans ce mode. Le noyau de votre distribution Linux devrait le réaliser de manière automatique.

L'option « -I » permet d'obtenir plus d'informations sur la configuration de votre disque dur.

<code>[root@R1 ~]# hdparm -I /dev/hda
/dev/hda:
ATA device, with non-removable media
Model Number: FUJITSU MHT2040AT
Serial Number: NN77T3C13KB9
Firmware Revision: 0022
Standards:
Used: ATA/ATAPI-6 T13 1410D revision 3a
Supported: 6 5 4 3
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 78140160
device size with M = 1024*1024: 38154 MBytes
device size with M = 1000*1000: 40007 MBytes (40 GB)
Capabilities:
LBA, IORDY(cannot be disabled)
bytes avail on r/w long: 4 Queue depth: 1
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 128 (0x80)
Recommended acoustic management value: 254, current value: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
* Look-ahead
* Write cache
* Power Management feature set
Security Mode feature set
* SMART feature set
* Mandatory FLUSH CACHE command
* Device Configuration Overlay feature set
* Automatic Acoustic Management feature set
* SET MAX security extension
Power-Up In Standby feature set
* Advanced Power Management feature set
* DOWNLOAD MICROCODE cmd
* SMART self-test
* SMART error logging
Security:
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase
40min for SECURITY ERASE UNIT.
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct
[root@R1 ~]#</code>

On y retrouve le modèle, le numéro de série et la version du firmware qui peuvent être utiles en cas de contact avec le Service Après-Vente ou de mise à jour pour une série de firmwares défaillante.

La ligne commençant par « DMA » dans la partie « Capabilities » permet d'afficher la vitesse de transfert négociée entre le disque dur et le driver IDE de Linux. L'étoile précède la valeur actuelle. Dans cet exemple, le mode udma5 est sélectionné : ceci est conforme aux machines disponibles sur le marché depuis environ 3 ans.

Pour rappel, voici le tableau de conversion entre le mode DMA et la vitesse maximale associée.

Type de fonctionnement
Vitesse Maximale en MO/sec
UltraDMA 0
16,6
UltraDMA 1
25
UltraDMA 2
33,3
UltraDMA 3
44,4
UltraDMA 4
66,6
UltraDMA 5
100
UltraDMA 6
133,33

Une configuration actuelle ne devrait pas être en dessous de UDMA5. Si ce n'était pas le cas, on peut essayer de renégocier la vitesse de transfert à l'aide de la commande :

<code>hdparm -X udma5 </code>

Celle-ci permet de forcer le mode UltraDMA5. Il faut utiliser cette commande avec précaution car elle pourrait générer des pertes ou de la corruption de données en cas de transfert pendant ce changement de mode.

Vous pouvez aussi impacter les performances de votre disque dur en modifiant sa vitesse de rotation. Cette fonctionnalité connue sous le nom de Automatic Acoustic Management (AAM) est utilisable avec l'option « -M » de hdparm. La valeur 128 représentera la vitesse la plus faible avec un disque silencieux, la valeur 254 la vitesse la plus élevée mais avec comme contre-partie un disque plus bruyant. On pourra noter des différences de quelques Mo/sec selon les configurations.

Il est aussi à noter que l'utilisation de logiciels permettant une meilleure gestion d'énergie (cpufreq, laptop-mode) peut dégrader les performances d'un disque dur de manière notable.

=== Configuration bas niveau du réseau ===

Le réseau local filaire peut parfois être un peu lent. Voici quelques tests pour vérifier si la lenteur provient du logiciel, du noyau ou du matériel. Tout d'abord, explorons la trousse à outils indispensable pour analyser votre carte réseau : ethtool. Digne successeur de mii-tool, il permet de s'informer sur la configuration de votre carte réseau.

Il suffit de lancer « ethtool <votre_interface> » » pour obtenir la configuration matérielle de votre carte. On y retrouve les modes supportés par votre carte (Supported Link Modes ainsi que la vitesse actuelle (Speed), obtenue par auto-négociation dans cet exemple.

On peut également savoir si le câble réseau est connecté à la carte grâce à la ligne « Link Detected ». Le type de « duplex » utilisé permet également de savoir si la négociation avec l' élément actif au bout de votre câble (commutateur, concentrateur ou une autre machine) a correctement fonctionné. Le duplex définit le mode de transmission : le mode half-duplex indique que l'on émet puis on reçoit des données, le mode full-duplex indique que l'on peut émettre et recevoir en même temps des données. Le mode full-duplex est donc plus que recommandé pour vos équipements réseaux.

<code>[root@konilope ~]# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Current message level: 0x000020c1 (8385)
Link detected: yes
[root@konilope ~]# </code>

=== Mesurer les {contre}performances de votre réseau ===

Une fois vérifiée la bonne configuration de votre matériel, nous pouvons passer à la vérification des performances entre deux machines.

L'utilitaire netpipe (http://www.scl.ameslab.gov/netpipe/) permet de réaliser des tests de performance mais aussi d'intégrité entre deux machines. Il permet de tester les performances du réseau au travers la couche IP et non pas depuis un mode plus bas niveau comme pourrait l'être un test utilisant directement le driver Ethernet. Ce test permet donc de valider que la configuration matérielle mais aussi logicielle est correcte.

Sur la première machine, exécutez « NPtcp » : netpipe se positionne en mode « serveur ».
Sur la seconde machine, exécutez « NPtcp -h <machine1> » : netpipe se connecte au serveur netpipe de la machine nommée machine1 pour effectuer le test de performance.

Le test par défaut teste les communication allant de 1 octet jusqu'à 8 Mo. Il peut prendre plusieurs minutes si le réseau est « lent ». Le test va montrer pour chaque taille de paquet la performance obtenue. Il est normal d'obtenir des performances faibles pour des paquets d'une taille inférieure à 8 Ko. Transporter des petits paquets nécessite de réaliser beaucoup d'opérations pour le processeur pour une quantité d'information minime. Les performances seront meilleures à partir d'environ 16 Ko et maximales à partir de 128 Ko. Sur un système utilisant du gigabit ethernet, on constatera une performance de 39Mbps à 256 octets, 287Mbps à 4Ko, 614Mbps à 16Ko, 845Mbps à 128Ko, 895Mbps à 8Mo.

Vous pouvez ainsi vérifier et comparer facilement les performances de votre configuration réseau. Netpipe permet également de tester la vitesse du réseau pour une taille de paquets définie entre la taille indiqué par l'option « -l » et la taille indiquée par l'option « -u ». Ainsi, NPtcp -l 16384 -u 16384 permet de tester la bande passante réseau pour une taille de paquet égale à 16Ko.

L'option « -n <nb-cycle> » permet de définir le nombre de boucles à réaliser pour le test (50 par défaut). Enfin, pour réaliser des tests « full-duplex », on utilisera l'option « -2 ». Ce test permet de s'assurer du bon fonctionnement du mode de communication permettant l'écriture et la lecture simultanées.

Attention, même si ce test donne de bons résultats, cela ne veut pas dire que la configuration est exempte d'erreur de configuration. Par exemple, les performances réseaux peuvent être très bonnes en point à point mais mauvaises lorsque l'on aura une charge réseau avec plusieurs clients. Dans cette situation, il faut vérifier que le contrôle de flux est bien activé sur toutes les machines. L'option « ethtool -a » permet de vérifier que les champs « rx » et « tx » sont placés sur « on ». Si ce n'était pas le cas activez-les avec la commande « ethtool -A eth0 rx on » et « ethtool -A eth0 tx on ».

Les cartes réseaux, des serveurs essentiellement, permettent maintenant de réaliser le « tcp segment offload ». Cette technique permet de décharger une partie du traitement TCP directement dans l'électronique de la carte réseau. Ceci à pour effet de décharger le processeur central d'un traitement fastidieux. L'option « -k » d'ethtool permet de consulter l'état de cette fonctionnalité (off/on). On pourra l'activer sur des serveurs générant un gros trafic réseau par exemple : « ethtool -K eth0 tso on ».

Vous voilà maintenant équipé de nouveau outils pour traquer la perte de performances de votre installation réseau. Ceci couplé aux habituels tcpdump/ethereal, voilà une belle panoplie du zorro du réseau.

=== Quand la latence s'en mêle ===

La latence représente le temps nécessaire à un système pour prendre en compte un événement.

Il arrive que certains périphériques de votre machine nécessitant des débits importants ou une latence assez faible sur le bus PCI soient « poussifs ». On retrouve dans cette catégorie les cartes vidéos accélératrice 3D, les cartes son et les cartes d'acquisition firewire ou DVB (récepteur de télévision numérique terrestre : TNT).

Un périphérique branché sur le bus PCI doit attendre que le bus soit libre pour émettre les données vers la mémoire centrale. Le bus PCI qui est le coeur de communication des périphériques est donc soumis en permanence à un arbitrage qui permet de décider qui doit émettre des données et qui doit attendre. Cet arbitrage est en partie réalisé grâce au « latency_timer ».

Chaque périphérique possède une valeur de « latency_timer » comprise en 0 et 248 cycles d'horloge du bus. Plus la valeur sera importante plus le périphérique disposera de temps pour transmettre des informations. Une latence de 248 cycles permet d'obtenir une priorité forte sur le bus, ce qui permet un débit important. A contrario, une latence de 0 indiquera au périphérique qu'il doit cesser ses transmissions si un autre composant à besoin du bus : ceci se traduira par une perte de bande passante importante.

La configuration réalisée par défaut sur votre machine doit être correcte mais il peut arriver qu'une carte 3D ou DVB soit configurée avec une latence trop faible, ce qui aurait pour conséquence d'offrir une image saccadée et peu fluide. Une carte son offrirait également le même type de symptômes avec un son hâché ou excessivement métallique.

Heureusement, une série d'outils est là pour vous aider à diagnostiquer le problème mais aussi à le résoudre. Le projet pciutils (http://atrey.karlin.mff.cuni.cz/~mj/linux.shtml#pciutils) contient deux outils indispensables: lspci et setpci. Bien entendu, votre distribution favorite devrait posséder ce logiciel, il vous suffira de l'installer avec votre gestionnaire de paquet favori (urpmi, apt, smart).

La commande « lspci » vous permet de lister les périphériques PCI disponibles sur votre ordinateur (cf article paru dans le numéro 68). Cet exemple se basera sur une carte vidéo ayant pour adresse sur le bus PCI « 01:00.0 ».

<code>[root@lagirafe] lspci -v -s 01:00.0
01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX Go5200 32M/64M] (rev a1) (prog-if 00 [VGA])
Subsystem: Samsung Electronics Co Ltd: Unknown device c00f
Flags: bus master, 66Mhz, medium devsel, latency 16, IRQ 11
Memory at c8000000 (32-bit, non-prefetchable) [size=16M]
Memory at d8000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 3.0
[root@lagirafe]</code>

On retiendra dans cette ligne, la valeur 'latency 16'. Ceci risque de poser problème lorsque celle-ci aura besoin d'un fort débit pendant un jeu par exemple. Augmenter la latence va donc se révéler nécessaire pour ce périphérique.

La commande setpci permet de modifier les paramètres PCI d'un périphérique ou d'un bus complet avec tous ses périphériques.

La commande « setpci -v -d 01:* latency_timer=20 » permet de positionner tous les périphériques du bus 01 à une valeur de 32 cycles. Il est à noter que la commande setpci utilise des valeurs en hexadécimal mais lspci affichera les valeurs en décimal.

Pour en revenir à nos moutons, la correction de la latence de cette carte graphique se fera avec la commande « setpci -v -d 01:00.0 latency_timer=f8 ». Ceci positionne donc la carte sur la plus grande valeur de latence possible, ce qui lui garantira la plus grande bande passante possible. Il est possible d'utiliser la valeur « ff » comme paramètre pour « latency_timer » mais celui-ci sera converti à la volée par la commande setpci en « 0xf8 ».

Attention, certains composants de votre machine doivent rester en « latency_timer=0 » pour garantir une bon fonctionnement de votre système : il ne faudra donc pas modifier les latences des contrôleurs mémoire et des ponts PCI connectés généralement sur le bus « 0:* ».

== DSDT : le cauchemar continue ! ==

Cette partie de l'article a pour but d'expliquer le problème que peut représenter la table DSDT pour un certain nombre de machines et surtout les ordinateurs portables.

La norme ACPI 3.0 de Septembre 2004 disponible gratuitement à l'adresse http://www.acpi.info/DOWNLOADS/ACPIspec30.pdf définit la DSDT comme une table remplie par un OEM permettant au système d'exploitation de découvrir les ressources pour la gestion de l'énergie avancée, de la gestion thermique ainsi que la gestion du Plug'nPlay des ressources définies par l'ACPI.

Voici une description certes un peu théorique mais nécessaire pour bien comprendre la problématique et ses conséquences. Le constructeur de l'ordinateur doit donc définir dans le BIOS une table contenant une liste de ressources et leurs configuration et ce pour que le système d'exploitation puisse s'en servir. Noble cause n'est il pas ? Tout au long des 618 pages de ce document sont spécifiés les éléments du langage à utiliser ainsi que sa syntaxe. L' « ACPI Source Language » permettra donc aux développeurs d'écrire des DSDT puis de les compiler dans un format nommé « ACPI Machine Language » en utilisant un compilateur adéquat. Le système d'exploitation utilisera la table compilée (AML) pour accéder aux ressources ACPI.
Sur la plupart des ordinateurs portables, la table DSDT ne respecte pas la norme ACPI dans sa syntaxe. Ceci est très gênant car cela bloque le code de l'interpréteur ACPI du noyau Linux qui essaie de la lire. Le résultat est sans appel, pas d'ACPI, pas de gestion d'énergie avancée, plus de ventilation automatique sur certains modèles d'ordinateurs, plus de touche de gestion de contraste/luminosité sur d'autres etc...

Ceci est très gênant sur un ordinateur portable. Alors que faire ? Dans un premier temps, prévenir le constructeur que son BIOS est incorrect et ne respecte pas la norme ACPI. La réponse se fait toujours attendre pour tous ceux qui « osent » poser la question au support technique : à savoir, les constructeurs ignorent tout simplement les mails de ce type.
La seconde étape puisque vous êtes devant le fait accompli d'une machine non conforme, il va falloir corriger cette table. Il suffit de récupérer la table actuelle via la commande 'cat /proc/acpi/dsdt > dsdt.aml' si vous avez la chance d'avoir un répertoire /proc/acpi malgré une table DSDT endommagée, sinon utilisez la commande 'acpidump -b -t dsdt -o dsdt.aml'. La commande acpidump est fournit dans le projet pmtools (ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20050926.tar.bz2)
Vous avez donc extrait la table DSDT de votre système. Il ne reste plus qu'à essayer de la recompiler. Pour cela, le compilateur IASL de la société Intel (http://developer.intel.com/technology/iapc/acpi/downloads.htm) offre sous Linux et Windows une plate-forme de compilation pour le langage ASL.

Suivez les instructions du site pour télécharger et compiler la version unix d'iasl. Ensuite, décompilez la table avec la commande « iasl -d dsdt.aml ». Le fichier dsdt.dsl vient d'être créé par le décompilateur. Il suffit de le recompiler avec la commande « iasl -tc dsdt.dsl » pour constater les dégâts ! La DSDT que vous avez dans votre BIOS est généralement compilée par le compilateur de Microsoft qui semble autoriser une syntaxe plus qu'approximative.
Si vous avez de la chance, votre DSDT s'est recompilée sans erreurs, vous obtenez donc un fichier dsdt.hex et un fichier dsdt.aml. Il ne reste plus qu'à injecter cette dsdt dans le noyau Linux et le tour sera joué.

Si vous avez moins de chance, votre DSDT est syntaxiquement incorrecte et génère des erreurs. Les expliquer plus en détails nécessiterait un article complet, il ne sera cité que les plus « habituelles » (sic).

<code>dsdt.dsl 2626: Field (ECR, DWordAcc, Lock, Preserve)
Error 1048 - ^ Host Operation Region requires ByteAcc access </code>

Cette erreur présente à ligne 2626 du fichier dsdt.asl indique une erreur de type dans la déclaration du champ ECR. Il suffit dans ce cas de changer le mot « DWordAcc » par « ByteAcc ». Celle-ci reste assez simple à corriger, on se demande donc pourquoi les constructeurs ne prennent pas le temps de vérifier et de corriger leur BIOS.

<code>dsdt.dsl 2672: Method (_GLK, 1, NotSerialized)
Warning 2024 - ^ Reserved method has too many arguments ( _GLK requires 0) </code>

La méthode _GLK n'a besoin que de 0 paramètre tandis que ce code en utilise 2 ! La correction est assez simple : il suffit de remplacer la ligne 2672 par « Method(_GLK) ».

Pour plus de détails sur la correction des erreurs de compilation de votre table dsdt, je vous recommande les tutoriaux disponibles depuis la page http://acpi.sourceforge.net/dsdt/index.php du projet ACPI.

Votre DSDT est compilée avec succès, il ne vous reste plus qu'à l'ajouter pour que votre noyau puisse l'utiliser à la place de celle fourni par le BIOS (modifiable uniquement par le constructeur, via une mise à jour).

Il existe trois possibilités pour inclure une table DSDT : la modification du noyau Linux ( noyau < 2.6.9), l'injection de la DSDT dans la configuration du noyau (noyau >= 2.6.9), l'intégration de la table DSDT dans l'initrd qui nécessite un patch kernel disponible à l'adresse http://gaugusch.at/kernel.shtml.

Pour les noyaux 2.6.9 et supérieur, copiez votre fichier dsdt.hex sous le nom «/usr/src/linux/include/acpi/dsdt_table.h » puis reconfigurez votre noyau.
Insérer « dsdt_table.h » dans l'option « Include you custom DSDT » disponible dans le menu « Power Management/ACPI/ ». Recompilez votre noyau et redémarrez avec votre nouveau noyau.
Pour les noyaux inférieurs à 2.6.9, il est possible de modifier le code source de votre noyau pour intégrer votre DSDT mais il est préférable d'utiliser le patch permettant l'insertion de la table DSDT dans l'initrd. Recompilez votre noyau avec ce patch, puis suivez la procédure décrite ci-dessous.

Certaines distributions Linux comme « Mandriva Linux » possèdent le patch qui permet de n'avoir qu'à reconstruire l'initrd avec la commande « mkinitrd –dsdt=/boot/dsdt.aml /boot/initrd-`uname -r`.img `uname -r` » puis de relancer lilo avant de redémarrer votre machine. Lors du démarrage de celle-ci vous devriez voir le message suivant :

<code>ACPI: Looking for DSDT in initrd... found (at offset 0x4f8d9).
ACPI-0294: *** Info: Table [DSDT] replaced by host OS</code>

Vous voilà maintenant avec une table DSDT correcte et un ACPI fonctionnel. La question qui reste ouverte est pourquoi les constructeurs n'utilisent pas un compilateur digne de ce nom pour permettre à leur clients de pouvoir utiliser d'autres systèmes d'exploitation que Windows de Microsoft.

Pour la petite histoire, si vous cherchez dans votre dsdt vous risquez de tomber ce genre de lignes :

<code>If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), Zero))
If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))
If (LEqual (SCMP (\_OS, "Microsoft WindowsME: Millennium Edition"), Zero))
If (LEqual (SizeOf (\_OS), 0x27)) </code>

Lorsque qu'un système d'exploitation souhaite utiliser les ressources ACPI du BIOS, il utilise son nom de système d'exploitation (acpi_os_name). On retrouve donc dans les bios des parties qui ne seront exécutées que pour certains systèmes d'exploitation de Microsoft. On retrouve même certains tests où c'est la longueur du nom qui compte...... Ceci prouve bien que les constructeurs d'ordinateurs savent corriger des tables DSDT pour les systèmes d'exploitation mais pas forcément pour le notre malheureusement. Depuis le noyau 2.6.9, le noyau Linux utilise « Windows NT » comme « acpi_os_name » pour assurer une meilleure compatibilité matérielle dixit Len Bron d'Intel dans le changelog de cette version.

== Comment trouver le pilote qui va avec votre matériel ? ==

Cette question on se la pose souvent mais uniquement lorsque l'on essaye de brancher un nouveau périphérique sur sa machine. Les distributions récentes permettent de détecter automatiquement votre matériel et de lui associer un pilote avec sa configuration. Ce mécanisme fonctionne plutôt bien mais cela n'évite pas les dysfonctionnements voir l'absence de fonctionnement.

Pour vérifier si votre noyau Linux est capable de supporter un nouveau périphérique PCI par exemple, il suffit d'en récupérer les identifiants PCI (constructeur et produit) puis de les rechercher dans le fichier « /lib/modules/`uname -r`/modules.pcimap » qui est auto-généré lors de la commande depmod.

L'utilitaire « lspcidrake -v » vous permet de trouver les identifiants PCI de votre carte, la commande « lspci » vous permet de trouver le nom de votre périphérique puis faites un « lspci -n » pour en trouver la correspondance numérique. On utilisera la position du périphérique sur le bus pour retrouver la correspondance numérique « 02:05.0 » dans cet exemple.
<code>[root@pumphome] lspci
[....]
02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01)
[root@pumphome] lspci -n
[...]
02:05.0 Class 0200: 14e4:4401 (rev 01)
[root@pumphome]</code>

Ainsi cette carte réseau possède les identifiants 14e4 (constructeur) et 4401 (produit). Il suffit de rechercher cette valeur dans le modules.pcimap, ce qui nous donnera la correspondance en module (pilote).

<code>[root@pumphome] grep "0x000014e4 0x00004401" /lib/modules/2.6.12-12mdk-i686-up-4GB/modules.pcimap
b44 0x000014e4 0x00004401 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
bcm4400 0x000014e4 0x00004401 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0</code>

On voit ici que cette carte peut utiliser le driver b44 ou le driver bcm4400. On ne trouve pas toujours les identifiants PCI de produit sous leur forme directe, on peut également trouver « 0Xffffffff » qui indique que tous les cartes du constructeur sont gérées par un module.
Il ne vous restera plus qu'à effectuer la configuration associée à ce périphérique pour qu'il fonctionne correctement.

== Conclusion ==

La fin de cet article conclut une toute petite série de deux articles ayant pour but de vulgariser l'architecture de nos machines, de découvrir les outils disponibles pour mieux comprendre leur configuration et au besoin régler les problèmes de configuration matérielle qui ont souvent le don de nous pourrir la vie.

Merci à LaurentJ de #Mandrivafr pour ses tests complémentaires sur les problèmes d'IO-APIC. Un énorme merci à Nicolas Planel pour sa relecture pointue et également Anne pour sa patience de girafe à relire et « quaurigé »mes « photes », ainsi qu'à tous ceux qui m'ont aidé à découvrir ce que je restitue dans cet article.

Cet article a été publié dans Linux Magazine France n°78. Il est publié sur Léa avec l'aimable autorisation de l'éditeur.

Découvrez les ressources de votre machine (La suite)

2006-06-11T20:27:22Z

Ennael : /* La mémoire qui flanche ? */

= Découvrez les ressources de votre machine (La suite) =

== Introduction ==

A nouvelle année, nouvelles résolutions ! Paru dans le numéro 68, un premier article dédié à la découverte des outils disponibles pour la récupération des configurations de votre machine promettait une suite. Je vous propose donc de reprendre ce voyage au centre de votre ordinateur.

Cet article sera articulé autour du diagnostic de pannes et des correctifs associés mais aussi de « trucs & astuces » permettant d'optimiser votre configuration.

== Savez-vous planter les choux ? ==

Les choux peut-être pas mais les ordinateurs je pense que c'est arrivé au moins une fois à chaque lecteur qui lit cet article. Rien de plus énervant qu'un écran qui se fige, le pointeur de souris qui ne se déplace plus, le clavier qui ne répond plus non plus.... Planté ! Ce constat est assez facile à établir mais en trouver la cause reste un problème nettement plus complexe tellement le nombre de causes possibles est important.

Deux solutions : ignorer le problème et relancer le système en se disant que ça « passera », ou alors chercher la cause du problème en essayant de trouver une méthode reproduisant le « plantage » tant redouté.

La première solution fonctionne assez bien mais si l'on à faire à un « vrai » problème de configuration matérielle ou logicielle, on arrivera assez vite à ne plus pouvoir éviter la seconde voire la troisième. J'allais oublier cette troisième solution destinée aux plus riches d'entre vous : changer de matériel. Cette solution coûteuse peut parfois se révéler efficace, parfois pas du tout. A quoi bon changer un composant sans savoir si c'était bien celui-ci qui posait problème ?
Quelque soit la solution retenue, il sera de toute manière nécessaire de localiser la panne pour y apporter la réponse adéquate. Certaines sociétés ou particuliers se sont spécialisés dans ce dépannage ou l'utilisateur est « dépassé » par les événements.

Cet article vous fera, je l'espère, découvrir quelques outils et méthodes pour valider un par un les composants de votre ordinateur. Cela vous permettra j'espère d'être un peu moins dépourvu quand un problème surviendra. L'article reproduira les étapes qu'il faut suivre pour isoler le « fautif ».

== Les causes possibles d'un « plantage » ==

On retrouve deux grandes catégories de pannes provoquant des dysfonctionnements importants sur un système informatique.
* une panne du matériel
* une erreur logicielle au niveau du noyau et des pilotes (drivers)

Il faudra donc être capable de séparer la panne matérielle qui « force » l'ordinateur à entrer dans un mode de fonctionnement non prévu et instable, de l'erreur logicielle qui équivaut à demander à l'ordinateur de faire « n'importe quoi » et qui va donc se « planter ».

Le terme « planté » utilisé ici équivaut à un arrêt du système à cause d'erreurs sévères : instruction illégale ou composants défaillants. Le terme de « plantage » est aussi utilisé pour décrire le fonctionnement d'une application qui se ferme inopinément. Ce cas est plus souvent lié à une erreur de programmation de l'application qu'à une erreur du système. Nous ne parlerons donc pas de ce second cas dans cet article.

== La mémoire qui flanche ? ==

Une cause « classique » des dysfonctionnements se situe au niveau de la gestion de la mémoire de votre machine. Je ne parle pas d'allocation mémoire réalisée par votre système d'exploitation favori mais bien de la manière avec laquelle la carte mère configure et utilise vos barrettes de mémoire. Les applications chargent en mémoire des données et des instructions destinées au processeur. Voici un scénario qui peut provoquer l'arrêt de la machine.

Votre application favorite est lancée depuis la ligne de commande ou une interface graphique via un « clic » de souris. Votre système d'exploitation va donc charger ce programme en mémoire puis en exécuter les instructions. Au plus bas niveau de votre système, le processeur exécute des instructions en langage machine (assembleur) présente en mémoire.
Malheureusement, votre mémoire est défaillante et elle n'arrive pas à maintenir un état stable des informations qui lui sont confiées. Par exemple, la lettre C est représentée par le code 67, ou « 1000011 » en binaire. Si la zone mémoire change d'état, alors le contenu de la valeur stocké à cet endroit changera : on pourrait se retrouver avec « 1000010 ». Un seul bit a changé, mais on passe de la lettre 'C' (67) à la lettre 'B'(66). Le résultat ne se fait pas attendre, le processeur se retrouve à exécuter des instructions qui n'ont plus de sens, provoquant l'arrêt de la machine.

Les pannes de mémoires sont généralement dues à des composants endommagés, des barrettes incompatibles ou un « timing d'accès » à la mémoire (nommé CAS (Column Address Strobe) dans la plupart des BIOS) trop agressif permettant des lectures dans des zones mémoires avant que les écritures aient eu le temps de se stabiliser pour en garantir le contenu.

Il est assez simple de valider votre configuration mémoire grâce à l'utilitaire memtest (http://www.memtest.org). Cet utilitaire de taille très modeste, 96 Kilo-octets, est écrit en assembleur ce qui lui permet de s'exécuter indépendamment du système d'exploitation. Ceci garantit un test « proche » du matériel, sans sur-couche pouvant apporter d'autres problèmes.
La version 1.65 actuelle est téléchargeable sous deux formes : une iso que l'on peut graver sur un CDRW de préférence vu la petite taille du programme ou sous la forme d'une amorce système (pre-compiled bootable binary). Il suffira de décompresser l'archive puis d'exécuter la commande suivante :
<code>dd if=memtest.bin of=/dev/fda</code>

Ceci écrasera le contenu de votre disquette pour y copier memtest. Rebootez l'ordinateur avec la disquette placée dans le lecteur, memtest devrait se lancer.

[[Image:memtest.jpg]]

La figure 1, est une capture d'écran de memtest en fonctionnement. Le barre de progression principale affichée en haut à droite de l'écran (2% dans cet exemple) permet de suivre la progression du test. Les erreurs apparaissent dans la partie inférieure de l'écran. Il suffit de laisser fonctionner memtest au moins une fois jusqu'à 100%. Si aucune ligne ne s'est affichée alors vou pouvez considérer que la mémoire est fonctionnelle. Dans le cas contraire, il faudra soit procéder à son remplacement s'il s'agit d'une seule barrette mémoire, soit tester les barrettes indépendamment (l'une puis l'autre) avec ce logiciel. Dans le cas de 2 ou 3 barrettes qui ne fonctionnement pas correctement ensemble mais qui fonctionnement correctement individuellement, il faudra vérifier qu'elles sont bien de même modèle/marque et remettre le Bios dans une configuration initiale.

Votre mémoire est bonne ? Testons les autres composants de votre machine pour traquer la source de ce plantage.

== Il ne fait pas un peu chaud là ? ==

Ces dix dernières années la puissance consommée et dissipée par nos ordinateurs a littéralement explosé ! Du 486 qui ne nécessitait quasiment pas de ventilateur, on est arrivé à des stations de travail/jeu avec des alimentations pouvant atteindre 1KiloWatt pour les dernières et 500watt pour des modèles plus « grand public ». Le processeur est un des composants gourmands de la machine. Certains modèles peuvent consommer plus de 130W ! Autant dire que si le système est mal ventilé, la montée en charge du processeur peut provoquer un échauffement important provoquant une surchauffe de celui-ci. S'il dépasse ces caractéristiques de fonctionnement, il va alors exécuter du code incorrect provocant un plantage du système.

Un bon test pour vérifier que votre processeur n'est pas la cause de votre instabilité : commencez par relever la température de votre machine au repos à l'aide des informations fournies soit par l'acpi soit pas lm_sensors.

<code>[erwan@R1 ~]$ cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 42 C
[erwan@R1 ~]$

[root@konilope ~]# sensors | grep Temp
M/B Temp: +39°C (low = +15°C, high = +40°C) sensor = thermistor
CPU Temp: +127°C (low = +15°C, high = +45°C) sensor = thermistor
Temp3: +44°C (low = +15°C, high = +45°C) sensor = thermistor
[root@konilope ~]</code>

La méthode utilisant lm_sensors nécessite une interprétation de la part de l'utilisateur. Dans cet exemple, il apparaît évidant que le processeur ne peut avoir une température de fonctionnement aussi élevée (127°C). L'erreur est du à un mauvais calcul de la part de lm_sensors. Il se base sur le type de capteurs thermiques utilisé par la carte mère pour calculer la température des différents composants. Malheureusement, le montage électrique autour du capteur de température peut varier d'un modèle de carte à un autre, ce qui fausse les calculs. On considéra donc, que pour cette machine (konilope) sa température se situe aux alentours de 42° : valeur moyenne entre les deux valeurs « cohérentes » relevées par lm_sensors. On pourra cependant vérifier cette approximation en relevant la température du disque sur à l'aide de smartmontools.

<code>[root@konilope ~]# smartctl -A /dev/hda | grep Temperature
194 Temperature_Celsius 0x0022 042 052 000 Old_age Always - 42
[root@konilope ~]# </code>

De manière générale, il est préférable de maintenir sa machine en dessous des 55° et celle de son processeur en dessous de 70°C. Au delà, le système risque d'être instable. Si ce n'est pas le cas, effectuez les modification nécessaire pour y parvenir : meilleure ventilation du processeur ou du boîtier par exemple.

Ensuite, téléchargez l'utilitaire cpuburn depuis un mirroir (http://pages.sbcglobal.net/redelm/cpuburn_1_4_tar.gz) ou depuis votre distribution linux favorite (oui, oui, urpmi cpuburn ça fonctionne ;o)).

Vous y trouverez plusieurs programmes nommés burnXX ou XX représente votre processeur. La version P6 sera à utiliser sur les processeurs Intel Pentium 4, la version K7 pour les processeurs Athlon x86. Pour les processeurs plus récents, utilisez la version P6.
Ce logiciel réalise des boucles en langage assembleur ayant pour but de stresser votre processeur de manière importante et donc le faire chauffer. Lancez cpuburn autant de fois que vous avez de processeur sur votre machine puis observez la température de votre machine. Si lors de la montée en température votre système se fige, alors vous avez un problème de thermie. Si cpuburn ne fait pas planter votre ordinateur au bout de 10mn, vous pouvez considérez que votre système est stable de ce coté là. Vous pouvez aussi utiliser ce test pour vérifier que vos ventilateurs d'ordinateurs portable se déclenchent bien en cas de surchauffe.
Sur un portable récent, on obtient le résultat suivant au bout de quelques minutes de cpuburn.

<code>[root@R1 ~]# cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 80 C
[root@R1 ~]# </code>

Malgré la température très élevée du processeur, le système est resté stable ce qui permet de valider qu'il est capable d'encaisser une montée en température élevée. Bien entendu, plus votre machine sera « chaude » plus elle s'usera rapidement. Il ne faut pas oublier que les autres composants peuvent souffrir de la chaleur dégagée par le processeur par exemple : les disques durs en sont un bon exemple car les plateaux ne supportent pas la chaleur.
Ce test est bon aussi ? A priori, les composants de base de votre système sont en bon état, vous pouvez commencer à regarder du coté configuration logicielle.

== APIC es tu là ? ==

Le manque de stabilité peut aussi s'expliquer par la gestion des interruptions.
L'architecture PIC (Programmable Interrupt Controllers) représentée par la famille de composants Intel 8259, permettait une gestion de 8 interruptions pour un unique processeur. On les associe par 2 pour obtenir les 16 niveaux d'interruptions nécessaire depuis nos vieux 80286 (milieu des années 80). Avec l'arrivée des systèmes multi-processeurs, l'architecture APIC (Advanced Programmable Interrupt Controllers) (Intel 82093) à été ajoutée pour permettre une gestion plus fine des interruptions. En effet, dans un contexte multi-processeurs, il est nécessaire de pouvoir choisir quel processeur traitera quelle interruption pour ne pas rester figé dans l'ancien modèle (PIC) où le processeur de « boot » est assigné à un ensemble d'interruptions.

De plus, l'architecture APIC apporte une gestion de 24 interruptions, une gestion de priorité des interruptions et le routage de l'interruption sur le bon processeur, contre un simple routage de 2*8 interruptions dans le modèle PIC sur un seul processeur. Depuis une dizaine d'années, Intel propose le modèle APIC comme nouvelle architecture, y compris pour les systèmes mono-processeurs. Les ordinateurs récents, y compris les portables, sont maintenant équipés uniquement de composants APIC même si l'on peut obtenir un comportement de type PIC avec ceux-ci.

L'architecture APIC est constituée d'un ou plusieurs composants situé physiquement dans le southbridge (IO-APIC), généralement un par bus, et un composant situé dans le processeur : le Local APIC (LAPIC). Le LAPIC va permettre la gestion des interruptions au niveau du processeur local. Il permet aussi de générer des interruptions par exemple pour transmettre des interruptions à des processeurs voisins dans le contexte d'un système multi-processeurs, ces messages sont appelés IPI (Inter Processor Interrupts).

De plus le Local APIC (LAPIC) inclut un « timer » de précision cadencé à la fréquence du bus, généralement il peut être utilisé par l'ordonnanceur de votre système d'exploitation favori ou d'autres outils de haut niveau (profiler kernel : oprofile, vtune). Les LAPIC et l'IO-APIC sont reliés par un bus spécifique pour permettre un échange rapide des informations.
Schema logique d'implémentation :

Les IO-APIC vont donc se charger de collecter les interruptions provenant des périphériques systèmes et d'en assurer le transfert vers le ou les processeur(s) suivant une route préalablement programmée par le BIOS et/ou le système d'exploitation.

Cependant, l'implémentation des APIC dans les BIOS peut provoquer certaines instabilités sur votre système Linux. Par expérience, il n'y a pas de règle pour trouver la configuration qui peut aider votre machine à se stabiliser car cela dépend de chaque machine. Des différences peuvent même exister entre deux versions de BIOS d'un même ordinateur. Cependant, dans la série 2.6 du noyau Linux et les version 2.4 récentes nous disposons d'outils permettant de re-paramétrer cette configuration en activant/désactivant les IO-APIC ou les LAPIC.

Chaque composant possède un activateur ou un inhibiteur, on aura donc d'un coté « apic » et « noapic » pour la gestion des IO-APIC, « nolapic » et « lapic » de l'autre pour la gestion des LAPIC. Ces 4 options sont à utiliser sur la ligne de commande du noyau, c'est à dire au moment où le « bootloader » (lilo ou grub par exemple) va charger le noyau en mémoire. L'utilisation de « apic » et « lapic » permet d'activer ces composants qui ne l'ont pas été par le BIOS. L'activateur « apic » n'est disponible que les architectures de type x86_64 car celui-ci est déjà activé sur les systèmes de type x86. On désactivera les APIC dans le cas où le système affiche des messages d'erreurs sur les APIC comme :

<code>« APIC error on CPU0: 40(40) »</code>

ou

<code>MP-BIOS bug: 8254 timer not connected to IO-APIC
failed.
timer doesn't work through the IO-APIC - disabling NMI Watchdog!</code>

La désactivation des IO-APIC permet par exemple de corriger le comportement parfois récalcitrant de certaines cartes vidéos qui ne parviennent pas à afficher correctement en mode 2D/3D (écran noir par exemple).

La non activation des LAPIC peut avoir comme conséquence un dysfonctionnement de l'ACPI (gestion d'énergie avancée). Ce cas est traité par le noyau, vous retrouverez dans les messages de démarrage la ligne suivante : « "Local APIC disabled by BIOS you can enable it with lapic ».

Pour résumer, si votre machine, en général à architecture mono-processeur, a tendance à se bloquer lors de l'utilisation de périphériques tels que le port usb, la carte graphique ou la carte son, essayez de désactiver le LAPIC puis l' IO-APIC puis les 2. Pour exemple, les cartes mère A7N8X de chez Asus ont largement tendance à se bloquer si l'on ne spécifie pas « nolapic » lors du boot. Sur certaines machines, il faudra faire le contraire à savoir forcer l'activation des LAPIC. Ceci dépendra de votre machine et de sa conception.

== A vos marques, rebootez ! ==

Certains machines peuvent présenter quelques soucis pour redémarrer. Encore une fois, on retrouve au coeur de ce problème l'interaction entre le noyau et le matériel notamment l'ACPI. Les ordinateurs portables dont le modèle HP nc6120 ont par exemple le bon goût de rester bloqués sur le message « No reboot fixup found for your hardware ». Ceci indique que le noyau ne connaît pas de contournement pour ce matériel (ce qui est le cas de la quasi totalité des ordinateurs) mais puisque vous voyez ce message c'est que votre machine n'a pas réussi à rebooter. Heureusement, il existe des contournements pour permettre un redémarrage plus « bas niveau ». Le noyau défini les modes suivants : « b » « c » « h » « s » et « w ».
Le mode de reboot peut être défini sur la ligne de commande du noyau suivant la forme « reboot=<mode> ». Le mode « s » est réservé au systèmes multi-processeurs, elle va réinitialiser chacun des processeurs.

Le mode « b » permet quant à lui de rebooter en faisant un appel direct au bios qui se chargera de faire redémarrer la machine. Ce mode fonctionne plutôt bien car dans le cas d'un BIOS posant problème sur l'ACPI, on peut espérer avoir un reboot correct. C'est le cas sur de notre portable cité précédement.

Le mode « h » se chargera de faire redémarrer la machine en réinitialisant le processeur. C'est l'équivalent du mode « s » pour les environnements mono-processeurs. Pour finir, les modes « c » et « w » correspondent aux modes « cold » et « warn » : ces modes sont plus connus sous le nom de « reboot à froid » et « reboot à chaud ». Le premier effectuera les tests de mémoire tandis que le second exécutera un reboot plus court.

De manière générale, on utilisera plutôt le mode « b » ou « h » pour les systèmes mono-processeurs récalcitrant et le mode « s » pour les systèmes multi-processeurs.

== Toujours plus de performance ==
Votre configuration est bien stable depuis un certain temps. Toutefois vous trouvez qu'elle est un peu lente, elle ne vous donne pas satisfaction par rapport à ce qu'elle devrait fournir.
Cette partie de l'article va explorer comment vérifier et corriger les problèmes de performance des différents composants.
Note: certaines configuration mono-processeur nécessitent de désactiver LAPIC (nolapic)

=== Le disque dur ===

Il arrive parfois que le disque dur semble un peu lent et pénalise le système dans son ensemble. Hdparm est là pour vous aider à y voir plus clair. Hdparm est à l'origine conçu pour les systèmes de disques IDE de type PATA. Le nouveau système de disque SATA, ne permet pas toujours en fonction de l'implémentation, l'appel à toutes ces astuces. Cependant les nouvelles séries de kernel à partir du 2.6.15 devrait permettre une gestion plus unifiée des systèmes de disques PATA et SATA.

Le test « hdparm -t /dev/<mon_device> » permet de tester la vitesse de lecture depuis le disque dur jusqu'en mémoire. Une valeur de 25Mo/sec est un minimum pour des machines récentes. Plusieurs paramètres peuvent influencer les performances d'un disque IDE.
La commande « hdparm -cd » permet de vérifier que les entrées/sorties sont réalisées en 16-bit (le mode 32-bit n'offre pas de performance supplémentaire) alors que le DMA (Direct Memory Access) est activé. Ceci permet la minimisation de l'utilisation du processeur pendant les accès au disque dur.

<code>[root@R1 ~]# hdparm -cd /dev/hda
/dev/hda:
IO_support = 0 (default 16-bit)
using_dma = 1 (on)
[root@R1 ~]# </code>

La commande « hdparm -c0d1 /dev/<mon_device> » permet de configurer le périphérique dans ce mode. Le noyau de votre distribution Linux devrait le réaliser de manière automatique.

L'option « -I » permet d'obtenir plus d'informations sur la configuration de votre disque dur.

<code>[root@R1 ~]# hdparm -I /dev/hda
/dev/hda:
ATA device, with non-removable media
Model Number: FUJITSU MHT2040AT
Serial Number: NN77T3C13KB9
Firmware Revision: 0022
Standards:
Used: ATA/ATAPI-6 T13 1410D revision 3a
Supported: 6 5 4 3
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 78140160
device size with M = 1024*1024: 38154 MBytes
device size with M = 1000*1000: 40007 MBytes (40 GB)
Capabilities:
LBA, IORDY(cannot be disabled)
bytes avail on r/w long: 4 Queue depth: 1
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 128 (0x80)
Recommended acoustic management value: 254, current value: 254
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* READ BUFFER cmd
* WRITE BUFFER cmd
* Host Protected Area feature set
* Look-ahead
* Write cache
* Power Management feature set
Security Mode feature set
* SMART feature set
* Mandatory FLUSH CACHE command
* Device Configuration Overlay feature set
* Automatic Acoustic Management feature set
* SET MAX security extension
Power-Up In Standby feature set
* Advanced Power Management feature set
* DOWNLOAD MICROCODE cmd
* SMART self-test
* SMART error logging
Security:
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase
40min for SECURITY ERASE UNIT.
HW reset results:
CBLID- above Vih
Device num = 0 determined by the jumper
Checksum: correct
[root@R1 ~]#</code>

On y retrouve le modèle, le numéro de série et la version du firmware qui peuvent être utiles en cas de contact avec le Service Après-Vente ou de mise à jour pour une série de firmwares défaillante.

La ligne commençant par « DMA » dans la partie « Capabilities » permet d'afficher la vitesse de transfert négociée entre le disque dur et le driver IDE de Linux. L'étoile précède la valeur actuelle. Dans cet exemple, le mode udma5 est sélectionné : ceci est conforme aux machines disponibles sur le marché depuis environ 3 ans.

Pour rappel, voici le tableau de conversion entre le mode DMA et la vitesse maximale associée.

Type de fonctionnement
Vitesse Maximale en MO/sec
UltraDMA 0
16,6
UltraDMA 1
25
UltraDMA 2
33,3
UltraDMA 3
44,4
UltraDMA 4
66,6
UltraDMA 5
100
UltraDMA 6
133,33

Une configuration actuelle ne devrait pas être en dessous de UDMA5. Si ce n'était pas le cas, on peut essayer de renégocier la vitesse de transfert à l'aide de la commande :

<code>hdparm -X udma5 </code>

Celle-ci permet de forcer le mode UltraDMA5. Il faut utiliser cette commande avec précaution car elle pourrait générer des pertes ou de la corruption de données en cas de transfert pendant ce changement de mode.

Vous pouvez aussi impacter les performances de votre disque dur en modifiant sa vitesse de rotation. Cette fonctionnalité connue sous le nom de Automatic Acoustic Management (AAM) est utilisable avec l'option « -M » de hdparm. La valeur 128 représentera la vitesse la plus faible avec un disque silencieux, la valeur 254 la vitesse la plus élevée mais avec comme contre-partie un disque plus bruyant. On pourra noter des différences de quelques Mo/sec selon les configurations.

Il est aussi à noter que l'utilisation de logiciels permettant une meilleure gestion d'énergie (cpufreq, laptop-mode) peut dégrader les performances d'un disque dur de manière notable.

=== Configuration bas niveau du réseau ===

Le réseau local filaire peut parfois être un peu lent. Voici quelques tests pour vérifier si la lenteur provient du logiciel, du noyau ou du matériel. Tout d'abord, explorons la trousse à outils indispensable pour analyser votre carte réseau : ethtool. Digne successeur de mii-tool, il permet de s'informer sur la configuration de votre carte réseau.

Il suffit de lancer « ethtool <votre_interface> » » pour obtenir la configuration matérielle de votre carte. On y retrouve les modes supportés par votre carte (Supported Link Modes ainsi que la vitesse actuelle (Speed), obtenue par auto-négociation dans cet exemple.

On peut également savoir si le câble réseau est connecté à la carte grâce à la ligne « Link Detected ». Le type de « duplex » utilisé permet également de savoir si la négociation avec l' élément actif au bout de votre câble (commutateur, concentrateur ou une autre machine) a correctement fonctionné. Le duplex définit le mode de transmission : le mode half-duplex indique que l'on émet puis on reçoit des données, le mode full-duplex indique que l'on peut émettre et recevoir en même temps des données. Le mode full-duplex est donc plus que recommandé pour vos équipements réseaux.

<code>[root@konilope ~]# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Current message level: 0x000020c1 (8385)
Link detected: yes
[root@konilope ~]# </code>

=== Mesurer les {contre}performances de votre réseau ===

Une fois vérifiée la bonne configuration de votre matériel, nous pouvons passer à la vérification des performances entre deux machines.

L'utilitaire netpipe (http://www.scl.ameslab.gov/netpipe/) permet de réaliser des tests de performance mais aussi d'intégrité entre deux machines. Il permet de tester les performances du réseau au travers la couche IP et non pas depuis un mode plus bas niveau comme pourrait l'être un test utilisant directement le driver Ethernet. Ce test permet donc de valider que la configuration matérielle mais aussi logicielle est correcte.

Sur la première machine, exécutez « NPtcp » : netpipe se positionne en mode « serveur ».
Sur la seconde machine, exécutez « NPtcp -h <machine1> » : netpipe se connecte au serveur netpipe de la machine nommée machine1 pour effectuer le test de performance.

Le test par défaut teste les communication allant de 1 octet jusqu'à 8 Mo. Il peut prendre plusieurs minutes si le réseau est « lent ». Le test va montrer pour chaque taille de paquet la performance obtenue. Il est normal d'obtenir des performances faibles pour des paquets d'une taille inférieure à 8 Ko. Transporter des petits paquets nécessite de réaliser beaucoup d'opérations pour le processeur pour une quantité d'information minime. Les performances seront meilleures à partir d'environ 16 Ko et maximales à partir de 128 Ko. Sur un système utilisant du gigabit ethernet, on constatera une performance de 39Mbps à 256 octets, 287Mbps à 4Ko, 614Mbps à 16Ko, 845Mbps à 128Ko, 895Mbps à 8Mo.

Vous pouvez ainsi vérifier et comparer facilement les performances de votre configuration réseau. Netpipe permet également de tester la vitesse du réseau pour une taille de paquets définie entre la taille indiqué par l'option « -l » et la taille indiquée par l'option « -u ». Ainsi, NPtcp -l 16384 -u 16384 permet de tester la bande passante réseau pour une taille de paquet égale à 16Ko.

L'option « -n <nb-cycle> » permet de définir le nombre de boucles à réaliser pour le test (50 par défaut). Enfin, pour réaliser des tests « full-duplex », on utilisera l'option « -2 ». Ce test permet de s'assurer du bon fonctionnement du mode de communication permettant l'écriture et la lecture simultanées.

Attention, même si ce test donne de bons résultats, cela ne veut pas dire que la configuration est exempte d'erreur de configuration. Par exemple, les performances réseaux peuvent être très bonnes en point à point mais mauvaises lorsque l'on aura une charge réseau avec plusieurs clients. Dans cette situation, il faut vérifier que le contrôle de flux est bien activé sur toutes les machines. L'option « ethtool -a » permet de vérifier que les champs « rx » et « tx » sont placés sur « on ». Si ce n'était pas le cas activez-les avec la commande « ethtool -A eth0 rx on » et « ethtool -A eth0 tx on ».

Les cartes réseaux, des serveurs essentiellement, permettent maintenant de réaliser le « tcp segment offload ». Cette technique permet de décharger une partie du traitement TCP directement dans l'électronique de la carte réseau. Ceci à pour effet de décharger le processeur central d'un traitement fastidieux. L'option « -k » d'ethtool permet de consulter l'état de cette fonctionnalité (off/on). On pourra l'activer sur des serveurs générant un gros trafic réseau par exemple : « ethtool -K eth0 tso on ».

Vous voilà maintenant équipé de nouveau outils pour traquer la perte de performances de votre installation réseau. Ceci couplé aux habituels tcpdump/ethereal, voilà une belle panoplie du zorro du réseau.

=== Quand la latence s'en mêle ===

La latence représente le temps nécessaire à un système pour prendre en compte un événement.

Il arrive que certains périphériques de votre machine nécessitant des débits importants ou une latence assez faible sur le bus PCI soient « poussifs ». On retrouve dans cette catégorie les cartes vidéos accélératrice 3D, les cartes son et les cartes d'acquisition firewire ou DVB (récepteur de télévision numérique terrestre : TNT).

Un périphérique branché sur le bus PCI doit attendre que le bus soit libre pour émettre les données vers la mémoire centrale. Le bus PCI qui est le coeur de communication des périphériques est donc soumis en permanence à un arbitrage qui permet de décider qui doit émettre des données et qui doit attendre. Cet arbitrage est en partie réalisé grâce au « latency_timer ».

Chaque périphérique possède une valeur de « latency_timer » comprise en 0 et 248 cycles d'horloge du bus. Plus la valeur sera importante plus le périphérique disposera de temps pour transmettre des informations. Une latence de 248 cycles permet d'obtenir une priorité forte sur le bus, ce qui permet un débit important. A contrario, une latence de 0 indiquera au périphérique qu'il doit cesser ses transmissions si un autre composant à besoin du bus : ceci se traduira par une perte de bande passante importante.

La configuration réalisée par défaut sur votre machine doit être correcte mais il peut arriver qu'une carte 3D ou DVB soit configurée avec une latence trop faible, ce qui aurait pour conséquence d'offrir une image saccadée et peu fluide. Une carte son offrirait également le même type de symptômes avec un son hâché ou excessivement métallique.

Heureusement, une série d'outils est là pour vous aider à diagnostiquer le problème mais aussi à le résoudre. Le projet pciutils (http://atrey.karlin.mff.cuni.cz/~mj/linux.shtml#pciutils) contient deux outils indispensables: lspci et setpci. Bien entendu, votre distribution favorite devrait posséder ce logiciel, il vous suffira de l'installer avec votre gestionnaire de paquet favori (urpmi, apt, smart).

La commande « lspci » vous permet de lister les périphériques PCI disponibles sur votre ordinateur (cf article paru dans le numéro 68). Cet exemple se basera sur une carte vidéo ayant pour adresse sur le bus PCI « 01:00.0 ».

<code>[root@lagirafe] lspci -v -s 01:00.0
01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX Go5200 32M/64M] (rev a1) (prog-if 00 [VGA])
Subsystem: Samsung Electronics Co Ltd: Unknown device c00f
Flags: bus master, 66Mhz, medium devsel, latency 16, IRQ 11
Memory at c8000000 (32-bit, non-prefetchable) [size=16M]
Memory at d8000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 3.0
[root@lagirafe]</code>

On retiendra dans cette ligne, la valeur 'latency 16'. Ceci risque de poser problème lorsque celle-ci aura besoin d'un fort débit pendant un jeu par exemple. Augmenter la latence va donc se révéler nécessaire pour ce périphérique.

La commande setpci permet de modifier les paramètres PCI d'un périphérique ou d'un bus complet avec tous ses périphériques.

La commande « setpci -v -d 01:* latency_timer=20 » permet de positionner tous les périphériques du bus 01 à une valeur de 32 cycles. Il est à noter que la commande setpci utilise des valeurs en hexadécimal mais lspci affichera les valeurs en décimal.

Pour en revenir à nos moutons, la correction de la latence de cette carte graphique se fera avec la commande « setpci -v -d 01:00.0 latency_timer=f8 ». Ceci positionne donc la carte sur la plus grande valeur de latence possible, ce qui lui garantira la plus grande bande passante possible. Il est possible d'utiliser la valeur « ff » comme paramètre pour « latency_timer » mais celui-ci sera converti à la volée par la commande setpci en « 0xf8 ».

Attention, certains composants de votre machine doivent rester en « latency_timer=0 » pour garantir une bon fonctionnement de votre système : il ne faudra donc pas modifier les latences des contrôleurs mémoire et des ponts PCI connectés généralement sur le bus « 0:* ».

== DSDT : le cauchemar continue ! ==

Cette partie de l'article a pour but d'expliquer le problème que peut représenter la table DSDT pour un certain nombre de machines et surtout les ordinateurs portables.

La norme ACPI 3.0 de Septembre 2004 disponible gratuitement à l'adresse http://www.acpi.info/DOWNLOADS/ACPIspec30.pdf définit la DSDT comme une table remplie par un OEM permettant au système d'exploitation de découvrir les ressources pour la gestion de l'énergie avancée, de la gestion thermique ainsi que la gestion du Plug'nPlay des ressources définies par l'ACPI.

Voici une description certes un peu théorique mais nécessaire pour bien comprendre la problématique et ses conséquences. Le constructeur de l'ordinateur doit donc définir dans le BIOS une table contenant une liste de ressources et leurs configuration et ce pour que le système d'exploitation puisse s'en servir. Noble cause n'est il pas ? Tout au long des 618 pages de ce document sont spécifiés les éléments du langage à utiliser ainsi que sa syntaxe. L' « ACPI Source Language » permettra donc aux développeurs d'écrire des DSDT puis de les compiler dans un format nommé « ACPI Machine Language » en utilisant un compilateur adéquat. Le système d'exploitation utilisera la table compilée (AML) pour accéder aux ressources ACPI.
Sur la plupart des ordinateurs portables, la table DSDT ne respecte pas la norme ACPI dans sa syntaxe. Ceci est très gênant car cela bloque le code de l'interpréteur ACPI du noyau Linux qui essaie de la lire. Le résultat est sans appel, pas d'ACPI, pas de gestion d'énergie avancée, plus de ventilation automatique sur certains modèles d'ordinateurs, plus de touche de gestion de contraste/luminosité sur d'autres etc...

Ceci est très gênant sur un ordinateur portable. Alors que faire ? Dans un premier temps, prévenir le constructeur que son BIOS est incorrect et ne respecte pas la norme ACPI. La réponse se fait toujours attendre pour tous ceux qui « osent » poser la question au support technique : à savoir, les constructeurs ignorent tout simplement les mails de ce type.
La seconde étape puisque vous êtes devant le fait accompli d'une machine non conforme, il va falloir corriger cette table. Il suffit de récupérer la table actuelle via la commande 'cat /proc/acpi/dsdt > dsdt.aml' si vous avez la chance d'avoir un répertoire /proc/acpi malgré une table DSDT endommagée, sinon utilisez la commande 'acpidump -b -t dsdt -o dsdt.aml'. La commande acpidump est fournit dans le projet pmtools (ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20050926.tar.bz2)
Vous avez donc extrait la table DSDT de votre système. Il ne reste plus qu'à essayer de la recompiler. Pour cela, le compilateur IASL de la société Intel (http://developer.intel.com/technology/iapc/acpi/downloads.htm) offre sous Linux et Windows une plate-forme de compilation pour le langage ASL.

Suivez les instructions du site pour télécharger et compiler la version unix d'iasl. Ensuite, décompilez la table avec la commande « iasl -d dsdt.aml ». Le fichier dsdt.dsl vient d'être créé par le décompilateur. Il suffit de le recompiler avec la commande « iasl -tc dsdt.dsl » pour constater les dégâts ! La DSDT que vous avez dans votre BIOS est généralement compilée par le compilateur de Microsoft qui semble autoriser une syntaxe plus qu'approximative.
Si vous avez de la chance, votre DSDT s'est recompilée sans erreurs, vous obtenez donc un fichier dsdt.hex et un fichier dsdt.aml. Il ne reste plus qu'à injecter cette dsdt dans le noyau Linux et le tour sera joué.

Si vous avez moins de chance, votre DSDT est syntaxiquement incorrecte et génère des erreurs. Les expliquer plus en détails nécessiterait un article complet, il ne sera cité que les plus « habituelles » (sic).

<code>dsdt.dsl 2626: Field (ECR, DWordAcc, Lock, Preserve)
Error 1048 - ^ Host Operation Region requires ByteAcc access </code>

Cette erreur présente à ligne 2626 du fichier dsdt.asl indique une erreur de type dans la déclaration du champ ECR. Il suffit dans ce cas de changer le mot « DWordAcc » par « ByteAcc ». Celle-ci reste assez simple à corriger, on se demande donc pourquoi les constructeurs ne prennent pas le temps de vérifier et de corriger leur BIOS.

<code>dsdt.dsl 2672: Method (_GLK, 1, NotSerialized)
Warning 2024 - ^ Reserved method has too many arguments ( _GLK requires 0) </code>

La méthode _GLK n'a besoin que de 0 paramètre tandis que ce code en utilise 2 ! La correction est assez simple : il suffit de remplacer la ligne 2672 par « Method(_GLK) ».

Pour plus de détails sur la correction des erreurs de compilation de votre table dsdt, je vous recommande les tutoriaux disponibles depuis la page http://acpi.sourceforge.net/dsdt/index.php du projet ACPI.

Votre DSDT est compilée avec succès, il ne vous reste plus qu'à l'ajouter pour que votre noyau puisse l'utiliser à la place de celle fourni par le BIOS (modifiable uniquement par le constructeur, via une mise à jour).

Il existe trois possibilités pour inclure une table DSDT : la modification du noyau Linux ( noyau < 2.6.9), l'injection de la DSDT dans la configuration du noyau (noyau >= 2.6.9), l'intégration de la table DSDT dans l'initrd qui nécessite un patch kernel disponible à l'adresse http://gaugusch.at/kernel.shtml.

Pour les noyaux 2.6.9 et supérieur, copiez votre fichier dsdt.hex sous le nom «/usr/src/linux/include/acpi/dsdt_table.h » puis reconfigurez votre noyau.
Insérer « dsdt_table.h » dans l'option « Include you custom DSDT » disponible dans le menu « Power Management/ACPI/ ». Recompilez votre noyau et redémarrez avec votre nouveau noyau.
Pour les noyaux inférieurs à 2.6.9, il est possible de modifier le code source de votre noyau pour intégrer votre DSDT mais il est préférable d'utiliser le patch permettant l'insertion de la table DSDT dans l'initrd. Recompilez votre noyau avec ce patch, puis suivez la procédure décrite ci-dessous.

Certaines distributions Linux comme « Mandriva Linux » possèdent le patch qui permet de n'avoir qu'à reconstruire l'initrd avec la commande « mkinitrd –dsdt=/boot/dsdt.aml /boot/initrd-`uname -r`.img `uname -r` » puis de relancer lilo avant de redémarrer votre machine. Lors du démarrage de celle-ci vous devriez voir le message suivant :

<code>ACPI: Looking for DSDT in initrd... found (at offset 0x4f8d9).
ACPI-0294: *** Info: Table [DSDT] replaced by host OS</code>

Vous voilà maintenant avec une table DSDT correcte et un ACPI fonctionnel. La question qui reste ouverte est pourquoi les constructeurs n'utilisent pas un compilateur digne de ce nom pour permettre à leur clients de pouvoir utiliser d'autres systèmes d'exploitation que Windows de Microsoft.

Pour la petite histoire, si vous cherchez dans votre dsdt vous risquez de tomber ce genre de lignes :

<code>If (LEqual (SCMP (\_OS, "Microsoft Windows NT"), Zero))
If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))
If (LEqual (SCMP (\_OS, "Microsoft WindowsME: Millennium Edition"), Zero))
If (LEqual (SizeOf (\_OS), 0x27)) </code>

Lorsque qu'un système d'exploitation souhaite utiliser les ressources ACPI du BIOS, il utilise son nom de système d'exploitation (acpi_os_name). On retrouve donc dans les bios des parties qui ne seront exécutées que pour certains systèmes d'exploitation de Microsoft. On retrouve même certains tests où c'est la longueur du nom qui compte...... Ceci prouve bien que les constructeurs d'ordinateurs savent corriger des tables DSDT pour les systèmes d'exploitation mais pas forcément pour le notre malheureusement. Depuis le noyau 2.6.9, le noyau Linux utilise « Windows NT » comme « acpi_os_name » pour assurer une meilleure compatibilité matérielle dixit Len Bron d'Intel dans le changelog de cette version.

== Comment trouver le pilote qui va avec votre matériel ? ==

Cette question on se la pose souvent mais uniquement lorsque l'on essaye de brancher un nouveau périphérique sur sa machine. Les distributions récentes permettent de détecter automatiquement votre matériel et de lui associer un pilote avec sa configuration. Ce mécanisme fonctionne plutôt bien mais cela n'évite pas les dysfonctionnements voir l'absence de fonctionnement.

Pour vérifier si votre noyau Linux est capable de supporter un nouveau périphérique PCI par exemple, il suffit d'en récupérer les identifiants PCI (constructeur et produit) puis de les rechercher dans le fichier « /lib/modules/`uname -r`/modules.pcimap » qui est auto-généré lors de la commande depmod.

L'utilitaire « lspcidrake -v » vous permet de trouver les identifiants PCI de votre carte, la commande « lspci » vous permet de trouver le nom de votre périphérique puis faites un « lspci -n » pour en trouver la correspondance numérique. On utilisera la position du périphérique sur le bus pour retrouver la correspondance numérique « 02:05.0 » dans cet exemple.
<code>[root@pumphome] lspci
[....]
02:05.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01)
[root@pumphome] lspci -n
[...]
02:05.0 Class 0200: 14e4:4401 (rev 01)
[root@pumphome]</code>

Ainsi cette carte réseau possède les identifiants 14e4 (constructeur) et 4401 (produit). Il suffit de rechercher cette valeur dans le modules.pcimap, ce qui nous donnera la correspondance en module (pilote).

<code>[root@pumphome] grep "0x000014e4 0x00004401" /lib/modules/2.6.12-12mdk-i686-up-4GB/modules.pcimap
b44 0x000014e4 0x00004401 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0
bcm4400 0x000014e4 0x00004401 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0</code>

On voit ici que cette carte peut utiliser le driver b44 ou le driver bcm4400. On ne trouve pas toujours les identifiants PCI de produit sous leur forme directe, on peut également trouver « 0Xffffffff » qui indique que tous les cartes du constructeur sont gérées par un module.
Il ne vous restera plus qu'à effectuer la configuration associée à ce périphérique pour qu'il fonctionne correctement.

== Conclusion ==

La fin de cet article conclut une toute petite série de deux articles ayant pour but de vulgariser l'architecture de nos machines, de découvrir les outils disponibles pour mieux comprendre leur configuration et au besoin régler les problèmes de configuration matérielle qui ont souvent le don de nous pourrir la vie.

Merci à LaurentJ de #Mandrivafr pour ses tests complémentaires sur les problèmes d'IO-APIC. Un énorme merci à Nicolas Planel pour sa relecture pointue et également Anne pour sa patience de girafe à relire et « quaurigé »mes « photes », ainsi qu'à tous ceux qui m'ont aidé à découvrir ce que je restitue dans cet article.

Cet article a été publié dans Linux Magazine France n°78. Il est publié sur Léa avec l'aimable autorisation de l'éditeur.

2006-06-10T09:28:47Z

Ennael :

= DKMS : Donnez l'indépendance à vos pilotes =

== Contexte ==

Sous Linux, les pilotes (le logiciel qui permet au système d'exploitation de communiquer avec le matériel) peuvent soit être directement inclus dans le noyau soit être disponibles sous la forme de modules à charger dans le noyau. Un tel module est compilé pour un noyau particulier et ne peut être utilisé sur un autre.

En ce qui concerne les pilotes libres, cela ne pose en général aucun problème car ils sont soit livrés avec votre noyau, soit compilés en même temps que le noyau que vous compilez vous-même.

Dans le cas de pilotes non libres (comme ceux de nVidia ou ATI) ou de pilotes distribués séparément et que vous compilez à la main, le pilote doit être recompilé à chaque version de noyau, ce qui peut devenir fastidieux.

De plus, si vous souhaitez utiliser les pilotes distribués par votre distributeur Linux, vous devez attendre que les pilotes soient recompilés pour le nouveau noyau, et ne pouvez espérer qu'ils fonctionnent avec un noyau que vous auriez personnalisé.

== Objectifs de DKMS ==

DKMS (Dynamic Kernel Module Support ou en français Gestion Dynamique des Modules Noyau) est un système très simple conçu par Dell et permettant de compiler dynamiquement et facilement les modules noyau pour tous les noyaux de votre système. Ce système est à la base conçu pour faciliter à Dell la distribution de pilotes Linux et de correctifs.

Cela évite à la fois aux éditeurs et aux utilisateurs de devoir passer par des mises à jour du noyau pour une correction sur un pilote particulier et permet de distribuer un pilote supplémentaire sous la forme d'un seul paquetage quel que soit le noyau de l'utilisateur.

Cet article a pour but de présenter ce système, à la fois aux développeurs et distributeurs de modules noyau qui pourraient l'utiliser pour faciliter la vie à leurs utilisateurs, et aux utilisateurs qui peuvent également l'utiliser tout seuls.

== Comment ça marche ==

Le principe de DKMS est très simple. À condition que le module soit prévu pour être utilisé avec DKMS (fourniture d'un dkms.conf), l'utilisation d'un nouveau module en passant par DKMS consiste à exécuter les 3 étapes suivantes :

* Insertion dans l'arbre DKMS (action add)
* Compilation pour le noyau (action build)
* Installation avec les autres modules du noyau (action install)

Ces étapes sont séparées et ne sont pas forcement toutes réalisées à la suite. La figure 1 montre les différents états d'un module dans le système DKMS, et les transitions possibles entre ces états à l'aide des actions de la commande dkms.
Figure 1 : États d'un module dans DKMS
Figure 1 : États d'un module dans le système DKMS

=== Structure sur le disque ===

Afin de bien séparer la gestion des différentes versions de module et de la version du noyau, le fonctionnement de DKMS se base sur la présence de 3 arborescences :

* Les sources des modules, dans /usr/src
* L'arborescence des modules du noyau/lib/modules : DKMS y remplacera ou ajoutera les modules que l'on va lui faire gérer
* L'arborescence de DKMS /var/lib/dkms, contenant :
o Les répertoire ou seront construit les modules
o Les modules originaux sauvegardés
o Les modules générés par DKMS

Les chemins indiqués sont ceux par défaut et il est possible de les modifier dans /etc/dkms/framework.conf mais nous supposerons dans le reste de l'article que les valeurs par défaut ont été conservées.

== Mise en oeuvre de DKMS par un utilisateur ==

=== La commande dkms ===

La gestion des modules au sein du système DKMS se fait à l'aide de la commande dkms. Cette commande a une syntaxe très simple : dkms <action> [options]
Les actions et les options sont par contre plutôt nombreuses et même si je vous les explique ci-dessous, seules les principales devraient être utiles à la majorité d'entre vous (à savoir: add, build, install, remove en ce qui concerne les actions et -m, -v et --all en ce qui concerne les options).

Voici tout d'abord la liste des options génériques s'appliquant à diverses commandes, celles restreintes à une commande particulière seront expliquées dans la description de celle-ci.

* -m <module> : Le nom du module sur lequel effectuer l'action.
* -v <version du module> : La version du module sur laquelle effectuer l'action.
* -k <version du noyau> : La version du noyau sur laquelle effectuer l'action. Il est possible pour certaines actions de spécifier plusieurs versions du noyau en utilisant plusieurs fois -k, si l'action spécifiée ne le supporte pas une erreur sera émise.
* -a <architecture> : L'architecture pour laquelle effectuer l'action. Si cette option n'est pas précisée, l'architecture choisie est celle indiquée par uname -m. Il est possible de répéter cette option afin d'indiquer plusieurs architectures, mais dans ce cas il doit y avoir exactement autant de -k que de -a. Chaque noyau sera associé à l'architecture de position identique. Par exemple si vous indiquez -k noyau1 -k noyau2 -a i386 -k noyau3 -a i586 -a x86_64, DKMS comprendra que noyau1 est en i386, noyau2 est en i586 et noyau3 est en x86_64.
* --all : Indique d'appliquer l'action pour toutes les versions de noyau et toutes les architectures pour lesquelles le module a été compilé. Cela est particulièrement utile pour l'action remove.
* --rpm_safe_upgrade : Cette option est nécessaire pour les commandes DKMS appelées à l'intérieur d'un RPM. Cela évite des problèmes lors de mise à jour d'un RPM à un autre contenant la même version du module. Cela évite aussi les problèmes d'interblocage dus au système de verrous de rpm.

Nous allons maintenant étudier ce que permet de faire DKMS à travers le parcours des actions que l'on peut faire effectuer à la commande dkms.

* add : Ajoute à l'arbre des sources de DKMS une version d'un module (les options -m et -v sont donc obligatoires, c'est le cas pour la majorité des commandes). Les sources du module doivent être précédemment placées dans /usr/src/<module>-<version du module>/ et contenir un fichier dkms.conf. Si le fichier dkms.conf ne se trouve pas dans /usr/src/<module>-<version du module>/, il faut ajouter l'option -c pour indiquer son chemin.

<code>[root@plop src]# dkms add -m exemple -v 0.9.0 -c /tmp/dkms.conf
Creating symlink /var/lib/dkms/exemple/0.9.0/source ->
/usr/src/exemple-0.9.0

DKMS: add Completed.</code>

* remove : Supprime une version d'un module. Il faut en plus des options -m et -v, soit préciser une version de noyau avec l'option -k, soit demander à supprimer le module de tout les noyaux pour lesquelles cette version avait été compilée, avec l'option --all.

Si le module avait été installé, il est d'abord désinstallé (comme si on avait appelé l'action uninstall) et d'éventuelles versions précédentes sont réinstallées. Après un remove, le module n'est plus du tout connu de DKMS et il faut recommencer à l'étape add.

<code>[root@plop src]# dkms remove -m exemple -v 0.9.0 --all

------------------------------
Deleting module version: 0.9.0
completely from the DKMS tree.
------------------------------
Done.</code>

* build : Compile une version d'un module pour le noyau indiqué avec l'option -k ou pour le noyau utilisé actuellement si aucun n'est précisé. En cas d'erreurs lors de la compilation, il est utile de savoir que celle-ci se déroule dans /var/lib/dkms/<module>/<version du module>/build/ et que tout ce qui est affiché pendant la compilation est enregistré dans un fichier make.log dans ce même répertoire.

La commande build accepte quelques options facultatives :
o --config <fichier .config du noyau> : Cette option permet d'indiquer à la commande build ou trouver le fichier .config si celui-ci n'est pas à l'emplacement standard de la distribution ou n'a pas le nom habituel.
o --no-prepare-kernel : Cette option demande à DKMS de ne pas préparer les sources du noyau avant de compiler un module pour lui. Il est recommandé de ne pas utiliser cette option si l'on souhaite que les modules soient correctement construits.
o --no-clean-kernel : Cette option demande à DKMS de ne pas nettoyer les sources du noyau après avoir compilé un module.
o --kernelsourcedir <chemin vers les sources du noyau> : Cette option permet d'indiquer l'emplacement des sources du noyau lorsqu'elles ne se trouvent pas dans /lib/modules/<version du noyau>/build.

<code>[root@plop src]# dkms build -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB

Preparing kernel 2.6.12-12mdk-i686-up-4GB for module build:
(This is not compiling a kernel, only just preparing kernel symbols)
Storing current .config to be restored when complete
Running Generic preparation routine
make mrproper.........
using /boot/config-2.6.12-12mdk-i686-up-4GB
make oldconfig......
make prepare-all......

Building module:
cleaning build area....
make KERNELRELEASE=2.6.12-12mdk-i686-up-4GB KERNEL_DIR=/lib/modules/2.6.12-12mdk-i686-up-4GB/build drivers....
cleaning build area....
cleaning kernel tree (make mrproper)....

DKMS: build Completed.</code>

* install : Installe une version d'un module dans l'arborescence du noyau indiqué (ou du noyau utilisé actuellement si aucun n'est précisé par l'option -k). Cette version doit précédemment avoir été compilée pour le noyau en question à l'aide de l'action build.

Lors de la première installation d'une version d'un module donné sur un noyau donné, DKMS cherche si ce module existait déjà avec ce noyau et le sauvegarde pour pouvoir le réinstaller lorsque l'on demandera à DKMS de désinstaller la nouvelle version. Pour information, la version originale est sauvée dans /var/lib/dkms/<module>/original_module/<version du noyau>/<architecture>/

<code>[root@plop src]# dkms install -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB
Running module version sanity check.

slamr.ko.gz:
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/

slusb.ko.gz:
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/

depmod.....

DKMS: install Completed.</code>

* uninstall : Désinstalle une version d'un module pour une version du noyau (celle précisée par l'option -k ou la version utilisée actuellement si aucune n'est précisée). Cette commande ne gère pas l'option --all donc il vous faudra désinstaller pour chaque noyau séparément.

<code>[root@plop src]# dkms uninstall -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB

-------- Uninstall Beginning --------
Module: slmodem
Version: 2.9.10
Kernel: 2.6.12-12mdk-i686-up-4GB (i586)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.

slamr.ko.gz:
- Uninstallation
- Deleting from: /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

slusb.ko.gz:
- Uninstallation
- Deleting from: /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

DKMS: uninstall Completed.</code>

* mkrpm : Génére un RPM pour un couple module/version donné. Si vous désirez que le RPM ne contienne que les sources (et donc que les modules soient compilés lors de l'installation), vous devez ajouter l'option --source-only. Sinon, le choix des modules à distribuer se fait à l'aide de -k et -a, comme pour les autres actions.

Si vous maîtrisez la création de RPM et souhaitez personnaliser ce qui est généré, sachez que DKMS regarde d'abord si /usr/src/<module>-<version du module>/<module>-dkms-mkrpm.spec existe, si oui l'utilise comme modèle, et sinon utilise /etc/dkms/template-dkms-mkrpm.spec.

* status : Affiche l'état des différents modules pour chaque version, noyau et architecture.

<code>[root@plop src]# dkms status
ipw2200, 1.0.4: added
slmodem, 2.9.10, 2.6.12-11mdk-i686-up-4GB, i586: installed
slmodem, 2.9.10, 2.6.12-12mdk-i686-up-4GB, i586: built
sysprof, 1.0, 2.6.12-12mdk-i686-up-4GB, i586: installed</code>

* match : Cette commande fort sympathique permet de compiler et installer pour un noyau donné tout les modules qui avaient été installés pour un autre noyau (spécifié par l'option --templatekernel). Par exemple, après exécution de dkms match --templatekernel 2.6.12-11mdk-i686-up-4GB -k 2.6.12-12mdk-i686-up-4GB, toutes les combinaisons module/version qui étaient installées pour le noyau 2.6.12-11mdk-i686-up-4GB le seront pour le noyau 2.6.12-12mdk-i686-up-4GB.
* mktarball : Crée une archive tar.gz pour le module et la version indiquées. Cette archive contiendra les sources et les modules précédemment compilés. Par défaut l'archive est créée pour le noyau utilisé actuellement. Si vous en souhaitez un (ou plusieurs) autre, vous pouvez l'indiquer en utilisant les options -k et -a. Cette commande dispose également de quelques options supplémentaires :
o --archive <fichier.tar.gz> : Permet de préciser le nom à donner à l'archive (ne pas indiquer de chemin, il sera toujours placé dans /var/lib/dkms/<module>/<version du module>/tarball/). Sans cette option, le fichier s'appelle <module>-<version du module>-<versions des noyaux>.dkms.tar.gz
o --binaries-only : Ne pas inclure les sources du module
o --sources-only : Ne pas inclure les modules pré compilés. L'archive s'appellera <module>-<version du module>-source-only.dkms.tar.gz, sauf si vous précisez un autre nom à l'aide de --archive

<code>[root@plop src]# dkms mktarball -m slmodem -v 2.9.10 -k 2.6.12-11mdk-i686-up-4GB -k 2.6.12-12mdk-i686-up-4GB
Marking modules for 2.6.12-11mdk-i686-up-4GB (i586) for archiving...
Marking modules for 2.6.12-12mdk-i686-up-4GB (i586) for archiving...

Marking /usr/src/slmodem-2.9.10 for archiving...

Tarball location: /var/lib/dkms/slmodem/2.9.10/tarball/slmodem-2.9.10-kernel2.6.12-11mdk-i686-up-4GB-i586-kernel2.6.12-12mdk-i686-up-4GB-i586.dkms.tar.gz

DKMS: mktarball Completed.</code>

* ldtarball : Importe une archive tar.gz créé à l'aide de l'action mktarball et spécifié à l'aide de l'option --archive.

Les fichiers sont importés dans l'arborescence de DKMS et pas dans celle du noyau, les modules sont donc au mieux dans l'état built(compilé) et il faut lancer ensuite la commande dkms install pour chacun d'eux.

Par ailleurs, si des fichiers existent déjà lors de l'import, un avertissement sera affiché et ils seront laissés tels quels. Si vous souhaitez que ces éventuels fichiers soient écrasés, il faut ajouter l'option --force.
* mkdriverdisk : Crée une disquette avec les pilotes pour permettre l'installation d'une distribution, c'est particulièrement utile lorsque le CD d'installation ne contient pas les pilotes pour un nouveau contrôleur disque.
o --size <taille de la disquette> : Cette option est utilisée par la commande mkdriverdisk pour décider de la taille de la disquette à créer. La valeur doit être un nombre entier de kilo-octets, divisible par 20, et vaut 1440 si cette option n'est pas précisée.
o --distrib <distribution> : Cette option obligatoire indique la distribution cible. Les valeurs actuellement supportées sont suse, UnitedLinux, redhat, redhat1 and redhat2. Red Hat supportant les disquettes de pilotes multi-architecture depuis la RHEL3, redhat1 force à utiliser l'ancien format, redhat2 force à utiliser le nouveau.
o --release <version> : Cette option est nécessaire si vous construisez une disquette pour SuSE ou UnitedLinux. Elle indique la version de la distribution, par exemple --distrib suse --release 9.1 indiquera que vous construisez la disquette pour une SuSE 9.1
Les options --binaries-only et --sources-only de mktarball peuvent également être utilisées.

=== Utilisation basique ===

Après vous avoir noyé sous les commandes et les options, je pense qu'un exemple d'utilisation classique est nécessaire pour vous persuader de la simplicité d'utilisation. Voici donc comment installer un module exemple, fourni sous la forme de exemple-1.0.tar.gz contenant un unique répertoire exemple-1.0 avec les sources du module et un dkms.conf.

<code>cd /usr/src
tar xzf /tmp/exemple-1.0.tar.gz
dkms add -m exemple -v 1.0
dkms build -m exemple -v 1.0
dkms install -m exemple -v 1.0</code>

Listing 1 : Ajout d'un pilote en utilisant DKMS

Si tout s'est bien passé, le module est compilé et installé, et modprobe exemple fonctionne ! Si cela ne s'est pas bien passé, c'est vraisemblablement lors de l'étape build, et vous pouvez essayer de déterminer le problème en allant lire le fichier /var/lib/dkms/exemple/1.0/build/make.log. Si vous n'avez pas les compétences pour cela, le plus simple est d'envoyer ce fichier à l'auteur du dkms.conf afin qu'il corrige l'erreur.

Un mode de distribution courant, que nous détaillerons plus loin, consiste à distribuer les sources et le dkms.conf sous la forme d'un package RPM et non pas d'un tar.gz. Dans ce cas, installer le package RPM suffit et exécutera automatiquement les différentes commandes.

== Mise en oeuvre de DKMS par un distributeur ==

=== Adaptation des sources ===
DKMS a besoin des sources du module dans le répertoire /usr/src/<nom du module>-<version du module>/ et d'un fichier dkms.conf dans ce même répertoire. Nous allons étudier la syntaxe de ce fichier sur un exemple classique avant de détailler toutes les options disponibles.

=== Exemple de dkms.conf pour l'ipw2200 1.0.4 ===

<code>PACKAGE_VERSION="1.0.4"
PACKAGE_NAME="ipw2200"

MAKE[0]="make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules HOSTAP_SRC=${kernel_source_dir}/3rdparty/hostap/"
CLEAN="make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build clean"

BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
BUILT_MODULE_NAME[1]="ieee80211_crypt_ccmp"
BUILT_MODULE_NAME[2]="ieee80211_crypt"
BUILT_MODULE_NAME[3]="ieee80211_crypt_tkip"
BUILT_MODULE_NAME[4]="ieee80211_crypt_wep"
BUILT_MODULE_NAME[5]="ieee80211"
DEST_MODULE_LOCATION[0]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[1]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[2]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[3]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[4]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[5]="/kernel/drivers/net/wireless/ipw2200/"

MODULES_CONF_ALIAS_TYPE[0]="eth"

REMAKE_INITRD="no"
AUTOINSTALL="yes"</code>

Listing 2: Exemple de dkms.conf pour le pilote ipw2200 version 1.0.4

Comme vous pouvez le voir ce fichier a une syntaxe très simple, une option par ligne sous la forme OPTION="valeur". Voyons maintenant plus précisément à quoi correspondent les options définies dans cet exemple.

PACKAGE_VERSION et PACKAGE_NAME ne méritent je pense aucune explication. Il est toutefois intéressant de noter que lors de la sortie d'une nouvelle version du module, la seule ligne à modifier dans le dkms.conf est en général PACKAGE_VERSION.

MAKE[0] contient la commande à exécuter pour compiler le module, elle peut utiliser de nombreuses variables, listées dans la section suivante. La majorité des modules peuvent se compiler avec la commande suivante : make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules

CLEAN contient une commande permettant de nettoyer le répertoire de construction, elle est appelée avant et après la compilation du module.

Les 12 lignes suivantes indiquent les modules générés (ici il y en a 6) et ou il faut les installer. BUILT_MODULE_NAME[i] contient le nom du module numéro i (en commençant à 0) et DEST_MODULE_LOCATION[i] le chemin où installer le module numéro i. Le chemin est relatif à l'arborescence des modules du noyau concerné, /lib/modules/<version du noyau>.

L'option MODULES_CONF_ALIAS_TYPE[0]="eth" indique qu'il faudra ajouter dans /etc/modprobe.conf (ou modules.conf) un alias vers ce module qui s'appelera eth0 (ou eth1, eth2, ... selon ce qui est déjà pris).

REMAKE_INITRD="no" indique que ce pilote n'a pas besoin d'être dans l'initrd. L'initrd est l'image contenant tout les modules et commandes nécessaires pour accéder au disque dur, cette option a donc rarement besoin d'être à yes en dehors des pilotes de contrôleur disque.

AUTOINSTALL="yes" indique que l'on veut que ce module soit compilé et installé automatiquement lorsque l'on démarre sur un nouveau noyau.

=== Variables disponibles ===

Quelques variables peut être utilisées dans les options et les commandes comme vous pouvez le voir dans la commande MAKE[0] de l'exemple précédent. Ces variables sont définies par la configuration de DKMS ou par les options passées à la commande dkms.

* $kernelver : Cette variable contient la version du noyau pour laquelle le module est en train d'être construit. C'est particulièrement utile dans la définition de la commande MAKE, par exemple MAKE[0]="make INCLUDEDIR=/lib/modules/${kernelver}/build/include"
* $dkms_tree : Cette variable indique ou se trouve l'arbre DKMS sur le système local. Par défaut il s'agit de /var/lib/dkms, mais cette valeur ne doit pas être mise en dur dans les dkms.conf au cas ou l'utilisateur aurait changé cela sur son système (Un tel réglage se fait à l'aide de /etc/dkms/framework.conf ou en ajoutant l'option --dkmstree lors de l'appel, mais nous ne verrons pas ce genre d'utilisations avancées dans cette article).
* $source_tree : Cette variable indique ou DKMS stocke les sources des modules sur le système. Par défaut il s'agit de /usr/src, mais cette valeur ne doit pas être mise en dur dans les dkms.conf au cas ou l'utilisateur aurait changé cela sur son système (à l'aide de /etc/dkms/framework.conf ou en ajoutant l'option --sourcetree lors de l'appel).
* $kernel_source_dir : Cette variable contient le chemin vers les sources du kernel pour lequel on construit le module. Il s'agit en général de /lib/modules/$kernelver/build, à moins qu'un autre chemin ait été spécifié avec l'option --kernel-sourcedir

=== Options que l'on peut définir dans le fichier dkms.conf ===
Tout d'abord, le nom des options est sensible à la casse donc elles doivent être écrites en majuscules. Seules 4 options sont obligatoires :

* PACKAGE_NAME : le nom du package
* PACKAGE_VERSION : la version du package
* BUILT_MODULE_NAME[0] : le nom du module construit. S'il y en a plusieurs, ça sera BUILT_MODULE_NAME[1], BUILT_MODULE_NAME[2], ... Les modules non listés ici ne seront pas installés même s'il sont construit par la commande MAKE[0]
* DEST_MODULE_LOCATION[0] : l'emplacement ou installer le module numéro 0. Ce chemin est relatif au répertoire des modules, et sera par exemple "3rdparty". Il faut renseigner DEST_MODULE_LOCATION[#] pour chaque module listé dans BUILT_MODULE_NAME

De nombreuses autres options bien pratiques mais facultatives dont disponibles :

* MAKE[#] : la commande pour compiler le(s) modules. Voir l'explication de MAKE_MATCH pour la signification du numéro passé en paramètre. Cette option est facultative dans la mesure ou la commande standard de construction d'un module kernel sera utilisée si elle n'est pas définie.
* MAKE_MATCH[#] : cet ensemble d'options permet d'avoir une commande de construction différente en fonction des versions du kernel. Chacune contient une expression régulière qui sera comparée à la version du noyau. Le numéro de la dernière qui correspond indiquera le numéro de commande MAKE à utiliser.
* BUILT_MODULE_LOCATION[#] : le chemin relatif vers le module généré. Cela est nécessaire lorsque le module est généré dans un sous répertoire du répertoire de compilation.
* DEST_MODULE_NAME[#] : le nom a utiliser pour installer le module, s'il y a besoin de le renommer. L'extension (.o ou .ko) ne doit pas être spécifiée. Par défaut le nom original BUILT_MODULE_NAME[#] est conservé.
* MODULES_CONF_ALIAS_TYPE[#] : cette option indique pour chaque module quel alias créer dans /etc/modprobe.conf. DKMS calculera automatiquement le numéro de l'alias en fonction de ceux qui existent déjà. Par exemple si MODULES_CONF_ALIAS_TYPE[0] contient eth et que vous avez déjà eth0 et eth1 définis dans /etc/modprobe.conf, DKMS ajoutera un alias eth2 vers le module. Cette fonctionnalité est à utiliser avec précaution dans la mesure ou elle gère mal les cas complexes, comme par exemple les systèmes avec plusieurs cartes réseau utilisant le même module.
* MODULES_CONF_OBSOLETES[#] : cette option indique à DKMS quels modules vers lesquels pointent des alias dans /etc/modprobe.conf doivent être remplacés par ce nouveau module. Si il y en a plusieurs, les séparer par une virgule. Je pense que ce sera plus clair sur un exemple. Considérons le fichier modprobe.conf suivant :

alias eth0 bcm4400
alias eth1 e1000

Si l'on se contente des options suivantes, DKMS n'a aucun moyen de deviner que b44 et bcm4400 gèrent la même carte et un nouvel alias sera généré.

BUILT_MODULE_NAME[0]="b44"
MODULES_CONF_ALIAS_TYPE[0]="eth"

Le nouveau modprobe.conf contiendra donc :

alias eth0 bcm4400
alias eth1 e1000
alias eth2 b44

Si par contre on ajoute MODULES_CONF_OBSOLETES[0]="bcm4400", le nouveau modprobe.conf sera correct :

alias eth0 b44
alias eth1 e1000

* MODULES_CONF_OBSOLETE_ONLY[#] : Si cette option vaut yes, DKMS ne modifiera modprobe.conf que s'il trouve un alias vers un module obsolète à remplacer. Il n'y aura donc jamais de nouveaux alias de créés.
* STRIP[#] : Par défaut, les symboles de deboguage sont supprimés des modules à l'aide de strip -g. Positionner cette option à "no" pour l'un des modules permet de les conserver dans ce module.
* REMAKE_INITRD : Cette option indique, lorsque la première lettre est y ou Y, qu'il faut régénérer l'initrd après l'installation d'une nouvelle version du module. C'est surtout nécessaire pour les pilotes de contrôleur disque.
* MODULES_CONF[#] : Cette option permet d'indiquer des lignes à ajouter au fichier modprobe.conf. Lorsqu'une première version du module est installée sur l'un des noyaux, les lignes de MODULES_CONF sont ajoutées au fichier modprobe.conf (avant que l'initrd soit régénéré si REMAKE_INITRD est activé). Elles sont supprimées lorsque la dernière version est désinstallée. On peut imaginer par exemple dans le cas de l'ipw2200 MODULES_CONF[0]="options ipw2200 led=1".
* PATCH[#] : Cette option permet d'indiquer des patchs à appliquer sur les sources du pilote avant de le compiler. Tout les patchs doivent se trouver dans /usr/src/<module>-<version du module>/patches/ et sont appliqués avec patch -p1. Vous pouvez spécifier pour quels noyaux chaque patch doit être appliqué en utilisant l'option PATCH_MATCH ci-dessous.
* PATCH_MATCH[#] : Cette option sert à indiquer pour quels noyaux les patchs contenus dans le tableau PATCH doivent être appliqués. PATCH_MATCH[i] contient une expression régulière qui est comparés à la version du noyau cible pour décider si PATCH[i] doit être appliqué.
* AUTOINSTALL : Si cette option vaut "yes", le service dkms (/etc/rc.d/init.d/dkms) essayera automatiquement de construire et installer ce module sur le noyau sur lequel vous démarrez. Ce service ne fera toutefois rien si plusieurs versions du module sont présentes dans l'arbre DKMS, ce sera à vous de décider laquelle vous souhaitez.
* BUILD_EXCLUSIVE_KERNEL : Cette option permet d'indiquer une expression régulière décrivant les versions de noyau pour lesquelles DKMS est autorisé à construire votre module. Si vous essayez de construire le module pour un noyau ne correspondant pas à cette expression régulière, DKMS provoquera une erreur. Par exemple, si vous indiquez "^2.6.*", votre module ne pourra être construit que pour les noyaux 2.6 et une erreur se produira sur les 2.4.
* BUILD_EXCLUSIVE_ARCH : Cette option fonctionne comme BUILD_EXCLUSIVE_KERNEL mais limite l'architecture du noyau au lieu de sa version. Par exemple, si cette option vaut "i.86" votre module pourra être construit pour i386 ou i586 mais pas ppc, x86_64, ni s390.
* POST_ADD : Cette option indique le nom d'un script à exécuter après le traitement de la commande add. Le chemin doit être indiqué relativement aux sources du module.
* POST_BUILD : Cette option indique le nom d'un script à exécuter après le traitement de la commande build. Le chemin doit être indiqué relativement aux sources du module.
* POST_INSTALL : Cette option indique le nom d'un script à exécuter après le traitement de la commande install. Le chemin doit être indiqué relativement aux sources du module.
* POST_REMOVE : Cette option indique le nom d'un script à exécuter après le traitement de la commande remove. Le chemin doit être indiqué relativement aux sources du module.
* PRE_BUILD : Cette option indique le nom d'un script à exécuter avant le traitement de la commande build. Le chemin doit être indiqué relativement aux sources du module.

=== Intégration avec rpm ===

Les possibilités d'intégration de DKMS avec RPM sont doubles :

* Création manuelle de RPM contenant les sources et le dkms.conf ;
* Création automatique de rpm contant un module compilé à l'aide de dkms, et dont la gestion est faite par DKMS.

En ce qui concerne le premier cas, la création du RPM est assez simple si vous savez construire des RPM. Vous indiquez comme source le tar.gz des sources du module et dans la section %install vous copiez les sources vers /usr/src/<nom du module>-<version du module> et vous y écrivez le dkms.conf (Il est également possible de mettre le dkms.conf dans un fichier annexe et de l'inclure comme source, mais l'avoir inclus permet d'utiliser les macros RPM %name, %version, ... afin de créer rapidement un .spec pour un nouveau module). Ensuite vous indiquez en %post et %preun les commandes DKMS à invoquer (add, build et install en %post et remove en %preun).
Le modèle de fichier spec suivant pourra vous servir de base dans la majorité des cas.

%define module_name rt2500

Name: dkms-%{module_name}
Version: 1.4.6.2
Release: 1mdk
Summary: DKMS-ready kernel-source for the RT2500 driver
License: GPL
URL: http://www.ralinktech.com/supp-1.htm
Source: http://www.ralinktech.com/drivers/Linux/RT2500-Linux-STA-%{version}.tar.bz2
Group: System/Kernel and hardware
Requires(pre): dkms
Requires(post): dkms
Buildroot: %{_tmppath}/%{name}-%{version}-root
Buildarch: noarch

%description
Driver for the Ralink RT2500 802.11g chipset

%prep
%setup -q -n RT2500-Linux-STA-%{version}
chmod 0755 Module/2.*.x

%build

%clean
rm -fr $RPM_BUILD_ROOT

%install
mkdir -p %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cp -a Module/* %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cp -af Module/2.6.x/Makefile %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cat > %{buildroot}/usr/src/%{module_name}-%{version}-%{release}/dkms.conf <<EOF

PACKAGE_VERSION="%{version}-%{release}"

# Items below here should not have to change with each driver version
PACKAGE_NAME="%{module_name}"
MAKE[0]="make -C \${kernel_source_dir} SUBDIRS=\${dkms_tree}/\${PACKAGE_NAME}/\${PACKAGE_VERSION}/build modules"
CLEAN="make -C \${kernel_source_dir} SUBDIRS=\${dkms_tree}/\${PACKAGE_NAME}/\${PACKAGE_VERSION}/build clean"

BUILT_MODULE_NAME[0]="\$PACKAGE_NAME"

DEST_MODULE_LOCATION[0]="/kernel/drivers/net/wireless/"

MODULES_CONF_ALIAS_TYPE[0]="ra"

REMAKE_INITRD="no"
AUTOINSTALL=yes

EOF

%post
dkms add -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade
dkms build -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade
dkms install -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade

%preun
dkms remove -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade --all ||:

%files
%defattr(-,root,root)
/usr/src/%{module_name}-%{version}-%{release}

Listing 7: Exemple de fichier .spec pour un package DKMS

Il y a peu de remarques à faire sur ce fichier si ce n'est l'importance de ne pas oublier --rpm_safe_upgrade et surtout ||: dans le %preun qui permet que le rpm puisse être désinstallé même si le remove échoue (par exemple parce que le build avait échoué donc le module n'est pas installé).

Pour ce qui est du deuxième cas (création de RPM binaires), c'est encore plus simple, il suffit de compiler le module puis d'utiliser dkms mkrpm en précisant le module, sa version et le ou les noyaux qui vous intéressent. Contrairement aux RPM créés à la main comme précédemment, cette méthode nécessite par contre d'être root sur la machine générant le package (ou d'avoir par exemple un sudo sur la commande dkms).

== Avantages et inconvénients ==

Pour finir, voici une petite liste des avantages et des inconvénients que je vois à utiliser DKMS. Cette liste vous aidera probablement à décider si vous souhaiter essayer de gérer vos pilotes additionnels avec DKMS.

=== Avantages ===

* Il n'y a plus besoin de se préoccuper de ses pilotes additionnels lorsque l'on met à jour son noyau ;
* Il est beaucoup plus facile de distribuer des pilotes (y compris les modules propriétaires avec une couche libre de jonction). Avec un seul paquetage à installer l'utilisateur n'a rien à faire pour que ça marche sur son noyau ;
* Il est beaucoup plus facile (et léger) de distribuer des correctifs sur les noyaux. Il n'y a plus besoin de distribuer un nouveau noyau lorsque le problème n'affecte qu'un module, DKMS gérera très bien le remplacement du module original, même si celui-ci n'était initialement pas installé avec DKMS ;
* Il est possible d'avoir plusieurs versions du module présentes sur sa machine simultanément et de basculer entres elles à l'aide de la commande dkms, ce qui est très pratique pour des tests ;
* Il est possible de distribuer le module avec la partie userspace associée plutôt qu'avec le noyau, ce qui permet d'éviter les problèmes de désynchronisation.

=== Inconvénients ===

* Le fonctionnement classique de DKMS implique la présence d'un compilateur sur la machine, ce qui est en particulier problématique pour la sécurité des serveurs. Toutefois, DKMS reste utile sans compilateur sur le serveur pour générer depuis une autre machine un RPM contenant la nouvelle version compilée du module et pouvoir ainsi facilement mettre à jour toutes ses machines.
* De même DKMS a besoin des sources du noyau, ce qui occupe beaucoup d'espace disque.
* La recompilation dynamique par un service au démarrage n'est pas adaptée pour les modules nécessaires plus tôt (pilotes de contrôleur disque par exemple), il faut donc dans ce cas s'assurer de faire compiler à DKMS le pilote pour le nouveau noyau avant de redémarrer. Cet inconvénient n'en est toutefois pas réellement un dans la mesure où le problème est le même lorsque le module en question est compilé à la main sans DKMS.
* DKMS est basé sur RPM et ne fonctionnera donc que sur des distributions utilisant RPM (RedHat, Mandriva, SuSE, ...). L'utilisation de rpm est pourtant très localisée (par exemple détection de l'architecture du noyau cible) et il devrait être assez facile de s'en passer.
* DKMS ne prend pour le moment pas en compte le fichier .config du noyau mais celui par défaut fourni par la distribution pour la famille de noyaux (smp, 64G, ...).

=== Références ===

* [http://linux.dell.com/dkms/dkms.html http://linux.dell.com/dkms/dkms.html]
* [http://www.linuxjournal.com/article/6896 http://www.linuxjournal.com/article/6896]
* [http://linux.dell.com/dkms/dkms-ols2004.pdf http://linux.dell.com/dkms/dkms-ols2004.pdf]
* [http://www.dell.com/downloads/global/power/1q04-ler.pdf http://www.dell.com/downloads/global/power/1q04-ler.pdf]
* [http://linux.dell.com/dkms/dkms-LWE-Boston2005.pdf http://linux.dell.com/dkms/dkms-LWE-Boston2005.pdf]

Pascal Terjan <pterjan@mandriva.com>
Cet article a été initialement publié dans le GNU/Linux Magazine 80 de Février 2006
Contexte</code>

DKMS

2006-06-10T09:26:46Z

Ennael : /* Exemple de dkms.conf pour l'ipw2200 1.0.4 */

= DKMS : Donnez l'indépendance à vos pilotes =

== Contexte ==

Sous Linux, les pilotes (le logiciel qui permet au système d'exploitation de communiquer avec le matériel) peuvent soit être directement inclus dans le noyau soit être disponibles sous la forme de modules à charger dans le noyau. Un tel module est compilé pour un noyau particulier et ne peut être utilisé sur un autre.

En ce qui concerne les pilotes libres, cela ne pose en général aucun problème car ils sont soit livrés avec votre noyau, soit compilés en même temps que le noyau que vous compilez vous-même.

Dans le cas de pilotes non libres (comme ceux de nVidia ou ATI) ou de pilotes distribués séparément et que vous compilez à la main, le pilote doit être recompilé à chaque version de noyau, ce qui peut devenir fastidieux.

De plus, si vous souhaitez utiliser les pilotes distribués par votre distributeur Linux, vous devez attendre que les pilotes soient recompilés pour le nouveau noyau, et ne pouvez espérer qu'ils fonctionnent avec un noyau que vous auriez personnalisé.

== Objectifs de DKMS ==

DKMS (Dynamic Kernel Module Support ou en français Gestion Dynamique des Modules Noyau) est un système très simple conçu par Dell et permettant de compiler dynamiquement et facilement les modules noyau pour tous les noyaux de votre système. Ce système est à la base conçu pour faciliter à Dell la distribution de pilotes Linux et de correctifs.

Cela évite à la fois aux éditeurs et aux utilisateurs de devoir passer par des mises à jour du noyau pour une correction sur un pilote particulier et permet de distribuer un pilote supplémentaire sous la forme d'un seul paquetage quel que soit le noyau de l'utilisateur.

Cet article a pour but de présenter ce système, à la fois aux développeurs et distributeurs de modules noyau qui pourraient l'utiliser pour faciliter la vie à leurs utilisateurs, et aux utilisateurs qui peuvent également l'utiliser tout seuls.

== Comment ça marche ==

Le principe de DKMS est très simple. À condition que le module soit prévu pour être utilisé avec DKMS (fourniture d'un dkms.conf), l'utilisation d'un nouveau module en passant par DKMS consiste à exécuter les 3 étapes suivantes :

* Insertion dans l'arbre DKMS (action add)
* Compilation pour le noyau (action build)
* Installation avec les autres modules du noyau (action install)

Ces étapes sont séparées et ne sont pas forcement toutes réalisées à la suite. La figure 1 montre les différents états d'un module dans le système DKMS, et les transitions possibles entre ces états à l'aide des actions de la commande dkms.
Figure 1 : États d'un module dans DKMS
Figure 1 : États d'un module dans le système DKMS

=== Structure sur le disque ===

Afin de bien séparer la gestion des différentes versions de module et de la version du noyau, le fonctionnement de DKMS se base sur la présence de 3 arborescences :

* Les sources des modules, dans /usr/src
* L'arborescence des modules du noyau/lib/modules : DKMS y remplacera ou ajoutera les modules que l'on va lui faire gérer
* L'arborescence de DKMS /var/lib/dkms, contenant :
o Les répertoire ou seront construit les modules
o Les modules originaux sauvegardés
o Les modules générés par DKMS

Les chemins indiqués sont ceux par défaut et il est possible de les modifier dans /etc/dkms/framework.conf mais nous supposerons dans le reste de l'article que les valeurs par défaut ont été conservées.

== Mise en oeuvre de DKMS par un utilisateur ==

=== La commande dkms ===

La gestion des modules au sein du système DKMS se fait à l'aide de la commande dkms. Cette commande a une syntaxe très simple : dkms <action> [options]
Les actions et les options sont par contre plutôt nombreuses et même si je vous les explique ci-dessous, seules les principales devraient être utiles à la majorité d'entre vous (à savoir: add, build, install, remove en ce qui concerne les actions et -m, -v et --all en ce qui concerne les options).

Voici tout d'abord la liste des options génériques s'appliquant à diverses commandes, celles restreintes à une commande particulière seront expliquées dans la description de celle-ci.

* -m <module> : Le nom du module sur lequel effectuer l'action.
* -v <version du module> : La version du module sur laquelle effectuer l'action.
* -k <version du noyau> : La version du noyau sur laquelle effectuer l'action. Il est possible pour certaines actions de spécifier plusieurs versions du noyau en utilisant plusieurs fois -k, si l'action spécifiée ne le supporte pas une erreur sera émise.
* -a <architecture> : L'architecture pour laquelle effectuer l'action. Si cette option n'est pas précisée, l'architecture choisie est celle indiquée par uname -m. Il est possible de répéter cette option afin d'indiquer plusieurs architectures, mais dans ce cas il doit y avoir exactement autant de -k que de -a. Chaque noyau sera associé à l'architecture de position identique. Par exemple si vous indiquez -k noyau1 -k noyau2 -a i386 -k noyau3 -a i586 -a x86_64, DKMS comprendra que noyau1 est en i386, noyau2 est en i586 et noyau3 est en x86_64.
* --all : Indique d'appliquer l'action pour toutes les versions de noyau et toutes les architectures pour lesquelles le module a été compilé. Cela est particulièrement utile pour l'action remove.
* --rpm_safe_upgrade : Cette option est nécessaire pour les commandes DKMS appelées à l'intérieur d'un RPM. Cela évite des problèmes lors de mise à jour d'un RPM à un autre contenant la même version du module. Cela évite aussi les problèmes d'interblocage dus au système de verrous de rpm.

Nous allons maintenant étudier ce que permet de faire DKMS à travers le parcours des actions que l'on peut faire effectuer à la commande dkms.

* add : Ajoute à l'arbre des sources de DKMS une version d'un module (les options -m et -v sont donc obligatoires, c'est le cas pour la majorité des commandes). Les sources du module doivent être précédemment placées dans /usr/src/<module>-<version du module>/ et contenir un fichier dkms.conf. Si le fichier dkms.conf ne se trouve pas dans /usr/src/<module>-<version du module>/, il faut ajouter l'option -c pour indiquer son chemin.

<code>[root@plop src]# dkms add -m exemple -v 0.9.0 -c /tmp/dkms.conf
Creating symlink /var/lib/dkms/exemple/0.9.0/source ->
/usr/src/exemple-0.9.0

DKMS: add Completed.</code>

* remove : Supprime une version d'un module. Il faut en plus des options -m et -v, soit préciser une version de noyau avec l'option -k, soit demander à supprimer le module de tout les noyaux pour lesquelles cette version avait été compilée, avec l'option --all.

Si le module avait été installé, il est d'abord désinstallé (comme si on avait appelé l'action uninstall) et d'éventuelles versions précédentes sont réinstallées. Après un remove, le module n'est plus du tout connu de DKMS et il faut recommencer à l'étape add.

<code>[root@plop src]# dkms remove -m exemple -v 0.9.0 --all

------------------------------
Deleting module version: 0.9.0
completely from the DKMS tree.
------------------------------
Done.</code>

* build : Compile une version d'un module pour le noyau indiqué avec l'option -k ou pour le noyau utilisé actuellement si aucun n'est précisé. En cas d'erreurs lors de la compilation, il est utile de savoir que celle-ci se déroule dans /var/lib/dkms/<module>/<version du module>/build/ et que tout ce qui est affiché pendant la compilation est enregistré dans un fichier make.log dans ce même répertoire.

La commande build accepte quelques options facultatives :
o --config <fichier .config du noyau> : Cette option permet d'indiquer à la commande build ou trouver le fichier .config si celui-ci n'est pas à l'emplacement standard de la distribution ou n'a pas le nom habituel.
o --no-prepare-kernel : Cette option demande à DKMS de ne pas préparer les sources du noyau avant de compiler un module pour lui. Il est recommandé de ne pas utiliser cette option si l'on souhaite que les modules soient correctement construits.
o --no-clean-kernel : Cette option demande à DKMS de ne pas nettoyer les sources du noyau après avoir compilé un module.
o --kernelsourcedir <chemin vers les sources du noyau> : Cette option permet d'indiquer l'emplacement des sources du noyau lorsqu'elles ne se trouvent pas dans /lib/modules/<version du noyau>/build.

<code>[root@plop src]# dkms build -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB

Preparing kernel 2.6.12-12mdk-i686-up-4GB for module build:
(This is not compiling a kernel, only just preparing kernel symbols)
Storing current .config to be restored when complete
Running Generic preparation routine
make mrproper.........
using /boot/config-2.6.12-12mdk-i686-up-4GB
make oldconfig......
make prepare-all......

Building module:
cleaning build area....
make KERNELRELEASE=2.6.12-12mdk-i686-up-4GB KERNEL_DIR=/lib/modules/2.6.12-12mdk-i686-up-4GB/build drivers....
cleaning build area....
cleaning kernel tree (make mrproper)....

DKMS: build Completed.</code>

* install : Installe une version d'un module dans l'arborescence du noyau indiqué (ou du noyau utilisé actuellement si aucun n'est précisé par l'option -k). Cette version doit précédemment avoir été compilée pour le noyau en question à l'aide de l'action build.

Lors de la première installation d'une version d'un module donné sur un noyau donné, DKMS cherche si ce module existait déjà avec ce noyau et le sauvegarde pour pouvoir le réinstaller lorsque l'on demandera à DKMS de désinstaller la nouvelle version. Pour information, la version originale est sauvée dans /var/lib/dkms/<module>/original_module/<version du noyau>/<architecture>/

<code>[root@plop src]# dkms install -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB
Running module version sanity check.

slamr.ko.gz:
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/

slusb.ko.gz:
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/

depmod.....

DKMS: install Completed.</code>

* uninstall : Désinstalle une version d'un module pour une version du noyau (celle précisée par l'option -k ou la version utilisée actuellement si aucune n'est précisée). Cette commande ne gère pas l'option --all donc il vous faudra désinstaller pour chaque noyau séparément.

<code>[root@plop src]# dkms uninstall -m slmodem -v 2.9.10 -k 2.6.12-12mdk-i686-up-4GB

-------- Uninstall Beginning --------
Module: slmodem
Version: 2.9.10
Kernel: 2.6.12-12mdk-i686-up-4GB (i586)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.

slamr.ko.gz:
- Uninstallation
- Deleting from: /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

slusb.ko.gz:
- Uninstallation
- Deleting from: /lib/modules/2.6.12-12mdk-i686-up-4GB/kernel/drivers/char/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

DKMS: uninstall Completed.</code>

* mkrpm : Génére un RPM pour un couple module/version donné. Si vous désirez que le RPM ne contienne que les sources (et donc que les modules soient compilés lors de l'installation), vous devez ajouter l'option --source-only. Sinon, le choix des modules à distribuer se fait à l'aide de -k et -a, comme pour les autres actions.

Si vous maîtrisez la création de RPM et souhaitez personnaliser ce qui est généré, sachez que DKMS regarde d'abord si /usr/src/<module>-<version du module>/<module>-dkms-mkrpm.spec existe, si oui l'utilise comme modèle, et sinon utilise /etc/dkms/template-dkms-mkrpm.spec.

* status : Affiche l'état des différents modules pour chaque version, noyau et architecture.

<code>[root@plop src]# dkms status
ipw2200, 1.0.4: added
slmodem, 2.9.10, 2.6.12-11mdk-i686-up-4GB, i586: installed
slmodem, 2.9.10, 2.6.12-12mdk-i686-up-4GB, i586: built
sysprof, 1.0, 2.6.12-12mdk-i686-up-4GB, i586: installed</code>

* match : Cette commande fort sympathique permet de compiler et installer pour un noyau donné tout les modules qui avaient été installés pour un autre noyau (spécifié par l'option --templatekernel). Par exemple, après exécution de dkms match --templatekernel 2.6.12-11mdk-i686-up-4GB -k 2.6.12-12mdk-i686-up-4GB, toutes les combinaisons module/version qui étaient installées pour le noyau 2.6.12-11mdk-i686-up-4GB le seront pour le noyau 2.6.12-12mdk-i686-up-4GB.
* mktarball : Crée une archive tar.gz pour le module et la version indiquées. Cette archive contiendra les sources et les modules précédemment compilés. Par défaut l'archive est créée pour le noyau utilisé actuellement. Si vous en souhaitez un (ou plusieurs) autre, vous pouvez l'indiquer en utilisant les options -k et -a. Cette commande dispose également de quelques options supplémentaires :
o --archive <fichier.tar.gz> : Permet de préciser le nom à donner à l'archive (ne pas indiquer de chemin, il sera toujours placé dans /var/lib/dkms/<module>/<version du module>/tarball/). Sans cette option, le fichier s'appelle <module>-<version du module>-<versions des noyaux>.dkms.tar.gz
o --binaries-only : Ne pas inclure les sources du module
o --sources-only : Ne pas inclure les modules pré compilés. L'archive s'appellera <module>-<version du module>-source-only.dkms.tar.gz, sauf si vous précisez un autre nom à l'aide de --archive

<code>[root@plop src]# dkms mktarball -m slmodem -v 2.9.10 -k 2.6.12-11mdk-i686-up-4GB -k 2.6.12-12mdk-i686-up-4GB
Marking modules for 2.6.12-11mdk-i686-up-4GB (i586) for archiving...
Marking modules for 2.6.12-12mdk-i686-up-4GB (i586) for archiving...

Marking /usr/src/slmodem-2.9.10 for archiving...

Tarball location: /var/lib/dkms/slmodem/2.9.10/tarball/slmodem-2.9.10-kernel2.6.12-11mdk-i686-up-4GB-i586-kernel2.6.12-12mdk-i686-up-4GB-i586.dkms.tar.gz

DKMS: mktarball Completed.</code>

* ldtarball : Importe une archive tar.gz créé à l'aide de l'action mktarball et spécifié à l'aide de l'option --archive.

Les fichiers sont importés dans l'arborescence de DKMS et pas dans celle du noyau, les modules sont donc au mieux dans l'état built(compilé) et il faut lancer ensuite la commande dkms install pour chacun d'eux.

Par ailleurs, si des fichiers existent déjà lors de l'import, un avertissement sera affiché et ils seront laissés tels quels. Si vous souhaitez que ces éventuels fichiers soient écrasés, il faut ajouter l'option --force.
* mkdriverdisk : Crée une disquette avec les pilotes pour permettre l'installation d'une distribution, c'est particulièrement utile lorsque le CD d'installation ne contient pas les pilotes pour un nouveau contrôleur disque.
o --size <taille de la disquette> : Cette option est utilisée par la commande mkdriverdisk pour décider de la taille de la disquette à créer. La valeur doit être un nombre entier de kilo-octets, divisible par 20, et vaut 1440 si cette option n'est pas précisée.
o --distrib <distribution> : Cette option obligatoire indique la distribution cible. Les valeurs actuellement supportées sont suse, UnitedLinux, redhat, redhat1 and redhat2. Red Hat supportant les disquettes de pilotes multi-architecture depuis la RHEL3, redhat1 force à utiliser l'ancien format, redhat2 force à utiliser le nouveau.
o --release <version> : Cette option est nécessaire si vous construisez une disquette pour SuSE ou UnitedLinux. Elle indique la version de la distribution, par exemple --distrib suse --release 9.1 indiquera que vous construisez la disquette pour une SuSE 9.1
Les options --binaries-only et --sources-only de mktarball peuvent également être utilisées.

=== Utilisation basique ===

Après vous avoir noyé sous les commandes et les options, je pense qu'un exemple d'utilisation classique est nécessaire pour vous persuader de la simplicité d'utilisation. Voici donc comment installer un module exemple, fourni sous la forme de exemple-1.0.tar.gz contenant un unique répertoire exemple-1.0 avec les sources du module et un dkms.conf.

<code>cd /usr/src
tar xzf /tmp/exemple-1.0.tar.gz
dkms add -m exemple -v 1.0
dkms build -m exemple -v 1.0
dkms install -m exemple -v 1.0</code>

Listing 1 : Ajout d'un pilote en utilisant DKMS

Si tout s'est bien passé, le module est compilé et installé, et modprobe exemple fonctionne ! Si cela ne s'est pas bien passé, c'est vraisemblablement lors de l'étape build, et vous pouvez essayer de déterminer le problème en allant lire le fichier /var/lib/dkms/exemple/1.0/build/make.log. Si vous n'avez pas les compétences pour cela, le plus simple est d'envoyer ce fichier à l'auteur du dkms.conf afin qu'il corrige l'erreur.

Un mode de distribution courant, que nous détaillerons plus loin, consiste à distribuer les sources et le dkms.conf sous la forme d'un package RPM et non pas d'un tar.gz. Dans ce cas, installer le package RPM suffit et exécutera automatiquement les différentes commandes.

== Mise en oeuvre de DKMS par un distributeur ==

=== Adaptation des sources ===
DKMS a besoin des sources du module dans le répertoire /usr/src/<nom du module>-<version du module>/ et d'un fichier dkms.conf dans ce même répertoire. Nous allons étudier la syntaxe de ce fichier sur un exemple classique avant de détailler toutes les options disponibles.

=== Exemple de dkms.conf pour l'ipw2200 1.0.4 ===

<code>PACKAGE_VERSION="1.0.4"
PACKAGE_NAME="ipw2200"

MAKE[0]="make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules HOSTAP_SRC=${kernel_source_dir}/3rdparty/hostap/"
CLEAN="make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build clean"

BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
BUILT_MODULE_NAME[1]="ieee80211_crypt_ccmp"
BUILT_MODULE_NAME[2]="ieee80211_crypt"
BUILT_MODULE_NAME[3]="ieee80211_crypt_tkip"
BUILT_MODULE_NAME[4]="ieee80211_crypt_wep"
BUILT_MODULE_NAME[5]="ieee80211"
DEST_MODULE_LOCATION[0]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[1]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[2]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[3]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[4]="/kernel/drivers/net/wireless/ipw2200/"
DEST_MODULE_LOCATION[5]="/kernel/drivers/net/wireless/ipw2200/"

MODULES_CONF_ALIAS_TYPE[0]="eth"

REMAKE_INITRD="no"
AUTOINSTALL="yes"</codeQ

Listing 2: Exemple de dkms.conf pour le pilote ipw2200 version 1.0.4

Comme vous pouvez le voir ce fichier a une syntaxe très simple, une option par ligne sous la forme OPTION="valeur". Voyons maintenant plus précisément à quoi correspondent les options définies dans cet exemple.

PACKAGE_VERSION et PACKAGE_NAME ne méritent je pense aucune explication. Il est toutefois intéressant de noter que lors de la sortie d'une nouvelle version du module, la seule ligne à modifier dans le dkms.conf est en général PACKAGE_VERSION.

MAKE[0] contient la commande à exécuter pour compiler le module, elle peut utiliser de nombreuses variables, listées dans la section suivante. La majorité des modules peuvent se compiler avec la commande suivante : make -C ${kernel_source_dir} SUBDIRS=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules

CLEAN contient une commande permettant de nettoyer le répertoire de construction, elle est appelée avant et après la compilation du module.

Les 12 lignes suivantes indiquent les modules générés (ici il y en a 6) et ou il faut les installer. BUILT_MODULE_NAME[i] contient le nom du module numéro i (en commençant à 0) et DEST_MODULE_LOCATION[i] le chemin où installer le module numéro i. Le chemin est relatif à l'arborescence des modules du noyau concerné, /lib/modules/<version du noyau>.

L'option MODULES_CONF_ALIAS_TYPE[0]="eth" indique qu'il faudra ajouter dans /etc/modprobe.conf (ou modules.conf) un alias vers ce module qui s'appelera eth0 (ou eth1, eth2, ... selon ce qui est déjà pris).

REMAKE_INITRD="no" indique que ce pilote n'a pas besoin d'être dans l'initrd. L'initrd est l'image contenant tout les modules et commandes nécessaires pour accéder au disque dur, cette option a donc rarement besoin d'être à yes en dehors des pilotes de contrôleur disque.

AUTOINSTALL="yes" indique que l'on veut que ce module soit compilé et installé automatiquement lorsque l'on démarre sur un nouveau noyau.

=== Variables disponibles ===

Quelques variables peut être utilisées dans les options et les commandes comme vous pouvez le voir dans la commande MAKE[0] de l'exemple précédent. Ces variables sont définies par la configuration de DKMS ou par les options passées à la commande dkms.

* $kernelver : Cette variable contient la version du noyau pour laquelle le module est en train d'être construit. C'est particulièrement utile dans la définition de la commande MAKE, par exemple MAKE[0]="make INCLUDEDIR=/lib/modules/${kernelver}/build/include"
* $dkms_tree : Cette variable indique ou se trouve l'arbre DKMS sur le système local. Par défaut il s'agit de /var/lib/dkms, mais cette valeur ne doit pas être mise en dur dans les dkms.conf au cas ou l'utilisateur aurait changé cela sur son système (Un tel réglage se fait à l'aide de /etc/dkms/framework.conf ou en ajoutant l'option --dkmstree lors de l'appel, mais nous ne verrons pas ce genre d'utilisations avancées dans cette article).
* $source_tree : Cette variable indique ou DKMS stocke les sources des modules sur le système. Par défaut il s'agit de /usr/src, mais cette valeur ne doit pas être mise en dur dans les dkms.conf au cas ou l'utilisateur aurait changé cela sur son système (à l'aide de /etc/dkms/framework.conf ou en ajoutant l'option --sourcetree lors de l'appel).
* $kernel_source_dir : Cette variable contient le chemin vers les sources du kernel pour lequel on construit le module. Il s'agit en général de /lib/modules/$kernelver/build, à moins qu'un autre chemin ait été spécifié avec l'option --kernel-sourcedir

=== Options que l'on peut définir dans le fichier dkms.conf ===
Tout d'abord, le nom des options est sensible à la casse donc elles doivent être écrites en majuscules. Seules 4 options sont obligatoires :

* PACKAGE_NAME : le nom du package
* PACKAGE_VERSION : la version du package
* BUILT_MODULE_NAME[0] : le nom du module construit. S'il y en a plusieurs, ça sera BUILT_MODULE_NAME[1], BUILT_MODULE_NAME[2], ... Les modules non listés ici ne seront pas installés même s'il sont construit par la commande MAKE[0]
* DEST_MODULE_LOCATION[0] : l'emplacement ou installer le module numéro 0. Ce chemin est relatif au répertoire des modules, et sera par exemple "3rdparty". Il faut renseigner DEST_MODULE_LOCATION[#] pour chaque module listé dans BUILT_MODULE_NAME

De nombreuses autres options bien pratiques mais facultatives dont disponibles :

* MAKE[#] : la commande pour compiler le(s) modules. Voir l'explication de MAKE_MATCH pour la signification du numéro passé en paramètre. Cette option est facultative dans la mesure ou la commande standard de construction d'un module kernel sera utilisée si elle n'est pas définie.
* MAKE_MATCH[#] : cet ensemble d'options permet d'avoir une commande de construction différente en fonction des versions du kernel. Chacune contient une expression régulière qui sera comparée à la version du noyau. Le numéro de la dernière qui correspond indiquera le numéro de commande MAKE à utiliser.
* BUILT_MODULE_LOCATION[#] : le chemin relatif vers le module généré. Cela est nécessaire lorsque le module est généré dans un sous répertoire du répertoire de compilation.
* DEST_MODULE_NAME[#] : le nom a utiliser pour installer le module, s'il y a besoin de le renommer. L'extension (.o ou .ko) ne doit pas être spécifiée. Par défaut le nom original BUILT_MODULE_NAME[#] est conservé.
* MODULES_CONF_ALIAS_TYPE[#] : cette option indique pour chaque module quel alias créer dans /etc/modprobe.conf. DKMS calculera automatiquement le numéro de l'alias en fonction de ceux qui existent déjà. Par exemple si MODULES_CONF_ALIAS_TYPE[0] contient eth et que vous avez déjà eth0 et eth1 définis dans /etc/modprobe.conf, DKMS ajoutera un alias eth2 vers le module. Cette fonctionnalité est à utiliser avec précaution dans la mesure ou elle gère mal les cas complexes, comme par exemple les systèmes avec plusieurs cartes réseau utilisant le même module.
* MODULES_CONF_OBSOLETES[#] : cette option indique à DKMS quels modules vers lesquels pointent des alias dans /etc/modprobe.conf doivent être remplacés par ce nouveau module. Si il y en a plusieurs, les séparer par une virgule. Je pense que ce sera plus clair sur un exemple. Considérons le fichier modprobe.conf suivant :

alias eth0 bcm4400
alias eth1 e1000

Si l'on se contente des options suivantes, DKMS n'a aucun moyen de deviner que b44 et bcm4400 gèrent la même carte et un nouvel alias sera généré.

BUILT_MODULE_NAME[0]="b44"
MODULES_CONF_ALIAS_TYPE[0]="eth"

Le nouveau modprobe.conf contiendra donc :

alias eth0 bcm4400
alias eth1 e1000
alias eth2 b44

Si par contre on ajoute MODULES_CONF_OBSOLETES[0]="bcm4400", le nouveau modprobe.conf sera correct :

alias eth0 b44
alias eth1 e1000

* MODULES_CONF_OBSOLETE_ONLY[#] : Si cette option vaut yes, DKMS ne modifiera modprobe.conf que s'il trouve un alias vers un module obsolète à remplacer. Il n'y aura donc jamais de nouveaux alias de créés.
* STRIP[#] : Par défaut, les symboles de deboguage sont supprimés des modules à l'aide de strip -g. Positionner cette option à "no" pour l'un des modules permet de les conserver dans ce module.
* REMAKE_INITRD : Cette option indique, lorsque la première lettre est y ou Y, qu'il faut régénérer l'initrd après l'installation d'une nouvelle version du module. C'est surtout nécessaire pour les pilotes de contrôleur disque.
* MODULES_CONF[#] : Cette option permet d'indiquer des lignes à ajouter au fichier modprobe.conf. Lorsqu'une première version du module est installée sur l'un des noyaux, les lignes de MODULES_CONF sont ajoutées au fichier modprobe.conf (avant que l'initrd soit régénéré si REMAKE_INITRD est activé). Elles sont supprimées lorsque la dernière version est désinstallée. On peut imaginer par exemple dans le cas de l'ipw2200 MODULES_CONF[0]="options ipw2200 led=1".
* PATCH[#] : Cette option permet d'indiquer des patchs à appliquer sur les sources du pilote avant de le compiler. Tout les patchs doivent se trouver dans /usr/src/<module>-<version du module>/patches/ et sont appliqués avec patch -p1. Vous pouvez spécifier pour quels noyaux chaque patch doit être appliqué en utilisant l'option PATCH_MATCH ci-dessous.
* PATCH_MATCH[#] : Cette option sert à indiquer pour quels noyaux les patchs contenus dans le tableau PATCH doivent être appliqués. PATCH_MATCH[i] contient une expression régulière qui est comparés à la version du noyau cible pour décider si PATCH[i] doit être appliqué.
* AUTOINSTALL : Si cette option vaut "yes", le service dkms (/etc/rc.d/init.d/dkms) essayera automatiquement de construire et installer ce module sur le noyau sur lequel vous démarrez. Ce service ne fera toutefois rien si plusieurs versions du module sont présentes dans l'arbre DKMS, ce sera à vous de décider laquelle vous souhaitez.
* BUILD_EXCLUSIVE_KERNEL : Cette option permet d'indiquer une expression régulière décrivant les versions de noyau pour lesquelles DKMS est autorisé à construire votre module. Si vous essayez de construire le module pour un noyau ne correspondant pas à cette expression régulière, DKMS provoquera une erreur. Par exemple, si vous indiquez "^2.6.*", votre module ne pourra être construit que pour les noyaux 2.6 et une erreur se produira sur les 2.4.
* BUILD_EXCLUSIVE_ARCH : Cette option fonctionne comme BUILD_EXCLUSIVE_KERNEL mais limite l'architecture du noyau au lieu de sa version. Par exemple, si cette option vaut "i.86" votre module pourra être construit pour i386 ou i586 mais pas ppc, x86_64, ni s390.
* POST_ADD : Cette option indique le nom d'un script à exécuter après le traitement de la commande add. Le chemin doit être indiqué relativement aux sources du module.
* POST_BUILD : Cette option indique le nom d'un script à exécuter après le traitement de la commande build. Le chemin doit être indiqué relativement aux sources du module.
* POST_INSTALL : Cette option indique le nom d'un script à exécuter après le traitement de la commande install. Le chemin doit être indiqué relativement aux sources du module.
* POST_REMOVE : Cette option indique le nom d'un script à exécuter après le traitement de la commande remove. Le chemin doit être indiqué relativement aux sources du module.
* PRE_BUILD : Cette option indique le nom d'un script à exécuter avant le traitement de la commande build. Le chemin doit être indiqué relativement aux sources du module.

=== Intégration avec rpm ===

Les possibilités d'intégration de DKMS avec RPM sont doubles :

* Création manuelle de RPM contenant les sources et le dkms.conf ;
* Création automatique de rpm contant un module compilé à l'aide de dkms, et dont la gestion est faite par DKMS.

En ce qui concerne le premier cas, la création du RPM est assez simple si vous savez construire des RPM. Vous indiquez comme source le tar.gz des sources du module et dans la section %install vous copiez les sources vers /usr/src/<nom du module>-<version du module> et vous y écrivez le dkms.conf (Il est également possible de mettre le dkms.conf dans un fichier annexe et de l'inclure comme source, mais l'avoir inclus permet d'utiliser les macros RPM %name, %version, ... afin de créer rapidement un .spec pour un nouveau module). Ensuite vous indiquez en %post et %preun les commandes DKMS à invoquer (add, build et install en %post et remove en %preun).
Le modèle de fichier spec suivant pourra vous servir de base dans la majorité des cas.

%define module_name rt2500

Name: dkms-%{module_name}
Version: 1.4.6.2
Release: 1mdk
Summary: DKMS-ready kernel-source for the RT2500 driver
License: GPL
URL: http://www.ralinktech.com/supp-1.htm
Source: http://www.ralinktech.com/drivers/Linux/RT2500-Linux-STA-%{version}.tar.bz2
Group: System/Kernel and hardware
Requires(pre): dkms
Requires(post): dkms
Buildroot: %{_tmppath}/%{name}-%{version}-root
Buildarch: noarch

%description
Driver for the Ralink RT2500 802.11g chipset

%prep
%setup -q -n RT2500-Linux-STA-%{version}
chmod 0755 Module/2.*.x

%build

%clean
rm -fr $RPM_BUILD_ROOT

%install
mkdir -p %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cp -a Module/* %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cp -af Module/2.6.x/Makefile %{buildroot}/usr/src/%{module_name}-%{version}-%{release}
cat > %{buildroot}/usr/src/%{module_name}-%{version}-%{release}/dkms.conf <<EOF

PACKAGE_VERSION="%{version}-%{release}"

# Items below here should not have to change with each driver version
PACKAGE_NAME="%{module_name}"
MAKE[0]="make -C \${kernel_source_dir} SUBDIRS=\${dkms_tree}/\${PACKAGE_NAME}/\${PACKAGE_VERSION}/build modules"
CLEAN="make -C \${kernel_source_dir} SUBDIRS=\${dkms_tree}/\${PACKAGE_NAME}/\${PACKAGE_VERSION}/build clean"

BUILT_MODULE_NAME[0]="\$PACKAGE_NAME"

DEST_MODULE_LOCATION[0]="/kernel/drivers/net/wireless/"

MODULES_CONF_ALIAS_TYPE[0]="ra"

REMAKE_INITRD="no"
AUTOINSTALL=yes

EOF

%post
dkms add -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade
dkms build -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade
dkms install -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade

%preun
dkms remove -m %{module_name} -v %{version}-%{release} --rpm_safe_upgrade --all ||:

%files
%defattr(-,root,root)
/usr/src/%{module_name}-%{version}-%{release}

Listing 7: Exemple de fichier .spec pour un package DKMS

Il y a peu de remarques à faire sur ce fichier si ce n'est l'importance de ne pas oublier --rpm_safe_upgrade et surtout ||: dans le %preun qui permet que le rpm puisse être désinstallé même si le remove échoue (par exemple parce que le build avait échoué donc le module n'est pas installé).

Pour ce qui est du deuxième cas (création de RPM binaires), c'est encore plus simple, il suffit de compiler le module puis d'utiliser dkms mkrpm en précisant le module, sa version et le ou les noyaux qui vous intéressent. Contrairement aux RPM créés à la main comme précédemment, cette méthode nécessite par contre d'être root sur la machine générant le package (ou d'avoir par exemple un sudo sur la commande dkms).

== Avantages et inconvénients ==

Pour finir, voici une petite liste des avantages et des inconvénients que je vois à utiliser DKMS. Cette liste vous aidera probablement à décider si vous souhaiter essayer de gérer vos pilotes additionnels avec DKMS.

=== Avantages ===

* Il n'y a plus besoin de se préoccuper de ses pilotes additionnels lorsque l'on met à jour son noyau ;
* Il est beaucoup plus facile de distribuer des pilotes (y compris les modules propriétaires avec une couche libre de jonction). Avec un seul paquetage à installer l'utilisateur n'a rien à faire pour que ça marche sur son noyau ;
* Il est beaucoup plus facile (et léger) de distribuer des correctifs sur les noyaux. Il n'y a plus besoin de distribuer un nouveau noyau lorsque le problème n'affecte qu'un module, DKMS gérera très bien le remplacement du module original, même si celui-ci n'était initialement pas installé avec DKMS ;
* Il est possible d'avoir plusieurs versions du module présentes sur sa machine simultanément et de basculer entres elles à l'aide de la commande dkms, ce qui est très pratique pour des tests ;
* Il est possible de distribuer le module avec la partie userspace associée plutôt qu'avec le noyau, ce qui permet d'éviter les problèmes de désynchronisation.

=== Inconvénients ===

* Le fonctionnement classique de DKMS implique la présence d'un compilateur sur la machine, ce qui est en particulier problématique pour la sécurité des serveurs. Toutefois, DKMS reste utile sans compilateur sur le serveur pour générer depuis une autre machine un RPM contenant la nouvelle version compilée du module et pouvoir ainsi facilement mettre à jour toutes ses machines.
* De même DKMS a besoin des sources du noyau, ce qui occupe beaucoup d'espace disque.
* La recompilation dynamique par un service au démarrage n'est pas adaptée pour les modules nécessaires plus tôt (pilotes de contrôleur disque par exemple), il faut donc dans ce cas s'assurer de faire compiler à DKMS le pilote pour le nouveau noyau avant de redémarrer. Cet inconvénient n'en est toutefois pas réellement un dans la mesure où le problème est le même lorsque le module en question est compilé à la main sans DKMS.
* DKMS est basé sur RPM et ne fonctionnera donc que sur des distributions utilisant RPM (RedHat, Mandriva, SuSE, ...). L'utilisation de rpm est pourtant très localisée (par exemple détection de l'architecture du noyau cible) et il devrait être assez facile de s'en passer.
* DKMS ne prend pour le moment pas en compte le fichier .config du noyau mais celui par défaut fourni par la distribution pour la famille de noyaux (smp, 64G, ...).

=== Références ===

* [http://linux.dell.com/dkms/dkms.html http://linux.dell.com/dkms/dkms.html]
* [http://www.linuxjournal.com/article/6896 http://www.linuxjournal.com/article/6896]
* [http://linux.dell.com/dkms/dkms-ols2004.pdf http://linux.dell.com/dkms/dkms-ols2004.pdf]
* [http://www.dell.com/downloads/global/power/1q04-ler.pdf http://www.dell.com/downloads/global/power/1q04-ler.pdf]
* [http://linux.dell.com/dkms/dkms-LWE-Boston2005.pdf http://linux.dell.com/dkms/dkms-LWE-Boston2005.pdf]

Pascal Terjan <pterjan@mandriva.com>
Cet article a été initialement publié dans le GNU/Linux Magazine 80 de Février 2006
Contexte</code>