fwts – Online w chmurze

PROGRAM:

IMIĘ

fwts – zestaw testów oprogramowania sprzętowego umożliwiający identyfikację błędów oprogramowania sprzętowego.

STRESZCZENIE

racja [Opcje] [test(y)]

OPIS

Ta strona podręcznika opisuje pokrótce racja zestaw testów oprogramowania sprzętowego. Narzędzie racja is
składa się z ponad pięćdziesięciu testów, które mają na celu zbadanie i przetestowanie różnych aspektów
Oprogramowanie sprzętowe komputera. Wiele z tych testów wymaga dostępu superużytkownika do wyodrębniania tabel i interakcji
z oprogramowaniem sprzętowym i ACPI, więc działa racja wymagane jest użycie sudo.
Bieganie racja bez opcji przeprowadzi wszystkie testy wsadowe, które nie wymagają użycia żadnego użytkownika
interakcja. Można jednak wybrać tylko określone testy do uruchomienia, jeśli jest to wymagane.

Domyślnie racja wyprowadza wyniki testu do pliku dziennika results.log jednak inny
Można określić nazwę pliku dziennika i, jeśli to konieczne, wyprowadzić dane na stderr lub stdout
wybrany.

Należy pamiętać, że istnieje wiele testów, w tym testy, które mogą potencjalnie zawiesić maszynę
(takie jak zawieszenie/hibernacja/wznowienie).

OPCJE

opcje fwts są następujące:

- wyprowadź wyniki na standardowe wyjście.

--acpica
włącz opcje trybu wykonywania ACPICA. Można je określić jako rozdzielone przecinkami
lista jednej lub więcej opcji. Dostępne opcje to: serializowany (serializowany
wykonanie AML), slack (uruchom w mniej pedantycznym trybie), ignoruj ​​błędy (ignoruj ​​ACPICA
błędy wyjątków), wyłącz automatyczną naprawę (wyłącz ACPICA z automatycznego naprawiania
zepsute kontrole ACPICA). Zauważ, że tryb luzu włącza ukryte zwroty
zero w metodach kontroli, aby umożliwić błędną obsługę AML w systemach innych niż Windows
systemy.

--acpica-debug
włączyć ostrzeżenia debugowania ACPICA i komunikaty o błędach podczas wywoływania podsystemu ACPICA.
Jest to przeznaczone głównie dla programistów fwts, aby pomóc w wyśledzeniu wszelkich problemów z interfejsem ACPICA
z fwtami.

--przestrzeganie
uruchamiaj tylko te testy, które konkretnie sprawdzają zgodność z ACPI
specyfikacje. Może to być podzbiór testów ACPI.

-za, --wszystko
przeprowadź wszystkie testy.

--arch=nazwa
określ docelową architekturę, której oprogramowanie sprzętowe jest testowane. Pozwala to na fwts
działać na jednej architekturze (hoście), ale wykonywać testy na innej
architektura (cel). Znane ciągi architektury to: x86, x86_32 lub x86_64
dla Intela; ia64 dla Itanium; arm64 lub aarch64 dla ARMv8. Chyba, że ​​jest taka opcja
określony, zakłada się, że cel jest taki sam jak host.

-B, --seria
uruchom nieinteraktywne testy wsadowe. Testy wsadowe nie wymagają interakcji użytkownika.

--wsadowo-eksperymentalny
przeprowadzaj tylko wsadowe testy eksperymentalne.

--disassemble-aml
zdemontować kod bajtowy AML (język maszynowy ACPI). To próba zdemontowania AML
w tabelach DSDT i SSDT oraz generuje źródła DSDT.dsl i SSDTx.dsl.

-D, --wysypisko
wyodrębnia dane oprogramowania sprzętowego i zrzuca je do plików dziennika. To generuje:
acpidump.log - zawierający zrzut szesnastkowy tabel ACPI (który można odczytać za pomocą
acpixtract).
dmesg.log - zawierający bieżące komunikaty dziennika jądra.
dmidecode.log - zawierający dane wyjściowe z dmidecode.
lspci.log - zawierający dane wyjściowe z lspci -vv -nn
cpuinfo.log - zawierający dane wyjściowe z cat / proc / cpuinfo
README.txt - zawierający znacznik czasu i informacje o wersji jądra.

--dumpfile=acpidump.log
załaduj tabele ACPI z danych wyjściowych wygenerowanych z acpidump lub z Sudo fwts --dump. The
to drugie jest preferowane, ponieważ fwts --dump jest w stanie zrzucić więcej tabel niż acpidump. Ten
pozwala zrzucić tabele z jednego komputera i przetworzyć je za pomocą fwts na innym
maszyna.

