The previous lessons give three outcomes. A corrected error changes nothing visible. An uncorrectable data error can be contained as poison, so only its consumer is affected. An uncorrectable metadata error is recoverable only if the metadata can be rebuilt from answers the protocol can collect; otherwise nothing guarantees that the next grant is safe, and the system has to stop the affected work, which in the worst case means a machine check and a reset. All RAS terms on these pages are generic (corrected error, detected uncorrectable error, poison, machine check, containment). No vendor's error-record format is described, and every number is illustrative.
Class | Example | What the system does | Effect |
|---|---|---|---|
Corrected | Single flip in a data word, tag or directory entry, fixed by SECDED | Use the corrected bits, write them back if the design scrubs, log a corrected error | Transparent to software |
Detected, clean copy | Double flip in an S line (MSI, MESI: memory current), or a tag parity error on a clean line | Drop the copy, refetch from memory on the next access | Transparent, at the cost of a miss |
Detected, data, no clean copy | Double flip in an M line, or in memory | Poison the line, keep coherence running | Contained: only a consumer gets an error |
Detected, cache state, tag intact | A cache's state bits for X uncorrectable (cache state recovered from H's entry) | Ask H: exclusive for this cache means write back with PutM if the data passes ECC, otherwise poison; sharer or not recorded means drop the line | Transparent, or contained as poison |
Detected, metadata, rebuildable | Directory entry uncorrectable, all caches answer | Freeze X, recall every possible holder, rebuild | Transparent, slow |
Detected, metadata, not rebuildable, address known | Lost entry and the dirty holder will not answer | Poison the line in memory, report | Contained to consumers of that line |
Detected, not rebuildable, address unknown | A dirty line's tag failed, or a directory tag failed | Cannot locate what is wrong: machine check | Fatal for the affected scope, often a reset |
Detected, in-flight transaction state | An MSHR's or pending entry's requester, ack count or data-valid flag failed | The transaction cannot be completed safely: machine check | Fatal for the affected scope |
Undetected | Flip beyond the code's strength, or an unprotected structure | Nothing: the system does not know | Silent data corruption or a coherence violation |
Apply it to the earlier traces. The lost sharer bit of the first lesson, if SECDED catches one flip, takes the 'Corrected' leaf and nothing happens. The poisoned dirty read takes Data, no clean copy, poison; C1's load takes the consumer leaf. The recall of the previous lesson takes Metadata, address known, no in-flight state lost, every holder answers: rebuilt. The same entry with C0 powered off takes the poison-in-memory leaf.
Containment means the error reaches as few consumers as possible and never becomes a silent wrong value. Poison contains a data error to the context that loads it; the operating system can then end that one process if the data was private to it, or usually has to stop the whole system if the consumer was the kernel itself. The coherence hardware does not choose that; it only has to deliver the error to the right consumer, with the address, synchronously with the load.
Every detected error, corrected or not, is reported to firmware or software with at least: the structure, the address if known, corrected or uncorrected, and whether poison was created. Corrected errors matter too: a rising count in one array suggests a weak cell, and a scrubber that reads and rewrites lines in the background fixes single flips before a second flip in the same word turns them into an uncorrectable error. Reporting is a log, not a stop: it must not block the coherence path.
Because C1 no longer knows what has already happened. H may have granted M and sent Data that C1 has or has not used; resending could start a second transaction that H treats as a new request from a cache it already records as exclusive. The transaction state is the only record of where the newest data and the permission are, so the flowchart's 'in-flight transaction state lost' leaf applies.
Every recovery action, recall or poison, names a line. If a directory tag or a dirty cache line's tag is corrupted, the hardware does not know which line's permissions or data are wrong, so it can neither rebuild nor poison the right one. Only escalation is safe.