A bring-up report rarely names the mechanism. It says 'wrong value', 'core hung' or 'it got slow'. This table turns each symptom into a short list of mechanisms taught in this course and the first piece of evidence that tells them apart. It is illustrative: real designs add their own mechanisms, and the first evidence depends on the observability your design provides.
Symptom | Likely mechanisms | First evidence to collect | Rule out first |
|---|---|---|---|
Stale read: a load returned an older value | Missed Inv, grant before Inv-Ack, memory answered while dirty, lost writeback, late Data installed after Inv (Stale-Data Triage); missed load replay (Ordering Bugs) | Messages for the line in H's order, with the Data record that supplied the reader's value | An outcome the memory model allows |
Hang at one address | Lost message, an Inv or Fwd held in a transient state whose Data is blocked, a pending entry never freed because a response carried the wrong transaction id (Hang Triage) | H's pending entry and every cache's MSHR for that line, plus queues on the path | A slow but moving queue: dump twice |
Hang across many addresses | Resource or credit cycle, responses sharing a buffer with requests, a missing virtual network (Message Classes and Virtual Networks) | Occupancy and credits of every queue and pending table, and which message classes share each buffer | One stuck line blocking a shared queue (follow its chain first) |
Performance cliff | False sharing, a hot line or lock, directory or filter evictions causing back-invalidations, a retry storm | Per-line counts of Inv, Fwd-GetM and retries, and directory eviction counts, over the slow window | A change in workload or memory placement |
Machine check or protocol error report | A message illegal in the receiver's state (Inv-Ack with no pending entry, Data with no MSHR), an error-correcting code (ECC) error in tags or directory, a watchdog report | The report's line address, message type, receiver state and transaction id | A transient electrical error: does it repeat at the same line and state? |
Lost update on an atomic | Reservation not cleared on Inv or Fwd-GetM, a read-modify-write that did not keep the line exclusive (LR/SC and Reservations) | The reservation or lock state for the line, and any Inv or Fwd-GetM between the read and the write | Software that used a plain load and store instead of an atomic |
Illustrative report: a loop where C0 updates one word of X's line and C1 updates a different word of the same line ran much slower on silicon than expected. No value is wrong. Per-line counters over the slow window show a Fwd-GetM for X's line on almost every iteration from each side, and no directory evictions. Every store needs exclusive permission for the whole 64-byte line, so the line moves between C0 and C1 for each store: false sharing. The evidence that decides it is the per-line count and the two different word offsets, not the slowdown itself. See Finding False Sharing.
Had the counters shown many directory evictions instead, the suspect would be Sparse Directories and Eviction or Filter Eviction and Back-Invalidation. Had there been many retries with no completions, a livelock. Had both cores updated the same lock word, a hot line.
A duplicated Inv-Ack (sent twice, or H sent the Inv twice), or an entry freed too early, for example because a grant was sent before this ack (the grant-before-Inv-Ack class). The capture separates them: count the Invs H sent for the transaction id, and check whether H's grant came before the ack.