XID 74 NVLink errors on NVIDIA H200 NVL bridges: decode, check the links, reseat, replace

What XID 74 means on an H200 NVL server

XID 74 is the NVIDIA driver's report of an NVLink error: the GPU found a problem on a connection to another GPU. On an H200 NVL server that connection is the NVLink bridge, so the fault sits in the bridge, its seating, the link circuitry of the card or the card at the other end. NVIDIA's XID Catalog says a GPU reset or node reboot is needed to clear it, and NVIDIA's GPU Debug Guidelines decode the error data into a likely hardware issue, a marginal signal or a mechanical problem to re-seat.

The catalogue, updated on 9 September 2026, adds the point that makes 74 tricky: the event "may indicate a hardware failure with the link itself, or may indicate a problem with the device at the remote end of the link". Its example is a failed GPU, after which "another GPU connected to it over NVLink may report an Xid 74 simply because the link went down". So the GPU that logs 74 is not necessarily the faulty one, and the first job is to look at every GPU on the same bridge.

NVIDIA XID Catalog, "Analyzing Xid Errors with the Xid Catalog", updated 9 September 2026, read 24 October 2026. The H200 NVL is a Hopper GPU like the H100.

The applicability columns explain why this article is about one card. Blackwell data-centre GPUs with fifth-generation NVLink report link faults under a separate series of NVLink codes with the action WORKFLOW_NVLINK5_ERR; the catalogue marks 146 to 150, for example, for B100 and GB200 and not for the A100 or H100. Of the cards we supply, only the H200 NVL has NVLink at all; no edition of the RTX PRO 6000 has it, nor do the L40S and L4. An XID 74 is not expected on a server with only those cards; check first that the log comes from the server you think it does. For the other codes see our NVIDIA XID error codes reference.

The NVLink layout of a bridged H200 NVL

NVIDIA's H200 NVL product brief (PB-12128-001_v01, April 2025) lists 18 NVLink links per card and one bridge per card, either a 2-way bridge (900-23945-xx00-xxx) that spans two cards or a 4-way bridge (900-23946-xx00-xxx) that spans four. Bridged cards "should be within the same CPU domain". An eight-card server therefore holds two 4-way sets or four 2-way pairs, and traffic between sets runs over PCIe, as our guide to the H200 NVL NVLink bridge, 2-way or 4-way explains. A card without a bridge keeps the removable cap that protects its NVLink interface.

For troubleshooting, this layout limits the search. A link fault involves only the cards of one bridge, two or four GPUs, and the other sets of the server keep working. It also gives the reference to compare against: the NVLink topology recorded when the server was accepted. If no baseline exists, record one from a healthy set of the same server.

Reading the XID 74 line: the first data word

NVIDIA's GPU Debug Guidelines (GPU node triage, updated 4 October 2026) give the procedure: "Extract the hex strings from the XID error message", then look at the first DWORD, the first 32-bit word, and check which bits are set, counted from the least significant bit.

NVIDIA GPU Debug Guidelines, GPU node triage, Table 1, row Xid 74, read 24 October 2026. SI means signal integrity. The guidelines do not describe other bits.

An example of the arithmetic, by our reading: a first word of 0x00000010 has only bit 4 set (hex 10 is binary 1 0000), so the guidelines count it toward the ECC or parity threshold; a word of 0x00200000 has bit 21 set, a marginal signal. Write the decoded bits into the incident record with the link number from nvidia-smi, because the reporting threshold for bits 4 and 5 counts per link.

Checking the links with nvidia-smi

The nvidia-smi manual documents the nvlink subcommand. Run it on every GPU of the affected bridge, before and after any reset.

NVIDIA nvidia-smi documentation, read 24 October 2026. The last column is our use of the commands.

On fourth-generation NVLink, as on the H200 NVL, the manual names three error counters: "Replay Errors", which "count the number of replay 'events' that occurred", "Recovery Errors", counting "link recovery events", and "CRC Errors" in received packets. A link that shows rising replay or CRC counts on one card and a matching count at the remote end, which -R names by PCI bus ID, points at that pair and the bridge between them. Errors on every link of one card point at that card.

For continuous monitoring, the default field file of dcgm-exporter lists separate "NVLink data-link error counters for Hopper GPUs": DCGM_FI_DEV_NVLINK_CRC_ERROR_TOTAL, DCGM_FI_DEV_NVLINK_RECOVERY_TOTAL and DCGM_FI_DEV_NVLINK_REPLAY_TOTAL, all three commented out. The counters for older GPUs and for Blackwell carry other names, so enable the Hopper set on H200 NVL hosts. Our guide to GPU server monitoring with DCGM covers the alert rules.

