The Test Matrix

A personal computer is several machines sharing one case. The same chassis holds a memory subsystem, a compute subsystem, storage, and a sensor chain, and almost no test loads more than one of them at a time. That is why a test matrix exists: it maps each row of the stack against the load that reaches it, so a result is read against a stated claim, not a feeling.

This page lays the matrix out once. The table is the short version. The sections after it say where each row ends, because a result read past its row is how a clean run gets over read.

No load touches everything

A memory pattern never opens a drive. A prime-number workload never negotiates a memory timing. A sensor reading is not a load at all; it is a report from a chip that was running anyway. Every tool on this desk reaches a subset of the machine, and the subset is the claim. A pass means the tested part held under that test, in those conditions, and it transfers to nothing outside the subset.

Which test reaches which subsystem?

Four rows cover most bench questions. Read the table by row, not by column: each row states what reaches the subsystem, what a clean run says, and where the row stops talking.

One property travels with the whole table. A clean cell records an absence of detected error, not a certification of stability. Nothing on this desk certifies that, because nothing can: a machine is stable against a load, never in the absolute.

The row that runs before the operating system

Memory is the one subsystem with a test that refuses to trust the machine it is auditing. A stand-alone memory tester boots its own small environment instead of running inside the operating system under suspicion. The Memtest86+ project page states its terms plainly: a free, open-source, stand-alone tester for IA-32, x86-64 and LoongArch64 systems, released under GNU GPL v2. On x86 machines it loads directly from a legacy BIOS or from UEFI, or through an intermediate bootloader that supports the Linux boot protocol. The project also states, as its own claim, that its check is more thorough than the memory test built into a BIOS.

Scope, from the same page: any Pentium-class or later 32-bit x86 CPU, any 64-bit x86 CPU, and supported Loongson LA64 systems. A naming trap sits here. Memtest86+ is not an edition of Memtest86, which since 2013 has been closed-source freemium software owned by PassMark Software. A guide that says "run MemTest" without naming the plus line has pointed at a different program.

The current v8.10 changelog reads as platform work: support for x2APIC, better Intel Panther Lake support, fixes to LPDDR5 timings, to AMI BIOS and GRUB boots, to SecureBoot code for shim. When a testing tool's changes are mostly platform edges, its patterns have long since settled; choose a release accordingly. The nightly builds are generated automatically each night, and the project's own page labels them fully untested. Booting one inverts this matrix, because the least-tested component in the machine would be the tester itself. The desk's page on what a pass covers takes that reading further.

What does a compute load actually load?

The compute row is where documents and bench practice diverge, and the matrix says so. The GIMPS download page documents a prime-search client: Prime95, free, for Windows, Linux, FreeBSD and Mac OSX, version 30.19 build 20 at consultation, built to donate spare processing power to the search for Mersenne primes. The page says nothing about stress testing; that is not what it is for. Practice picked the workload up anyway: a long, purposeful computation keeps cores busy in a way an idle desktop never does. Both statements hold at once, and the matrix keeps them apart. The document says search, the bench says load, and what a stress test proves is only ever the second thing.

Two rows you read instead of run

Storage and sensors break the matrix's pattern, and the break is the lesson. Nothing external exercises either one during a diagnosis. The storage row is the drive reporting on itself, and a clean bill there is the firmware's own accounting, counted in units the vendor defined. The desk's page on reading the drive's own report covers which of those numbers carry weight.

The sensor row is stranger: it is not a test, only a consultation. The Linux kernel documents hardware monitoring as a subsystem with its own index in the kernel documentation tree; what reaches the desk is what the driver chain for a given chip reports. The smartmontools page, consulted for this desk on September 5, 2026, served a connection check and no content, so nothing in this row rests on it. A source that cannot be read is not a source yet.

Where does the matrix go quiet?

Between the rows. Each result carries its conditions inside it, and the conditions do not travel. Memory verified at one temperature says nothing about memory at another, because temperature was part of the claim, not background. Compute held for one duration does not amortize into storage. The matrix's blind spot is not inside any row; it is the diagonal, the faults that need two subsystems at once, a warm case, a late hour of a long run. No single-row result closes those, and a bench that forgets it calls machines stable on evidence that never covered the question.

Write yours before the machine lies to you

The gesture this page asks for is small. Before the next sick machine arrives, draw the four rows on paper and add two columns of your own: the symptom as first described, and the row it points to. When the machine shows up, run that row first and nothing else, then write beside the result the conditions the matrix demands: tool version, duration, temperature at the start and at the end, slot order if the row is memory.

One row at a time, conditions beside the result. Kept that way, the matrix turns a folder of hunches into a record, and the next unstable machine inherits the record instead of the hunches.