--uefi-get-var-multiple
określa, ile razy należy uzyskać zmienną w zmiennej get zmiennej uefirt
test warunków skrajnych.

--uefi-set-var-multiple
określa, ile razy należy ustawić zmienną w zmiennej ustawionej uefirtvariable
test warunków skrajnych.

--uefi-query-var-multiple
określa liczbę zapytań o zmienną w zapytaniu o zmienną uefirt
zmienny test warunków skrajnych.

--filtr-błąd-odrzuć
określa błędy, które należy po cichu zignorować. Jeden wprowadza przecinek
rozproszona lista etykiet komunikatów o błędach fwts, jako których fwts nie ma zgłaszać
błędy. fwts uruchomi test, ale jeśli wystąpi błąd testu i etykieta będzie zgodna
ten podany na tej liście fwts po prostu zignoruje ten błąd. To nie może być
używane z --filter-error-keep.

--filter-zachowaj błąd
określa błędy, które chce się zachować, wszystkie inne błędy są dyskretnie ignorowane.
Jeden dostarcza rozdzieloną przecinkami listę etykiet komunikatów o błędach fwts, które mają być fwts
zgłosić jako błędy, inne niepowodzenia testów nie będą zgłaszane i dyskretnie ignorowane.
Nie można tego użyć z opcją --filter-error-discard.

-F, --wymuszenie czyszczenia
tworzy nowy plik dziennika wyników, zamiast po prostu dołączać do istniejącego
(domyślny).

-H, --help
wyświetla wewnętrzną stronę pomocy.

-ja, --interaktywny
uruchom testy interaktywne. Testy te wymagają interakcji użytkownika.

--interaktywno-eksperymentalny
przeprowadzaj wyłącznie interaktywne testy eksperymentalne.

-J, --json-ścieżka-danych
określa ścieżkę do plików danych fwts json. Pliki te zawierają format json
tabele konfiguracyjne, na przykład wzorce skanowania klog.

-k, --klog=plik
odczytaj dziennik jądra z określonego pliku, a nie z pierścienia dziennika jądra
bufor. Pozwala to na uruchomienie testów skanowania dziennika jądra, takich jak klog
wstępnie zebrane dane dziennika.

--pola-logowania
pokaż dostępne pola filtrowania logów. Określanie tych pól za pomocą --log-filter
aby wybrać, które pola mają być rejestrowane.

--filtr-logów
określić, jakie konkretne typy danych dziennika mają być zapisane w pliku dziennika. Każdy
linia danych dziennika jest oznaczona specjalnym znacznikiem w zależności od typu dziennika
informacja jest wyprowadzana. Dostępne typy można zobaczyć za pomocą --log-fields.
Określ żądane typy dzienników za pomocą listy rozdzielanej przecinkami. Aby wyłączyć pole, użyj prefiksu
nazwa z ~, na przykład:
--log-filter=RES,SUM rejestruje tylko wyniki i wiersze podsumowania.
--log-filter=ALL,~INF rejestruje wszystkie linie z wyjątkiem linii informacyjnych.

--format-dziennika
określ informacje w każdym wierszu dziennika. Dostępne są następujące specyfikatory:
%data - data
%czas czas
%field — pola filtrujące dziennik
%właściciel — nazwa procedury testowej
%level - poziom niepowodzenia testu
%line — linia dziennika
np. --log-format="%data %czas [%pole] (%właściciel): "

--poziom-logarytmowania [krytyczny|wysoki|średni|niski|informacje|wszystkie]
określ poziom niepowodzenia testu do zarejestrowania. Poziomy niepowodzeń testów równe i wyższe niż
określone są rejestrowane i rejestrowane jako awarie. Wartość domyślna to „wszystko” (tzn
identyczne z „informacjami”). Na przykład poziom dziennika „średni” spowoduje po prostu zarejestrowanie testu
awarie na poziomie „średnim”, „wysokim” i „krytycznym”, gdzie jako poziom log
„krytyczny” będzie po prostu rejestrował awarie na poziomie „krytycznym”.

--typ dziennika
określ typ dziennika. Obecnie dostępne są typy dzienników w postaci zwykłego tekstu, json i xml
domyślnie jest to zwykły tekst.

--lspci=ścieżka
podaj pełną ścieżkę i nazwę pliku binarnego lspci.

-P, --stany-władzy
uruchom testy stanu zasilania S3 i S4 (testy s3, s4)

--wyniki-bez-separatorów
brak ładnego drukowania poziomych separatorów w pliku dziennika wyników.

