FWTS(1)

📦
version 26.09.00 · 2 versions
, in fedora 44, nixpkgs unstable, ubuntu resolute, ubuntu stonking

💖 FWTS — the firmware test suite, bestie edition 💖

okay so you found fwts and you're like "what is this" and I'm here to tell you: this is the firmware test suite, and it's about to identify firmware bugs like it's got a personal vendetta (affectionate). it's from the General Commands Manual, section 1, and it's genuinely iconic. sit down, grab a strawberry 🍓, let's get into it.

🌸 NAME 🌸

fwts — a firmware test suite to identify firmware bugs. periodt. that's the whole job. 💅

✨ SYNOPSIS ✨

fwts [options] [test(s)]

like... you give it some options, you give it some tests, and it goes off. that's the vibe.

🦋 DESCRIPTION 🦋

okay so this manual page documents briefly the fwts firmware test suite. and when I say suite, bestie, I mean it — fwts is made up of over 150 tests designed to examine and test different aspects of PC firmware. over a hundred and fifty. that's not a test suite that's a whole test situation.

many of these tests need superuser access to extract tables and interact with the firmware and ACPI, so running fwts using sudo is required. like, required required. not optional. 🙈

running fwts with no options will run through all the batch tests that require no user interaction. however — and this is the fun part — you can select just specific tests to run if required. choose your own adventure, bestie. 🎀

by default fwts outputs the test results into the log file results.log. however, a different log file name can be specified, and if required, output to stderr or stdout can be selected. options on options.

⚠️ note that there are a variety of tests, including tests that can potentially hang a machine (such as a suspend/hibernate/resume). not me risking it all for the diagnostic data 😭. this is your heads-up, okay? these tests are not playing.

👑 OPTIONS 👑