We build H200 NVL servers with 2-way or 4-way bridges, assembled and tested before delivery; send us the nvidia-smi nvlink output and the XID line and our team helps you read it.

What a link fault does to a tensor-parallel job

Inside a bridged set, a model runs tensor parallelism over NVLink: TP=2 on a pair, TP=4 on a 4-way set. Since XID 74 is cleared only by a GPU reset or a node reboot, the job on that set stops for the reset whatever it would have done on its own. Plan for a restart of that job.

The reset itself is narrower than a reboot. The nvidia-smi manual states that "Starting with the NVIDIA Ampere architecture, GPUs with NVLink connections can be individually reset", and NVIDIA's GPU Debug Guidelines confirm for Ampere and later with direct NVLink connections on bare metal that "A GPU can be reset individually". The reset requires root and no applications on the GPU, and the manual says it is "not recommended for production environments at this time". In a virtual machine, the guidelines' answer is "GPU reset not supported in VMs. Restart the VM."

On an eight-card server with two 4-way sets, the healthy set carries on. By our reading, three options exist while one set is out:

• move the job to the healthy set, which has the same 564 GB of HBM3e;
• run a smaller copy, or a copy per card, on the healthy cards of the faulty set, which by our sizing rule (0.9 × the 140.4 GiB the driver reports, minus 3 GiB) offer 123.4 GiB each;
• wait for the reset and the checks below, if the job needs all eight cards.

A model sized for both sets with pipeline parallelism has to wait. Our article on one model on several GPUs over PCIe and NVLink explains why tensor parallelism across a PCIe hop is slow.

Reseat the bridge or replace a card

NVIDIA's actions and the counters lead to a decision. The table is our reading of them; the warranty provider decides what counts as a fault.

NVIDIA GPU Debug Guidelines (GPU node triage) and XID Catalog, read 24 October 2026; the cause and step columns combine NVIDIA's text with our reading.

Re-seating a bridge means opening the server, and the server maker sets the procedure. Dell's PowerEdge XE7740 technical guide (Rev. A04, April 2026) installs the 4-way bridge "on the connectors on the top of the H200 GPU PCIe cards" and states: "To prevent damage to the NVLink interface, NVL Bridges must be removed using the NVL Bridge removal tool." It adds "Improper removal without this tool can cause damage" and "Each NVLink bridge requires two removal tools", used at the same time, one on each side. Other makers describe other tools and steps for their chassis, so use the service manual of your server model and the tools it names.

After the re-seat, check every link with nvidia-smi nvlink -s, save and reset the counters with -re, run a load across the set and read -e again. Our acceptance testing guide and the bridge guide describe the all-reduce test per set. If the counters rise again on the same link, a spare bridge of the same part number separates bridge from card: errors that move with the bridge belong to it, errors that stay with one card's links belong to that card. Our article on finding the faulty GPU by bus ID, slot and serial maps the bus IDs to the physical cards.

What to send with a case for XID 74

NVIDIA's GPU Debug Guidelines list the general report: OS and driver details, the key log lines and the full log, the debug steps taken, nvidia-bug-report.sh output and DCGM diagnostics logs, submitted to the system vendor. For NVLink, add what lets the vendor locate the link:

• the XID 74 lines of every GPU on the bridge, with the decoded bits of the first word;
• nvidia-smi nvlink -s, -e and -R output from every GPU of the set, saved before any counter reset;
• the link number, the remote PCI bus ID and the serial numbers of both cards;
• the bridge type and part number, 2-way 900-23945 or 4-way 900-23946, and whether it was re-seated;
• the server model, BIOS, BMC and VBIOS versions.

The guidelines call NVIDIA's field diagnostic "the authoritative and comprehensive NVIDIA tool for determining the health of GPUs" and says it "is usually required before an RMA can be started"; the system vendor says when to run it. For the H200 NVL cards and bridges we supply, the manufacturer warranty is handled through us; describe the server and the link that fails and we reply within one business day.

Before the next order: bridges, slots and spares

Much of the risk is settled when the server is built. The bridges are separate parts that the server maker qualifies per model; HPE's QuickSpecs of 8 September 2026, as cited in our bridge guide, list the 4-way bridge for the ProLiant DL380a Gen12 only, and our guide to H200 NVL compatible servers lists which servers take which bridge. A server planned for 4-way sets is best laid out with four adjacent cards under one processor, as NVIDIA's brief recommends, and the removal tools belong with the server documentation. For a fleet of bridged servers, a spare bridge of each type in use shortens the isolation step above. Our eight-card H200 NVL server page describes the training node we build with two bridged sets.

FAQ