-R, --results-output=nazwa pliku
określ plik dziennika wyników. Można również określić stdout i stderr to
przekieruj do tych strumieni wyjściowych.

-R, --rsdp=fiz.dr
określ adres fizyczny ACPI RSDP. Jest to przydatne w niektórych systemach, w których jest to wymagane
nie mogą zostać wykryte automatycznie.

--pm-metoda=metoda
określ metodę zasilania, która ma być używana do wejścia do S3 lub S4 (w przeciwnym razie zostanie zastosowana automatyczna detekcja).
Dostępne są następujące specyfikatory:
logind - metoda domyślna, jeśli jest dostępna (wymaga dbus i logind).
pm-utils - poprzednia metoda domyślna, obecnie przestarzała.
sysfs — rozwiązanie awaryjne, używane, gdy login nie jest dostępny.
np. --pm-method=sysfs

--s3-opóźnienie-delta=N
czas do dodania na opóźnienie pomiędzy każdą iteracją S3.

--s3-device-check
sprawdź różnice pomiędzy konfiguracjami urządzeń w cyklu S3. Zauważ, że to dodaje 15
sekundy opóźnienia po każdym wznowieniu s3, aby umożliwić ponowne skojarzenie Wi-Fi.

--s3-device-check-opóźnienie
określ czas oczekiwania na ponowną konfigurację urządzeń (np. Wi-Fi w celu ponownego skojarzenia,
Ethernet do połączenia..) przed uruchomieniem sprawdzania konfiguracji urządzenia. Wartość domyślna to
15 sekund. Jeśli ta opcja jest używana, zakłada się, że urządzenie sprawdzane jest, więc tak się nie dzieje
należy również użyć flagi --s3-device-check.

--s3-hybrydowy
umożliwia fwt uruchomienie trybu uśpienia hybrydowego.

--s3-min-opóźnienie=N
minimalny czas pomiędzy iteracjami S3.

--s3-max-opóźnienie=N
maksymalny czas pomiędzy iteracjami S3.

--s3-wielokrotność=N
określono liczbę wielu testów zawieszenia/wznowienia S3 do uruchomienia. Wartość domyślna to 2
testów.

--s3-dziwactwa=--dziwactwa[,--dziwactwa]
określ rozdzieloną przecinkami listę dziwacznych argumentów, które mają zostać przekazane do pm-suspend, for
przykład: --s3-quirks=--quirk-s3-bios,--quirk-save-pci

--s3-opóźnienie-uśpienia=N
sen N sekund od początku zawieszenia do czasu wybudzenia. Zauważ, że to
czas MUSI być dłuższy niż czas potrzebny do zawieszenia maszyny, w przeciwnym razie
licznik czasu budzenia uruchomi się w stanie zawieszenia. Wartość domyślna to 30 sekund.

--s3-czas-zawieszenia=N
określ maksymalny dozwolony czas zawieszenia w sekundach. Jeśli zawieszenie trwa dłużej niż
powoduje to zarejestrowanie błędu.

--s3-czas-wznowienia=N
określ maksymalny dozwolony czas wznowienia w sekundach. Jeśli wznowienie trwa dłużej niż
powoduje to zarejestrowanie błędu.

--s3opóźnienie-uśpienia-zasilania=N
określ czas trwania zawieszenia w sekundach. Im wyższa wartość, tym dokładniejsza
wynik testu s3power. Nie zaleca się trwania krótszych niż 10 minut.

--s4-opóźnienie-delta=N
czas do dodania na opóźnienie pomiędzy każdą iteracją S4.

--s4-device-check
sprawdź różnice pomiędzy konfiguracjami urządzeń w cyklu S4. Zauważ, że to dodaje 15
sekundy opóźnienia po każdym wznowieniu s3, aby umożliwić ponowne skojarzenie Wi-Fi.

--s4-device-check-opóźnienie
określ czas oczekiwania na ponowną konfigurację urządzeń (np. Wi-Fi w celu ponownego skojarzenia,
Ethernet do połączenia..) przed uruchomieniem sprawdzania konfiguracji urządzenia. Wartość domyślna to
15 sekund. Jeśli ta opcja jest używana, zakłada się, że urządzenie sprawdzane jest, więc tak się nie dzieje
należy również użyć flagi --s4-device-check.

--s4-min-opóźnienie=N
minimalny czas pomiędzy iteracjami S4.

--s4-max-opóźnienie=N
maksymalny czas pomiędzy iteracjami S4.

--s4-wielokrotność=N
określono liczbę wielu testów hibernacji/wznowienia S4 do uruchomienia. Wartość domyślna to 2
testów.

