#2625 Linux CUDA/Xid crashes on RTX 5060 Ti 16 GB: repeated short prompts and 16K+ prefill; same machine reportedly works on Windows

Beschreibung

# Linux CUDA/Xid crashes on RTX 5060 Ti 16 GB: repeated short prompts and 16K+ prefill; same machine reportedly works on Windows

## Summary

Strata v0.1.44.1 intermittently fails on short requests and repeatedly fails during longer prefill on this Ubuntu machine. NVIDIA kernel logs show Xid 11/13/31/69 across the investigation. The engine reports CUDA launch failures, sometimes an illegal memory access or cuBLAS execution failure. Text, vision and native 128K context are the intended workload; this installation is **not reliably usable** yet.

The owner reports that the same hardware, model, images and 128K workload work on Windows. The exact Windows driver/build and a matched Windows log are not yet available, so this is an owner-reported comparison, not a controlled benchmark.

**Root cause is unknown.** We are seeking guidance on distinguishing an engine bug, CUDA/driver issue, or platform interaction. We have not established a defective GPU, an unsupported CPU, a firmware defect, or an IOMMU root cause.

## Environment

| Component | Recorded configuration |
| --- | --- |
| GPU | MSI GeForce RTX 5060 Ti, 16 GB, PCI device ID 2d04 |
| CPU | AMD Ryzen 7 3700X, Zen 2, AVX2 supported; no AVX-512 |
| Motherboard | ASUS TUF B350M-PLUS GAMING |
| BIOS | 6254; newest listed version when checked during investigation |
| RAM | 64 GB, four 16 GB DIMMs from mixed A-DATA/G.Skill kits; tested at 3000 and 2666 MT/s |
| OS | Ubuntu 24.04 LTS |
| Current recorded kernel | 6.8.0-147-generic |
| Current recorded driver | NVIDIA open kernel module 615.71.09, Ubuntu package 615.71.09-0ubuntu0.24.04.2 |
| Engine | v0.1.44.1, built by official Linux setup workflow; BUILD.json records CUDA 13.0, arch 120, source 7dfd34378bd2d32a; GCC 13.3 |
| Model | ukisai/Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-GGUF, IQ2_XS |
| Context | 131072; INT8 KV; KV resident 32768; vision enabled |
| PCIe | x8 negotiated width; measured host-to-device probe about 7.1 GB/s |
| BAR1 | 16 GiB after CSM disabled / Above 4G Decoding Auto; previously 256 MiB |
| Current recorded kernel arguments | ro quiet splash iommu.passthrough=1 iommu.strict=1 vt.handoff=7 |

Current configuration has an empty `env` object. `--no-ple-prefetch` remains enabled from diagnosis, but does not resolve the crashes. Other important arguments include `--expert-cache auto --prefill 512 --spec 4 --spec-min-p 0.5 --max-context 131072 --kv int8 --kv-resident 32768 --vision --vram-reserve-mib 896`, plus model/pack/MTP/profile paths.

## Expected / actual behavior

Expected: repeat text and image requests, including native 128K prompts, without engine termination or new NVIDIA Xids.

Actual: the model loads successfully, but requests can terminate the engine. A short request passing once does not imply stability. Some image failures were HTTP 400 or incomplete answers without a new Xid; those must be distinguished from GPU crashes.

Three service-start cycles on driver 615.71.09, BAR1 16 GiB, with `--no-ple-prefetch`:

| Cycle | Vision | ~2K prompts passed | ~8K prompts passed | ~32K prompts passed |
| --- | --- | --- | --- | --- |
| 1 | HTTP 400 | 1/2 | 1/2 | 0/1 |
| 2 | Incomplete answer, no new Xid | 2/2 | 1/2 | 0/1 |
| 3 | Pass | 1/2 | 2/2 | 0/1 |

32K failed on its first request in all three cycles. In separate direct-engine tests, 12K passed and 16K failed (about 64 seconds). This is an observed boundary in those runs, not a universal threshold.

One earlier 28-minute interval passed vision, 2K ×2, 8K ×2, 32K ×1 and ~130800-token prompts ×2 with no new Xid. The successful configuration did not remain reliable after reboot. The long tests checked retrieval of `START-593` and `END-827`; they are smoke tests, not comprehensive quality benchmarks.

## Direct-engine reproduction

This bypasses the HTTP server and its watchdog. Use the existing official setup-generated config; it must contain valid local pack/model/MTP/profile paths. Stop the service first to release VRAM. Run from the Strata directory in the same environment as the installation.

```bash
sudo systemctl stop strata
cd /opt/Strata
python3 - <<'PY'
import json, pathlib, subprocess, time
config = json.loads(pathlib.Path('strata-swift-iq2_xs.json').read_text())
tokens = pathlib.Path('/tmp/strata-repro-16k.txt')
tokens.write_text(' '.join(['40'] * 16000))
args = list(config['args'])
# The setup config used here contains engine args, without --serve.
assert '--serve' not in args, 'Remove serving-only options for direct mode'
cmd = [config.get('exe', '/opt/Strata/engine/strata'), *args,
       '--tokens-file', str(tokens), '--max-new', '16']
start = time.monotonic()
with open('/tmp/strata-repro-16k.log', 'w') as log:
    result = subprocess.run(cmd, stdout=log, stderr=subprocess.STDOUT)
print('exit:', result.returncode, 'seconds:', round(time.monotonic()-start, 2))
PY
sudo journalctl -k -b --no-pager | grep -E 'NVRM: Xid|MMU Fault|FAULT_PDE'
```

