[No Commit] Investigating B200 CI: expand NVIDIA state dump and add CUDA-check retry#3018
[No Commit] Investigating B200 CI: expand NVIDIA state dump and add CUDA-check retry#3018AmesingFlank wants to merge 2 commits into
Conversation
…UDA-check retry
Nightly on 2026-07-08 lost all 18 B200 jobs to two failure modes: 11
tripped the CUDA Compute Check with a bare 'CUDA unknown error' and 7
never got past docker network create ('all predefined address pools have
been fully subnetted') on host dgxb200-03. The CUDA-check log only tells
us torch.cuda.is_available() returned False; we cannot tell which of
UVM/fabric-manager/env is the actual culprit.
Adds diagnostic-only wiring so the next occurrence self-documents:
- 'Run NVIDIA command' now dumps /dev/nvidia*, nvidia kernel modules,
NVIDIA_/CUDA_ env vars, and the fabric-manager socket alongside
nvidia-smi.
- 'CUDA Compute Check' now wraps torch.cuda.init() to print its
traceback (currently swallowed as a UserWarning), then retries once
after 15s and dumps device state on failure. The retry also covers
the observed pattern where the same host succeeded yesterday and
failed today, which points at a transient host-side race.
No behavior change on healthy runners. Runners info + benchmark
metadata are captured at the end of the job unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`test.yml` runs on every PR and lands B200 jobs on the same `linux.dgx.b200` pool that the benchmark workflow does — the previous commit's diagnostics only touched `benchmark.yml`, which isn't `pull_request`-triggered, so those changes never actually executed. Duplicating the two step bodies into `test.yml` (the only PR-facing workflow that hits NVIDIA runners) means every PR push exercises the new state dump and retry. Skipped the `test-notebooks` job's `Run NVIDIA command` since it lives on `linux.g5.4xlarge.nvidia.gpu` (A10G), which is a different pool and unaffected by the current B200 fleet issue. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Extended this PR to mirror both diagnostic edits into Also closed #3019: the host-probe workflow was Skipped the second |
Summary
CUDA Compute CheckwithCUDA unknown error, 7 atInitialize containerswithall predefined address pools have been fully subnetted. Docker-network failures are localized to a single host (dgxb200-03); the CUDA failures spandgxb200-04anddgxb200-05.torch.cuda.is_available()returned False. We cannot see whether UVM device nodes are missing, fabric-manager socket is down,CUDA_VISIBLE_DEVICESgot clobbered, or something else. This PR expands the pre-check state dump and wraps the check with a retry + failure forensics so the next occurrence self-documents.[No Commit]title is intentional; this is meant to keep ondiag-b200-cudauntil we have signal from a nightly run.What changes
Run NVIDIA command: dumps/dev/nvidia*,nvidiakernel modules,NVIDIA_/CUDA_env vars, and the fabric-manager socket next tonvidia-smi. Runs before the CUDA check so we get the state even when the check fails.CUDA Compute Check: callstorch.cuda.init()explicitly and prints the traceback (currently silenced as aUserWarning), retries once after 15s, and dumps/dev/nvidia*+nvidia-smibetween/after attempts. The retry also covers the observed pattern where the same runner host succeeded on 2026-07-07 and failed on 2026-07-08 — a transient host-side race is a plausible cause.Test plan
yaml.safe_load)-nsyntax check on both step scripts passes (heredoc terminator lands at column 0 after YAML normalization)benchmark_dispatchon B200 to prove the diagnostic wiring executes cleanly on a healthy runner🤖 Generated with Claude Code