fwts options are as follows:

  • - — output results to stdout. just a whole lonely little dash. it's giving minimalism.
  • --acpica — enable ACPICA execution mode options. these can be specified as a comma separated list of one or more options. available options are: serialized (serialized execution of AML), slack (run in less pedantic mode), ignore-errors (ignore ACPICA exception errors), disable-auto-repair (disable ACPICA from automatically fixing broken ACPICA controls). note that the slack mode will turn on implicit returns of zero on control methods to attempt to allow buggy AML to work on non-Windows systems. slay in the "tolerant" sense.
  • --acpica-debug — enable ACPICA debug warning and error messages when invoking the ACPICA subsystem. this is mainly for fwts developers to help track down any ACPICA interfacing issues with fwts. iykyk.
  • --acpicompliance — run only those tests that specifically check for compliance with the ACPI specifications. this may be a subset of the ACPI tests. ✨
  • --acpitests — run all general ACPI tests. all of them. the whole general ACPI buffet.
  • -a, --all — run all the tests. every single one. main character energy, no notes.
  • *--arch=name* — specify the target architecture whose firmware is being tested. this allows fwts to run on one architecture (the host) but perform tests for a different architecture (the target). known architecture strings are: x86, x86_32, or x86_64 for Intel; ia64 for Itanium; arm64 or aarch64 for ARMv8. unless this option is specified, the target is assumed to be the same as the host.
  • -b, --batch — run the non-interactive batch tests. batch tests require no user interaction. they just go. 🫶
  • --batch-experimental — run only batch experimental tests. experimental batch, the spicy subsection.
  • --clog — specify a coreboot logfile dump.
  • --disassemble-aml — disassemble AML (ACPI machine language) byte code. this attempts to disassemble AML in DSDT and SSDT tables and generates DSDT.dsl and SSDTx.dsl sources. it's giving reverse-engineering chic 🔥
  • -d, --dump — extracts firmware data and dumps it into log files. this generates:
    • acpidump.log — containing a hex dump of the ACPI tables (which can be read using acpixtract).
    • dmesg.log — containing the current kernel log messages.
    • dmidecode.log — containing the output from dmidecode.
    • lspci.log — containing the output from lspci -vv -nn
    • cpuinfo.log — containing the output from cat /proc/cpuinfo
    • README.txt — containing a timestamp and kernel version information.
  • --dump-acpi-from-sysfs — specify dumping acpi table log default from sysfs.
  • --dumpfile=acpidump.log — load ACPI tables from output generated from acpidump or from sudo fwts --dump. the latter is preferred as fwts --dump is able to dump more tables than acpidump. this allows one to dump tables from one machine and processes them with fwts on another machine. machine-hopping, we love to see it 🌈
  • --ebbr — run ARM EBBR tests.
  • --uefi-get-var-multiple — specifies the number of times to get a variable in the uefirtvariable get variable stress test.
  • --uefi-set-var-multiple — specifies the number of times to set a variable in the uefirtvariable set variable stress test.
  • --uefi-query-var-multiple — specifies the number of times to query a variable in the uefirtvariable query variable stress test.
  • --uefitests — run all general UEFI tests.
  • --filter-error-discard — specifies the errors that one wants to silently ignore. one supplies a comma separated list of fwts error message labels that one wants fwts to not report as errors. fwts will run the test but if there is a test failure and the label matches the one supplied in this list fwts will then just ignore this error. this cannot be used with --filter-error-keep.
  • --filter-error-keep — specifies the errors that one wants to keep, all other errors are silently ignored. one supplies a comma separated list of fwts error message labels that one wants fwts report as errors, other test failures will be not reported and silently ignored. this cannot be used with --filter-error-discard.
  • -f, --force-clean — creates a new results log file, rather than just appending to any existing one (default). fresh start energy 🧚
  • -h, --help — outputs the internal help page. the classic.
  • -i, --interactive — run the interactive tests. these tests require user interaction. it needs you, bestie. 👑
  • --ifv — run tests in firmware-vendor modes.
  • --interactive-experimental — run only interactive experimental tests.
  • -j, --json-data-path — specifies the path to the fwts json data files. these files contain json formatted configuration tables, for example klog scanning patterns.
  • *-k, --klog=file* — read the kernel log from the specified file rather than from the kernel log ring buffer. this allows one to run the kernel log scanning tests such as klog against pre-gathered log data. pre-gathered. prepared. ahead of schedule. we stan a planner.
  • --log-fields — show the available log filtering fields. specifying these fields with --log-filter to select which fields one wants to log.
  • --log-filter — specify which particular types of log data to be output into the log file. each line of log data is tagged with a special marker depending on what type of log information is being output. the available types can be see by using --log-fields. specify the desired log types with comma separated list. to disable a field, prefix the name with ~, for example:
    • --log-filter=RES,SUM logs just the results and summary lines.
    • --log-filter=ALL,~INF logs all lines except for the information lines.
  • --log-format — specify the information in each log line. the following specifiers are available:
    • %date — date
    • %time — time
    • %field — log-filter fields
    • %owner — name of the test routine
    • %level — test failure level
    • %line — log line

e.g. --log-format="%date %time [%field] (%owner): "

  • --log-level [critical|high|medium|low|info|all] — specify the test failure level to log. test failure levels equal to and higher than the specified are logged and recorded as failures. the default is 'all' (which is identical to 'info'). for example, a log level of 'medium' will just log test failures of level 'medium', 'high' and 'critical', where as a log level of 'critical' will just log 'critical' level failures. it's giving tier list 📊
  • --log-type — specify the log type. currently plaintext, json and xml log types are available and the default is plaintext.
  • *--lspci=path* — specify the full path and filename to the lspci binary.
  • -P, --power-states — run S3 and S4 power state tests (s3, s4 tests). we love a power nap 😴
  • --results-no-separators — no pretty printing of horizontal separators in the results log file. minimal. austere. still valid.
  • *-r, --results-output=filename* — specify the results output log file. one can also specify stdout and stderr to redirect to these output streams.
  • *-R, --rsdp=physaddr* — specify the physical address of ACPI RSDP. this is useful on some systems where it cannot be automatically detected.
  • *--pm-method=method* — specify the power method to use to enter S3 or S4 (or autodetection will be used). the following specifiers are available:
    • logind — the default method, where available (requires dbus and logind).
    • pm-utils — the previous default method, now deprecated.
    • sysfs — the fallback, used when logind is not available.

