Incident Library
Applied filters ComponentGPU hardware and memoryOrganisationBigScienceClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases1 case

1 to 1 of 1

  1. Symptoms

    After many hours of training, one job of the tr1-13B Slurm job array crashed at iteration 43680 of 311541 during the backward pass. The next job in the array started by itself and crashed right away, before training began.

    Trigger

    One GPU on one node of the allocation developed a hardware problem that produced uncorrectable ECC errors.

    Root cause
    Component
    Contributing factor
    Detection

    Nobody was around to notice the first crash, and the Slurm scheduler started the next job in the array on its own, which crashed too.

    Remediation
    • Contacted the JZ administrators, who confirmed one of the nodes was faulty
    • Continued training with the next job, which was not placed on the faulty node
    Action items
    • Add %N to the Slurm output setting (#SBATCH --output=%x-%j-%N.out) so each node writes its own log file and the node with a corrupt GPU can be identified
    • Exclude a node known to be faulty from the allocation with sbatch --exclude
    Lessons

    Without a way to link an exception to the hostname of the node that raised it, the scheduler can keep placing the training on the faulty node and the training keeps crashing; per-node log files make the faulty node visible so it can be excluded.

Check your cluster for this

This case involves GPU hardware and memory and Slurm job scheduler. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

By root cause1