--s4-dziwactwa=--dziwactwa[,--dziwactwa]
określ rozdzieloną przecinkami listę dziwacznych argumentów, które mają zostać przekazane do pm-hibernate, for
przykład: --s4-quirks=--quirk-save-pci

--s4-opóźnienie-uśpienia=N
Sleep N sekund od początku hibernacji do czasu wybudzenia. Zauważ, że to
czas MUSI być dłuższy niż czas potrzebny do hibernacji komputera, w przeciwnym razie
licznik czasu budzenia uruchomi się w stanie hibernacji. Wartość domyślna to obecnie 90
towary drugiej jakości.

-P, --postęp-postęp
pokazać postęp przeprowadzanych testów. Każdy test zostanie zidentyfikowany w takim stanie, w jakim jest
uruchomić. W przypadku długich testów zostanie wyświetlony procent czasu ukończenia. Według stanu na dzień
0.19.06 jest to domyślnie włączone i można je wyłączyć za pomocą opcji --quiet (lub -q).

-Q, --cichy
działaj cicho, bez wyjścia na standardowe wyjście.

-D, --show-progres-dialog
wyprowadź postęp przeprowadzanych testów w formie, którą można przesłać do okna dialogowego
narzędzie z opcją --gauge.

-tak, --pokaż-testy
pokaż nazwy dostępnych testów. Domyślnie pokaże wszystkie testy. Użyj opcji --batch,
--interactive, --batch-experimental, --interactive-experimental, --utils opcje
pokaż te konkretne testy.

--show-tests-full
pokaż wszystkie dostępne testy wymienione według mniejszego opisu testu. Domyślnie pokaże
wszystkie testy. Użyj opcji --batch, --interactive, --batch-experimental,
--interaktywno-eksperymentalne opcje pokazania tych konkretnych testów.

--show-testy-kategorie
pokaż wszystkie dostępne testy i kategorie, do których należą.

--skip-test=test[,test..]
określ testy, które chcesz pominąć i nie uruchamiać. Lista musi być oddzielona przecinkami.

--stdout-podsumowanie
wypisz SUCCESS lub FAILED na standardowe wyjście po zakończeniu testów.

-T, --ścieżka-tabeli=ścieżka
określ ścieżkę zawierającą tabele ACPI. Tabele te należy nazwać w pliku
format: nazwatabeli.dat, na przykład DSDT.dat, na przykład wyodrębniony za pomocą
acpidump lub fwts --dump, a następnie acpixtract.

-ty, --narzędzia
uruchomić narzędzia. Zaprojektowany do zrzucania informacji o systemie, takich jak tabele ACPI z adnotacjami,
Pamięć CMOS, mapa pamięci Int 15 E820, dane oprogramowania ROM.

-v, --wersja
wyjściowy numer wersji i data kompilacji racja narzędziem.

-w, --szerokość=N
określ szerokość w znakach wyjściowego pliku dziennika. Wartość domyślna to 130.

PRZYKŁADY

Uruchom wszystkie testy wsadowe i dołącz wyniki do domyślnego dziennikaresults.log:
sudo fwts

Uruchom wszystkie testy interaktywne i rozpocznij czysty dziennik wyników o nazwie interaktywny.log:
sudo fwts -i -f -r interaktywny.log

Uruchom wszystkie testy, interaktywne i wsadowe:
sudo fwts -i -b

Uruchom tylko testy baterii i cpufreq:
sudo fwts bateria cpufreq

Uruchom wszystkie testy wsadowe i zdefiniuj nowy format dziennika, używając tylko daty i numeru wiersza:
sudo fwts --log-format="%data%linia: "

Uruchom wszystkie testy interaktywne i zarejestruj tylko wyniki, informacje i dane podsumowujące:
sudo fwts -i --log-filter=RES,INF,SUMA

Zrzuć wszystkie interesujące informacje o oprogramowaniu do plików dziennika w celu późniejszej analizy:
sudo fwts --dump

Wyświetl wersję jądra i sterownika ACPI oraz informacje o systemie BIOS:
sudo fwts -w 80 -r wersja standardowa bios_info --log-filter=INF --log-format=""

Pokaż testy eksperymentalne wsadowe i wsadowe:
fwts --show-tests --batch --batch-experimental

Uruchom wiele testów S3 z opóźnieniem pomiędzy każdym testem od 1 sekundy do 10 sekund
z deltą opóźnienia na test wynoszącą 0.2 sekundy
sudo fwts s3 --s3-multiple=100 --s3-min-delay=1 --s3-max-delay=10
--s3-delta-opóźnienia=0.2

Korzystaj z fwts online, korzystając z usług onworks.net