e.g. --pm-method=sysfs

  • --s3-delay-delta=N — time to be added onto delay between each S3 iteration.
  • --s3-device-check — check differences between device configurations over a S3 cycle. note this adds 15 seconds delay after each s3 resume to allow wifi to re-associate.
  • --s3-device-check-delay — specify the time to wait while devices re-configure (e.g. wifi to re-associate, ethernet to connect..) before a device configuration check is run. the default is 15 seconds. if this option is used the device checking is assumed so one does not also need to use the --s3-device-check flag.
  • --s3-hybrid — enables fwts to run Hybrid Sleep.
  • --s3-min-delay=N — minimum time between S3 iterations.
  • --s3-max-delay=N — maximum time between S3 iterations.
  • --s3-multiple=N — specify the number of multiple S3 suspend/resume tests to run. the default is 2 tests.
  • *--s3-resume-hook=hookscript* — specifies a script or program to run after each S3 resume. the hookscript must return 0 to indicate success, or non-zero to indicate failure. failures will abort subsequent S3 test iterations. no pressure on your script, but like, there is pressure 😭
  • --s3-quirks=--quirk[,--quirk] — specify a comma separated list of quirk arguments to pass to pm-suspend, for example: --s3-quirks=--quirk-s3-bios,--quirk-save-pci
  • --s3-sleep-delay=N — sleep N seconds from the start of the suspend to the wakeup time. note that this time MUST be longer than the time it takes to suspend the machine otherwise the wakeup timer will fire during the suspend state. the default is 30 seconds. this one is loud for a reason bestie, read it twice. 💀
  • --s3-suspend-time=N — specify the maximum allowed suspend time in seconds. if suspend takes longer than this then an error is logged.
  • --s3-resume-time=N — specify the maximum allowed resume time in seconds. if resume takes longer than this then an error is logged.

more coming in part 2, don't go anywhere 💜

  • --s3power-sleep-delay=N — sets how long we snooze in suspend, in seconds. The bigger the number, the more accurate the s3power test result gets. Anything under 10 minutes? Not recommended, bestie. Like, it'll run, but don't come crying to me about your numbers.
  • --s4-delay-delta=N — the amount of time tacked onto the delay between each S4 iteration. Little increments, one at a time. 💅
  • --s4-device-check — peep the differences between device configurations over one whole S4 cycle. 👀
Heads up: this adds a 15 second delay after every s3 resume so wifi has a chance to re-associate. Patience is a virtue, etc etc.
  • --s4-device-check-delay — sets the time to wait while devices re-configure themselves (wifi re-associating, ethernet connecting, all that ✨networking✨ drama) before a device configuration check runs. The default is 15 seconds. And lowkey if you use this option, the device checking is just assumed, so you don't also need the --s4-device-check flag. Two birds, one flag. 🦋
  • --s4-min-delay=N — minimum time between S4 iterations.
  • --s4-max-delay=N — maximum time between S4 iterations.
  • --s4-multiple=N — how many multiple S4 hibernate/resume tests you want to run. The default is 2 tests. Choose your own adventure. 🎀
  • --s4-quirks=--quirk[,--quirk] — a comma separated list of quirk arguments to hand off to pm-hibernate. For example: --s4-quirks=--quirk-save-pci
  • --s4-sleep-delay=N — sleep N seconds from the start of the hibernate to the wakeup time.
