HEADER7F / PCIe CONSOLE FREE BROWSER PREVIEW

Linux evidence workflow · Free preview

DMA stalled?
Follow the evidence.

PCIe addressing and DMA stalls on Linux.
Connect device context with reported faults, find the gaps, and choose your next check.

Browser-local analysis. Optional Linux collector. Your evidence stays here.
7FLinux PCIe workbench ADDRESSING → DMA → NEXT CHECKv0.4

01 / LINUX INVESTIGATION

Find the next PCIe check.

Card absent, link below expectation or DMA stalled? Import the Linux evidence you have and see the next check, with its limits.

SYNTHETIC WALKTHROUGHS
Bring your Linux evidenceEXAMPLE DATA

Run the metadata collector for one device, review its JSON, then import it here. Add relevant log lines if you have them. Analysis stays in this browser.

One selected device · JSON up to 1 MiB · schema header7f.linux-evidence.v1. Editing JSON keeps your separately pasted logs; review or clear those logs when changing devices.

Up to 256 KiB (262,144 UTF-8 bytes). Review before pasting: logs can contain private information. A reported fault is associated only with the selected device address. Upstream counters are shown separately. Empty logs do not prove that DMA works.

Get the Linux collector

Current preview: evidence checks run locally using defined rules. “Copy for ChatGPT” copies a reviewable investigation to your clipboard; it does not connect an AI account or send data.

LINUX PCIE. A REPRODUCIBLE START.

Collect context.
Keep control.

Collector v0.2 captures device identity, host resources, current and maximum link values, AER counters and upstream context. If the target is absent, it still exports the captured PCI inventory.

Download collector
  1. Find the device or expected slot

    Use your inventory or lspci -D. If the card is absent, use its expected or previous BDF and compare the returned tree with platform documentation. An old BDF may change.

  2. Review and run the collector on Linux
    python3 header7f-linux-capture.py 0000:01:00.0 > capture.json

    Replace the address with your device. Python 3 is required. No installation or extra packages are needed. Default capture reads sysfs metadata, makes no network calls and does not require sudo; inaccessible fields remain unknown.

    If an absent card’s port is known, supply it explicitly:

    python3 header7f-linux-capture.py 0000:01:00.0 --upstream 0000:00:01.0 > capture.json

    The supplied port is labeled as user-provided, not a verified endpoint connection.

  3. Import and add relevant logs

    Review capture.json, import it above, and optionally paste time-bounded PCIe AER, IOMMU or driver messages. Compare both link partners and a known-good capture before calling a lower current link value a failure.

Run the same investigation in CI

Download the local CLI bundle and instructions. Unzip the modules together. Node.js 22 or newer is required; no account or network connection is used.

node header7f-investigate.mjs linux capture.json --json investigation.json --markdown investigation.md

Exit 1 means a modeled attention condition; 2 means incomplete evidence without that condition; 3 rejects invalid input. A zero exit is limited to selected checks and never proves hardware health or DMA completion. Existing output files are protected unless you explicitly choose to replace them.

Optional configuration capture

After checking that configuration reads are suitable for the device, add --include-config to request up to 4,096 PCI configuration bytes. Permissions can limit coverage; partial captures remain partial. The Console decodes only the bytes actually read. No BAR/MMIO memory is read.

python3 header7f-linux-capture.py 0000:01:00.0 --include-config > capture.json
Exactly what the collector reads

Bounded sysfs identity, driver/IOMMU links, resources, interrupt assignments, current/maximum link attributes, AER counters and a PCI inventory. Upstream/bridge-candidate captures contain identity, link and AER context. PCI config bytes are read only with the explicit option above. The collector does not read BAR memory, RAM payloads or kernel logs, change settings, execute shell commands or run transfer tests. Redirecting output creates the JSON file you choose.

Resource allocation does not establish address accessibility. An IOMMU group does not establish a DMA mapping; interrupt assignments do not establish delivery. AER counters are cumulative observations at their reporting device. Completion traces and buffer contents require additional instrumentation.

FROM THE BENCH TO AN ANSWER

Need the register view?
Inspect a config capture.

Use the supporting capture tools to inspect standard PCI fields and compare a working state with a changed one.

1. Capture one device on Linux

Find its address with lspci -D, then capture the config space for that device:

sudo lspci -D -s 0000:01:00.0 -xxxx

Replace the address with your device’s address. The shown -xxxx requests up to 4 KiB so extended capabilities such as AER can be decoded when present and readable. A 256-byte -xxx dump cannot include them. Some devices react poorly to config reads; use an existing dump or check your device documentation first. See the lspci manual .

2. Paste, decode, compare

Paste the hex rows for one device. Missing bytes remain unknown. To investigate a change, compare a known-good capture with one taken after the problem appears. Compare the same device and capture method.

3. Share the evidence

Export a Markdown report or JSON for your issue tracker. Reports include observed values, offsets and limitations. A capture cannot establish root cause, prove DMA performance or reveal a vendor-specific LTSSM state.

What works today?

Linux device metadata import, selected-device reported IOMMU faults, resource allocation context and evidence-gap guidance; plus PCI config decoding, comparisons, CSV config-space maps and local config snapshots. The downloadable metadata collector runs separately. The same saved-file checks are available through the local CLI. No live connection, AI account connection, hardware writes or subscription billing is included. The separate Projects preview supports explicit private QDMA bundle saves.

THE PROBLEM WORTH PAYING TO SOLVE

Stop rebuilding the story
every time a board fails.

When a DMA transfer stalls, the team needs a reproducible account of the device, its address setup and the reported faults. Saved board context, repeatable checks and evidence shared across firmware and driver teams are the paid workflow we’re building toward.

01 / BRING-UP

Know where you started.

Keep the working state next to the board and firmware version that produced it.

02 / REGRESSION

Catch what changed.

Compare the next build against an agreed baseline, with expected differences separated from surprises.

03 / HANDOFF

Send evidence, not guesses.

Give the firmware engineer, driver team or supplier one clear report to investigate.

START FREE. SHAPE WHAT COMES NEXT.

A useful tool today.
A shared lab tomorrow.

The browser preview is free. Pro is a proposed service; team engineering is quoted after scope. One pricing page describes the current offer. No payment is collected.

AVAILABLE NOW

Free Console

$0 / browser preview

Investigate Linux evidence. Compare captured state.

  • Linux metadata & reported fault checks
  • PCIe config decode & error flags
  • Before / after snapshot comparisons
  • CSV named fields & report exports
  • Snapshots saved in this browser
Open the free workbench
PROPOSED · IN DEVELOPMENT

Team pilot

Scoped quote / after requirements

Keep the team on the same working state.

  • Everything proposed for Pro
  • Shared boards, baselines & maps
  • Read-only Linux agent workflow
  • Team roles & activity history
Discuss a team pilot

BUILD IT AROUND YOUR BENCH

Where does your
DMA investigation stall?

Tell us about the recurring addressing or DMA failure. We’ll respond about fit and scope. Early access is an enquiry, with no payment or purchase commitment.

Please leave out raw dumps and proprietary details. We use this to respond to your request. Privacy notice.