Do **not** add a literal `generate` subcommand: direct generation is the default in this build. Supplying `generate` returned usage/exit 2. Token ID 40 repeated 16000 times is a synthetic prefill stress input; natural-text API prompts fail too. Record kernel-log timestamps or before/after counts to identify new events rather than counting old Xids.

## Error samples and sanitizer result

Earlier driver 580 runs repeatedly included addresses ending in `06837000` (other earlier events had different offsets):

```text
MMU Fault: ENGINE GR_HOST0 HUBCLIENT_ESC0 faulted @ 0x202_06837000.
Fault is of type FAULT_PDE ACCESS_TYPE_VIRT_READ
```

On 615.71.09, recorded failures also include Xid 11/13 and:

```text
MMU Fault: ENGINE GRAPHICS GPC2 GPCCLIENT_T1_0 faulted @ 0x0_00000000.
Fault is of type FAULT_PDE ACCESS_TYPE_VIRT_READ
```

Engine observations under different diagnostic settings:

| Setting | Reported error |
| --- | --- |
| Baseline | dequant launch: unspecified launch failure |
| STRATA_BF16_TC=2 | dequant launch: an illegal memory access was encountered |
| --sync-every-layer | prefill moe_combine: unspecified launch failure |
| CUDA_LAUNCH_BLOCKING=1 | prefill gemm: cublasGemmEx: cuBLAS status 13 |

CUDA errors can be asynchronous; these locations do not establish the originating operation. Launch blocking also changes behavior and is diagnostic only. `STRATA_PF_STEP_SYNC=1` produced no `pf-step` lines; this absence alone does not prove every synchronization point passed.

`compute-sanitizer --tool memcheck` on the direct 16K test reported five CUDA API errors, all `cudaErrorLaunchFailure (719)`, with the first reported at `cudaStreamSynchronize` in `strata::prefill::Prefill::run_impl`. It reported no Invalid read/write or misaligned-access diagnostic. Instrumentation required overriding `--expert-cache 500 --vram-reserve-mib 4096`; otherwise instrumentation ran out of VRAM at initialization. **This is a changed configuration and does not exclude an application bug, race, or uninstrumented failure.**

## Comparisons already attempted

These changes did not establish a stable configuration; they are not all controlled single-variable experiments, and should not be read as categorical exclusions.

| Area | Tested values / changes |
| --- | --- |
| NVIDIA driver | 570.211.01, 580.178.04, 615.71.09 |
| Kernel | 6.8.0-147, 6.17.0-42, 7.0.0-38 |
| Build | CUDA 12.9 and 13.0; engine 0.1.40.3 and 0.1.44.1 |
| Memory clock | 3000 and 2666 MT/s |
| PCI/platform | IOMMU passthrough and fully disabled; ASPM disabled; NVreg_DmaRemapPeerMmio=0; pci=nommconf |
| BAR1 | 256 MiB and 16 GiB |
| Engine | prefill auto/4096/512; VRAM reserve 700/832/896/960/4916; --pcie-mode dma |
| Diagnostics | STRATA_KV_HOST_DMA, STRATA_PREFILL_CPU_SHARE=0, STRATA_ADAPT_OVERLAP=1, --sync-every-layer, STRATA_BF16_TC=2 |
| Host allocation | THP request disabled; explicit 2 MiB huge pages (17000 pages), allocation confirmed in log |

`--spec 0` was rejected for this native IQ pack, so it is **not** a completed no-speculation comparison. `STRATA_DENSE_F32=1` was found in a compile-time SM60-only path, so it is **not** a valid comparison on this build. `--ple-sync-submit` produced NaNs and was removed. Experimental environment overrides and explicit huge pages were removed afterward.

The documented RTX 50/CUDA 13.2.0–13.2.1 compiler issue does not directly match the CUDA 13.0 build used here.

## Other diagnostics and limitations

- `gpu_burn 600`: no reported errors. This does not certify all GPU/VRAM/PCIe paths healthy.
- `memtester 8192M`: no reported failures in tested patterns/region. This did not test all 64 GB or exclude intermittent RAM faults.
- Recorded AER status was clean; no OOM kill was found in the inspected logs.
- Custom CUDA probes also failed outside Strata: batched small-kernel / host-transfer workloads produced Xids; per-copy-synchronized tests passed 120 seconds, including a recorded 743.87 GiB transfer/check run. A kernel-only batch probe also failed, so **large host registration or host DMA alone is not an established explanation**. The probes are custom diagnostic code, not certified hardware tests; correctness and timing effects require independent review.
- Changing driver changed fault signatures; it does not prove the driver caused the fault or that an earlier issue was fixed.
- No GPU-in-another-machine / another-GPU-in-this-machine cross-test has been completed.
- BIOS availability, Windows driver details and a matched Windows reproduction should be rechecked before drawing platform conclusions.

## Questions for maintainers

1. Does the direct 16K reproduction or these Xid signatures match a known sm_120 issue?
2. Which official diagnostic configuration/test would best distinguish engine ordering/lifetime bugs from a driver/platform failure?
3. Which logs, build metadata or NVIDIA diagnostic bundle would you like next?
4. Would a comparison with an officially supported alternate engine build help, and which build/settings should be held fixed?

Potential attachments: setup config with API keys removed, engine BUILD.json, full failing engine log, timestamped kernel log, complete sanitizer log, and custom probe source with launch parameters. Not all of those are included in this text; missing artifacts should not be implied to exist.