CRITICAL, no cap: this time MUST be longer than the time it takes to hibernate the machine. Otherwise the wakeup timer fires during the hibernate state and everything gets weird. The default is currently 90 seconds.
  • --sbbr — run ARM SBBR tests. 🫶
  • -p, --show-progress — shows the progress of the tests being run. Every test gets identified as it's being run, so you're never just staring at a blank terminal wondering if it's dead. For long tests, a percentage of completion time gets displayed. As of fwts 0.19.06 this is enabled by default, and you can turn it off with --quiet (or -q). The way it's on by default now… iconic honestly. ✨
  • -q, --quiet — run quietly, with no output to stdout. Shhh. 🤫
  • -D, --show-progress-dialog — outputs the progress of tests being run in a form that can be piped into the dialog tool with the --gauge option. Fancy GUI-adjacent energy. 💅
  • -s, --show-tests — shows the names of available tests. By default it'll show all tests. Use the --batch, --interactive, --batch-experimental, --interactive-experimental, --utils options to show those specific tests instead.
  • --show-tests-full — shows all the available tests listed by minor test description. By default it'll show all tests. Use the --batch, --interactive, --batch-experimental, --interactive-experimental options to show those specific tests. More detail, same slay. 📋
  • --show-tests-categories — shows all the available tests and the categories they belong to. Sorting hat behavior. 🧚
  • --skip-test=test[,test..] — tests you want to skip over and not run. The list must be comma separated. We're not doing that one today, bestie. 🙈
  • --stdout-summary — outputs SUCCESS or FAILED to stdout at the end of the tests. One word. Devastating. 💀
  • -t, --table-path=path — the path containing ACPI tables. These tables need to be named in the format tablename.dat, for example DSDT.dat, for example, as extracted using acpidump or fwts --dump and then acpixtract.
  • -u, --utils — run utilities. Designed to dump system information, such as annotated ACPI tables, CMOS memory, Int 15 E820 memory map, firmware ROM data. All the receipts. 🔥
  • -v, --version — outputs the version number and build date of the fwts tool. Gotta know what you're working with. 👑
  • -w, --width=N — the width in characters of the output logfile. The default is 130.

🌈 EXAMPLES 🌈

Run all the batch tests and append the results into the default log results.log:

sudo fwts

Run all the interactive tests and start a clean results log called interactive.log:

sudo fwts -i -f -r interactive.log

Run all the tests, interactive and batch:

sudo fwts -i -b

Run just the battery and cpufreq tests:

sudo fwts battery cpufreq

Run all the batch tests and define a new log format using just the date and line number:

sudo fwts --log-format="%date %line: "

Run all the interactive tests and log just the results, info and summary data:

sudo fwts -i --log-filter=RES,INF,SUM

Dump all the interesting firmware information into log files for analysis later:

sudo fwts --dump

View kernel and ACPI driver version and BIOS information:

sudo fwts  -w 80 -r stdout  version bios_info --log-filter=INF --log-format=""

Show the batch and batch experimental tests:

fwts --show-tests --batch --batch-experimental

Run multiple S3 tests with delay between each test ranging from 1 second to 10 seconds with a delay delta per test of 0.2 seconds:

sudo fwts s3 --s3-multiple=100 --s3-min-delay=1 --s3-max-delay=10 --s3-delay-delta=0.2

💜 SEE ALSO 💜

iasl(1), acpixtract(1), acpidump(1), dtc(1), dmidecode(8), lspci(8)

Go read those too, they're part of the extended universe. 📚✨

🌸 AUTHOR 🌸

fwts was originally written by Colin King, with much of the original test code derived from the Intel Linux Firmware test kit. Many thanks also for contributions from (in alphabetical order): AceLan Kao, Al Korv, Al Stone, Alberto Milone, Alex Hung, Anthony Wong, Armin Wolf, Björn Esser, Chris Goldsworthy, Chris Van Hoof, David Ward, Deb McLemore, Erico Nunes, Fan Wu, Fu Wei, G Edhaya Chandran, Gergo Koteles, Haibo Xu, Hector Cao, Heinrich Schuchardt, Heyi Guo, Ivan Hu, Jeffrey Hugo, Jeremy Kerr, Jiri Vohanka, Kamal Mostafa, Keng-Yu Lin, Mahesh Bireddy, Mario Limonciello, Matt Fleming, Miao Wang, Monty Zhao, Naresh Bhat, Paul Menzel, Phidias Chiang, Pradeep Gaddam, Prarit Bhargava, Rajat Goyal, Ricardo Neri, Robert Hooker, Rudolf Marek, Sakar Arora, Seth Forshee, Sunil V L, Weizhao Ouyang, Yang Kun, Yi Li and Zhang Rui. Absolute legends, every single one. 🫶👑

This manual page was written by Colin King for the Ubuntu project (but may be used by others). Sharing is caring. 💖

This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Read that again, bestie — NO warranty. Fr fr. 😭

And that's the whole page, the FWTS(1) manual — this copy is dated 7 January, 2026, and it's the fwts page, so you know exactly where to find it again. Go run some tests, you're gonna do amazing. 🎀🦋💅✨

📦 where this page comes from