Message-signalled interrupts use configured memory-write messages rather than a separate asserted interrupt pin. The OS allocates vectors and programs their routing; the driver installs handlers and unmasks the supported interrupt path. MSI-X supports per-vector configuration and masking through its defined table/PBA mechanism. Do not assume the interrupt exists merely because a BAR can be read.
This isolated debug replay assumes a completed DMA operation, valid OS DMA mapping and configured interrupt support. Completion data, device status, the interrupt message and handler execution are separate observation points. The driver must still apply its platform’s DMA and synchronisation contract before consuming results.
MSI/MSI-X: follow the interrupt message after the DMA result — worked trace
Illustrative isolated example; not measured silicon behaviour.
Last confirmed observation | Next evidence | Discriminating question |
|---|---|---|
DMA writes completed at the observed boundary | Completion/status state in the device | Was this operation configured to signal an interrupt? |
Device marks an interrupt pending | Enable/mask and configured destination/message | Is the intended vector masked or misconfigured? |
Interrupt write leaves the device | Interrupt-controller routing / remapping evidence | Did it reach the expected host route? |
Handler runs | Status acknowledgement and result visibility | Did software consume and acknowledge the right operation? |
No. First follow interrupt generation, masking, routing and handler registration. Polling success narrows the failure but does not prove the entire interrupt path.
Start with link history, negotiated capability and error counters. Then correlate credits, request identity, routing, completions and software setup for the failing operation. These observations narrow hypotheses: L0 does not certify every transaction, and a timeout does not by itself identify a defective endpoint. Check reset, enable bits, mappings and permissions as well as the physical path.
Each layer has distinct evidence. LTSSM trace for physical. Credit counters for data link. TLP log for transaction. Config space dump for enumeration.
Correlate one operation instead of assuming a guilty layer
Evidence groups for the same failing PCIe operation; they are hypotheses to discriminate, not a mandatory diagnosis order.
Boundary | Evidence | What a healthy observation leaves open |
|---|---|---|
Link | State history, configured limits, margin and error counters | Request routing, mappings and returned data |
Transaction | Type, requester/Tag, byte range and Completion status | Whether software supplied the intended operation |
Host/device contract | BAR access or DMA mapping, enable bits and ownership | Whether that configured path actually transferred the right bytes |
What to notice
BAR access and device DMA exercise different address/mapping paths.
Use shared identity and observation intervals to join the evidence; no clean row clears all other rows.
No. Mapping and ownership belong to a separate contract row. Follow the same request into its route and Completion/error evidence.