Il s'agit de la commande fwts qui peut être exécutée dans le fournisseur d'hébergement gratuit OnWorks en utilisant l'un de nos multiples postes de travail en ligne gratuits tels que Ubuntu Online, Fedora Online, l'émulateur en ligne Windows ou l'émulateur en ligne MAC OS
PROGRAMME:
Nom
fwts - une suite de tests de firmware pour identifier les bogues de firmware.
SYNOPSIS
FWTS [Options] [essai(s)]
DESCRIPTION
Cette page de manuel documente brièvement les FWTS suite de tests du micrologiciel. L'outil FWTS is
composé de plus de cinquante tests conçus pour examiner et tester différents aspects de
Micrologiciel du PC. Beaucoup de ces tests nécessitent un accès super utilisateur pour extraire des tables et interagir
avec le firmware et l'ACPI, donc en cours d'exécution FWTS l'utilisation de sudo est requise.
Fonctionnement FWTS sans option exécutera tous les tests par lots qui ne nécessitent aucun utilisateur
interaction. Cependant, on peut sélectionner uniquement des tests spécifiques à exécuter si nécessaire.
Par défaut FWTS affiche les résultats du test dans le fichier journal résultats.log cependant un autre
le nom du fichier journal peut être spécifié et, si nécessaire, la sortie vers stderr ou stdout peut être
choisi.
Notez qu'il existe une variété de tests, y compris des tests qui peuvent potentiellement bloquer une machine
(comme une suspension/hibernation/reprise).
OPTIONS
Les options de fwts sont les suivantes :
- afficher les résultats sur stdout.
--acpica
activer les options du mode d'exécution ACPICA. Ceux-ci peuvent être spécifiés par des virgules séparés
liste d'une ou plusieurs options. Les options disponibles sont : sérialisé (sérialisé
exécution d'AML), slack (exécuter en mode moins pédant), ignorer les erreurs (ignorer ACPICA
erreurs d'exception), disable-auto-repair (désactivez ACPICA de la réparation automatique
contrôles ACPICA rompus). Notez que le mode slack activera les retours implicites de
zéro sur les méthodes de contrôle pour tenter de permettre à AML bogué de fonctionner sur non-Windows
systèmes.
--acpica-debug
activer les messages d'avertissement et d'erreur de débogage ACPICA lors de l'appel du sous-système ACPICA.
Ceci est principalement destiné aux développeurs de fwts pour aider à traquer les problèmes d'interfaçage ACPICA
avec fwts.
--acpicompliance
exécuter uniquement les tests qui vérifient spécifiquement la conformité avec l'ACPI
Caractéristiques. Il peut s'agir d'un sous-ensemble des tests ACPI.
-une, --tout
exécuter tous les tests.
--arch=nom
spécifier l'architecture cible dont le firmware est testé. Cela permet aux fwts
s'exécuter sur une architecture (l'hôte) mais effectuer des tests pour une autre
architecture (la cible). Les chaînes d'architecture connues sont : x86, x86_32 ou x86_64
pour Intel; ia64 pour Itanium ; arm64 ou aarch64 pour ARMv8. A moins que cette option ne soit
spécifié, la cible est supposée être la même que l'hôte.
-b, --grouper
exécuter les tests par lots non interactifs. Les tests par lots ne nécessitent aucune interaction de l'utilisateur.
--batch-expérimental
exécuter uniquement des tests expérimentaux par lots.
--désassembler-aml
désassembler le code d'octet AML (langage machine ACPI). Cela tente de désassembler AML
dans les tables DSDT et SSDT et génère les sources DSDT.dsl et SSDTx.dsl.
-ré, --décharger
extrait les données du micrologiciel et les vide dans des fichiers journaux. Cela génère :
acpidump.log - contenant un vidage hexadécimal des tables ACPI (qui peut être lu en utilisant
résumé).
dmesg.log - contenant les messages actuels du journal du noyau.
dmidecode.log - contenant la sortie de dmidecode.
lspci.log - contenant la sortie de lspci -vv -nn
cpuinfo.log - contenant la sortie de cat / proc / cpuinfo
README.txt - contenant un horodatage et des informations sur la version du noyau.
--dumpfile=acpidump.log
charge les tables ACPI à partir de la sortie générée à partir d'acpidump ou de sudo fwts --dump. Les
ce dernier est préféré car fwts --dump est capable de vider plus de tables que acpidump. Cette
permet de vider les tables d'une machine et de les traiter avec des fwts sur une autre
machine.
--uefi-get-var-multiple
spécifie le nombre de fois pour obtenir une variable dans la variable uefirtvariable get variable
test de résistance.
--uefi-set-var-multiple
spécifie le nombre de fois qu'il faut définir une variable dans la variable uefirtvariable set variable
test de résistance.
--uefi-query-var-multiple
spécifie le nombre de fois où interroger une variable dans la requête uefirtvariable
test de résistance variable.
--filter-erreur-rejet
spécifie les erreurs que l'on veut ignorer en silence. On fournit une virgule
liste séparée des étiquettes de message d'erreur fwts que l'on veut que fwts ne signale pas comme
les erreurs. fwts exécutera le test mais s'il y a un échec du test et que l'étiquette correspond
celui fourni dans cette liste fwts ignorera alors simplement cette erreur. Ça ne peut pas être
utilisé avec --filter-error-keep.
--filter-erreur-garder
spécifie les erreurs que l'on veut conserver, toutes les autres erreurs sont ignorées en silence.
On fournit une liste séparée par des virgules d'étiquettes de message d'erreur fwts que l'on veut fwts
signaler comme des erreurs, les autres échecs de test ne seront pas signalés et ignorés en silence.
Cela ne peut pas être utilisé avec --filter-error-discard.
-F, --force-nettoyage
crée un nouveau fichier journal des résultats, plutôt que de simplement l'ajouter à un fichier existant
(défaut).
-h, --Aidez-moi
affiche la page d'aide interne.
-je, --interactif
exécuter les tests interactifs. Ces tests nécessitent une interaction de l'utilisateur.
--interactif-expérimental
exécuter uniquement des tests expérimentaux interactifs.
-j, --json-chemin-des-données
spécifie le chemin d'accès aux fichiers de données fwts json. Ces fichiers contiennent au format json
des tables de configuration, par exemple des modèles de balayage de klog.
-k, --klog=fichier
lire le journal du noyau à partir du fichier spécifié plutôt que depuis l'anneau du journal du noyau
amortir. Cela permet d'exécuter les tests d'analyse des journaux du noyau tels que klog contre
données de journal pré-collectées.
--log-champs
afficher les champs de filtrage des journaux disponibles. Spécification de ces champs avec --log-filter
pour sélectionner les champs que l'on souhaite enregistrer.
--log-filtre
spécifier les types particuliers de données de journal à insérer dans le fichier journal. Chaque
la ligne de données de journal est étiquetée avec un marqueur spécial en fonction du type de journal
des informations sont émises. Les types disponibles peuvent être vus en utilisant --log-fields.
Spécifiez les types de journaux souhaités avec une liste séparée par des virgules. Pour désactiver un champ, préfixez
le nom avec ~, par exemple :
--log-filter=RES,SUM n'enregistre que les résultats et les lignes de résumé.
--log-filter=ALL,~INF enregistre toutes les lignes à l'exception des lignes d'information.
--format-journal
spécifier les informations dans chaque ligne de journal. Les spécificateurs suivants sont disponibles :
%date - date
%temps temps
%field - champs de filtre de journal
%owner - nom de la routine de test
%level - niveau d'échec du test
%line - ligne de journal
par exemple --log-format="%date %time [%field] (%owner): "
--niveau de journal [critique|élevé|moyen|faible|info|tout]
spécifiez le niveau d'échec du test à consigner. Niveaux d'échec des tests égaux et supérieurs à
les spécifiés sont consignés et enregistrés comme des échecs. La valeur par défaut est « all » (qui est
identique à 'info'). Par exemple, un niveau de journalisation de « moyen » enregistrera simplement le test
échecs de niveau « moyen », « élevé » et « critique », où en tant que niveau de journal de
« critical » enregistrera simplement les échecs de niveau « critique ».
--type-journal
spécifiez le type de journal. Actuellement, les types de journaux en texte clair, json et xml sont disponibles et
la valeur par défaut est le texte en clair.
--lspci=chemin
spécifiez le chemin complet et le nom de fichier du binaire lspci.
-P, --états-d'alimentation
exécuter des tests d'état d'alimentation S3 et S4 (tests s3, s4)
--résultats-pas de séparateurs
pas de jolie impression de séparateurs horizontaux dans le fichier journal des résultats.
-r, --results-output=nom de fichier
spécifiez le fichier journal de sortie des résultats. On peut également spécifier stdout et stderr pour
rediriger vers ces flux de sortie.
-R, --rsdp=adressephy
spécifier l'adresse physique de l'ACPI RSDP. Ceci est utile sur certains systèmes où il
ne peut pas être détecté automatiquement.
--pm-method=méthode
spécifiez la méthode d'alimentation à utiliser pour entrer S3 ou S4 (ou l'autodétection sera utilisée).
Les spécificateurs suivants sont disponibles :
logind - la méthode par défaut, lorsqu'elle est disponible (nécessite dbus et logind).
pm-utils - la méthode par défaut précédente, désormais obsolète.
sysfs - la solution de secours, utilisée lorsque logind n'est pas disponible.
par exemple --pm-method=sysfs
--s3-delay-delta=N
temps à ajouter au délai entre chaque itération S3.
--s3-vérification-de-périphérique
vérifier les différences entre les configurations d'appareils sur un cycle S3. Notez que cela ajoute 15
secondes de délai après chaque reprise s3 pour permettre au wifi de se réassocier.
--s3-device-check-délai
spécifier le temps d'attente pendant que les appareils se reconfigurent (par exemple, le wifi pour se réassocier,
ethernet pour se connecter..) avant qu'une vérification de la configuration de l'appareil ne soit exécutée. La valeur par défaut est
15 secondes. Si cette option est utilisée, la vérification de l'appareil est supposée afin de ne pas
devez également utiliser l'indicateur --s3-device-check.
--s3-hybride
permet à fwts d'exécuter Hybrid Sleep.
--s3-min-délai=N
temps minimum entre les itérations S3.
--s3-max-délai=N
temps maximum entre les itérations S3.
--s3-multiple=N
a spécifié le nombre de plusieurs tests de suspension/reprise S3 à exécuter. La valeur par défaut est 2
Des tests.
--s3-quirks=--bizarre[,--bizarre]
spécifiez une liste d'arguments quirk séparés par des virgules à transmettre à pm-suspend, par exemple
exemple : --s3-quirks=--quirk-s3-bios,--quirk-save-pci
--s3-sleep-delay=N
sommeil N secondes entre le début de la suspension et l'heure du réveil. Notez que ce
le temps DOIT être plus long que le temps qu'il faut pour suspendre la machine sinon le
la minuterie de réveil se déclenchera pendant l'état de suspension. La valeur par défaut est de 30 secondes.
--s3-suspend-time=N
spécifiez la durée de suspension maximale autorisée en secondes. Si la suspension prend plus de
ceci alors une erreur est enregistrée.
--s3-resume-time=N
spécifiez le temps de reprise maximum autorisé en secondes. Si la reprise prend plus de
ceci alors une erreur est enregistrée.
--s3power-sleep-delay=N
spécifiez la durée de suspension en secondes. Plus la valeur est élevée, plus la précision est élevée
le résultat du test s3power. Les durées inférieures à 10 minutes ne sont pas recommandées.
--s4-delay-delta=N
temps à ajouter au délai entre chaque itération S4.
--s4-vérification-de-périphérique
vérifier les différences entre les configurations d'appareils sur un cycle S4. Notez que cela ajoute 15
secondes de délai après chaque reprise s3 pour permettre au wifi de se réassocier.
--s4-device-check-délai
spécifier le temps d'attente pendant que les appareils se reconfigurent (par exemple, le wifi pour se réassocier,
ethernet pour se connecter..) avant qu'une vérification de la configuration de l'appareil ne soit exécutée. La valeur par défaut est
15 secondes. Si cette option est utilisée, la vérification de l'appareil est supposée afin de ne pas
devez également utiliser l'indicateur --s4-device-check.
--s4-min-délai=N
temps minimum entre les itérations S4.
--s4-max-délai=N
temps maximum entre les itérations S4.
--s4-multiple=N
a spécifié le nombre de plusieurs tests d'hibernation/reprise S4 à exécuter. La valeur par défaut est 2
Des tests.
--s4-quirks=--bizarre[,--bizarre]
spécifiez une liste d'arguments quirk séparés par des virgules à transmettre à pm-hibernate, par exemple
exemple : --s4-quirks=--quirk-save-pci
--s4-sleep-delay=N
sommeil N secondes entre le début de l'hibernation et l'heure du réveil. Notez que ce
le temps DOIT être plus long que le temps qu'il faut pour hiberner la machine sinon le
la minuterie de réveil se déclenchera pendant l'état de veille prolongée. La valeur par défaut est actuellement 90
secondes.
-p, --show-progression
montrer la progression des tests en cours. Chaque test sera identifié au fur et à mesure qu'il est
Cours. Pour les tests longs, un pourcentage du temps d'achèvement sera affiché. À partir de fwts
0.19.06 ceci est activé par défaut et peut être désactivé avec --quiet (ou -q).
-q, --silencieux
fonctionner tranquillement sans sortie vers stdout.
-RÉ, --show-progress-dialog
afficher la progression des tests en cours d'exécution sous une forme pouvant être acheminée dans la boîte de dialogue
outil avec l'option --gauge.
-Oui, --show-tests
afficher les noms des tests disponibles. Par défaut, tous les tests seront affichés. Utilisez le --batch,
--interactive, --batch-experimental, --interactive-experimental, --utils options pour
montrer ces tests spécifiques.
--show-tests-complet
afficher tous les tests disponibles répertoriés par description de test mineur. Par défaut s'affichera
tous les tests. Utilisez --batch, --interactive, --batch-experimental,
--interactive-experimental options pour afficher ces tests spécifiques.
--show-tests-catégories
afficher tous les tests disponibles et les catégories auxquelles ils appartiennent.
--skip-test=test[,test..]
spécifier les tests à ignorer et à ne pas exécuter. La liste doit être séparée par des virgules.
--stdout-résumé
sortie SUCCESS ou FAILED vers stdout à la fin des tests.
-t, --table-path=chemin
spécifiez le chemin contenant les tables ACPI. Ces tables doivent être nommées dans le
format : tablename.dat, par exemple DSDT.dat, par exemple, tel qu'extrait à l'aide
acpidump ou fwts --dump puis acpixtract.
-tu, --utils
exécuter des utilitaires. Conçu pour vider les informations système, telles que les tableaux ACPI annotés,
Mémoire CMOS, carte mémoire Int 15 E820, données ROM du firmware.
-dans, --version
le numéro de version de sortie et la date de construction du FWTS outil.
-w, --largeur=N
spécifiez la largeur en caractères du fichier journal de sortie. La valeur par défaut est 130.
EXEMPLES
Exécutez tous les tests par lots et ajoutez les résultats dans le journal par défaut results.log :
sudo fwts
Exécutez tous les tests interactifs et démarrez un journal de résultats propre appelé interactive.log :
sudo fwts -i -f -r interactif.log
Exécutez tous les tests, interactifs et batch :
sudo fwts -i -b
Exécutez uniquement les tests de batterie et de cpufreq :
sudo fwts batterie cpufreq
Exécutez tous les tests par lots et définissez un nouveau format de journal en utilisant uniquement la date et le numéro de ligne :
sudo fwts --log-format="%date %line: "
Exécutez tous les tests interactifs et enregistrez uniquement les résultats, les informations et les données récapitulatives :
sudo fwts -i --log-filter=RES,INF,SOMME
Videz toutes les informations intéressantes du micrologiciel dans des fichiers journaux pour une analyse ultérieure :
sudo fwts --dump
Affichez la version du noyau et du pilote ACPI et les informations du BIOS :
sudo fwts -w 80 -r version stdout bios_info --log-filter=INF --log-format=""
Afficher les tests expérimentaux batch et batch :
fwts --show-tests --batch --batch-experimental
Exécutez plusieurs tests S3 avec un délai entre chaque test allant de 1 seconde à 10 secondes
avec un delta de retard par test de 0.2 seconde
sudo fwts s3 --s3-multiple=100 --s3-min-delay=1 --s3-max-delay=10
--s3-délai-delta=0.2
Utiliser fwts en ligne à l'aide des services onworks.net