You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue tracks an unhealthy unattended CI workflow.
Subsequent failures are recorded in comments; a successful run in the
same trigger scope closes the issue automatically.
Looked at the last five runs. Three recurring real failures and one infra-side symptom. Full matrix is otherwise green.
1. numba-cuda-mlir on Windows MCDM, rtxpro6000 — three nights running
Oct 24 job, Oct 25 job, Oct 26 job. Each run opens with Write-Error "Switching to driver mode MCDM failed!" from the pre-test mode switch. Oct 24 and Oct 25 end with pytest exit 127 mid-run (no test summary written); Oct 26 completes and fails tests/test_dump_nvvm.py::test_compilation_dumps_exact_nvvm_input[ptx-sm_100] with assert 0 == 1. Oct 27-28 pass, so it is intermittent — but the common ancestor is the MCDM mode-switch warning, not a code change.
2. numba-cuda-mlir on Linux rtxpro6000, CUDA 13.4.2 wheels — Oct 27
Job log. Two tests in tests/test_cuda_array_interface_launch_cache.py both die with cupy_backends.cuda.api.driver.CUDADriverError: CUDA_ERROR_INVALID_CONTEXT: invalid device context:
Looks like test-ordering sensitivity under pytest-randomly — an earlier test tears the primary context that cupy then inherits.
3. standard linux-aarch64 Python 3.14t, CUDA 13.4.2 local — Oct 27
Job log. cuda_bindings_13/tests/test_cuda.py::test_coredump_bool_uses_single_byte_storage fails with assert True is False, labeled PARALLEL FAILED. The test is @pytest.mark.thread_unsafe-marked but agent-authored; the process-global LIGHTWEIGHT coredump round-trip is not surviving concurrent test execution on free-threaded 3.14t.
(Related: the Oct 22 aarch64 run saw the same four standard jobs all fail tests/test_load_nvidia_dynamic_lib.py::test_load_nvidia_dynamic_lib[cudss] with Child process failed for libname='cudss' with exit code 0. Has not recurred since.)
4. Oct 28 — only failure is infra, not test
Nightly numba-cuda linux-64 CUDA 13.4.2 wheels fails at host NVIDIA driver install (580.65.06 on kernel 6.8.0-147): ERROR: Building kernel modules → ERROR: The nvidia kernel module was not created. Job log.
#3263 was merged as the fix and auto-closed this issue, but reopening because:
Both Oct 28 attempts (02:35 UTC, 15:02 UTC) ran before the PR merged at 18:29 UTC, so no nightly has exercised the new installer path yet.
Author's note on the PR: "Live GPU validation remains pending CI."
The patch only diverges from the old path when /proc/version's build-time GCC major differs from the host's default gcc -dumpversion. If 6.8.0-147 is built with gcc-13 (same as the Noble default), the patch is a no-op and the DKMS failure persists.
It assumes the .run installer picks up the exported CC/CXX for the kernel module build; passing --cc= to the installer explicitly would be safer.
/var/log/nvidia-installer.log is not uploaded as an artifact, so the actual compile error — and whether it really is "GCC 13 rejects GCC 14 flags" — has not been shown.
Letting tomorrow's scheduled run speak before re-closing.
5. Earlier context
Oct 16-19 wiped the entire numba-cuda matrix (six jobs) with RuntimeError: NumPy only supports stream=None. from the numpy==2.4.6 + numba-cuda==0.30.4 combination. Resolved upstream by Oct 20.
Activity
github-actions commentedon Oct 25, 2026
Another unhealthy run
CI: Nightly optional-deps run #228, attempt 1 concluded with failure.
schedulemaina2fb8042026-10-25T03:21:30Zgithub-actions commentedon Oct 26, 2026
Another unhealthy run
CI: Nightly optional-deps run #229, attempt 1 concluded with failure.
schedulemaina2fb8042026-10-26T03:08:44Zgithub-actions commentedon Oct 27, 2026
Another unhealthy run
CI: Nightly optional-deps run #230, attempt 1 concluded with failure.
schedulemain590a8bf2026-10-27T03:14:39Zgithub-actions commentedon Oct 28, 2026
Another unhealthy run
CI: Nightly optional-deps run #231, attempt 1 concluded with failure.
schedulemain94625c12026-10-28T03:27:15Zgithub-actions commentedon Oct 28, 2026
Another unhealthy run
CI: Nightly optional-deps run #231, attempt 2 concluded with failure.
schedulemain94625c12026-10-28T15:05:28Zleofang commentedon Oct 28, 2026
Nightly triage, Oct 24-28
Looked at the last five runs. Three recurring real failures and one infra-side symptom. Full matrix is otherwise green.
1. numba-cuda-mlir on Windows MCDM, rtxpro6000 — three nights running
Oct 24 job, Oct 25 job, Oct 26 job. Each run opens with
Write-Error "Switching to driver mode MCDM failed!"from the pre-test mode switch. Oct 24 and Oct 25 end with pytest exit 127 mid-run (no test summary written); Oct 26 completes and failstests/test_dump_nvvm.py::test_compilation_dumps_exact_nvvm_input[ptx-sm_100]withassert 0 == 1. Oct 27-28 pass, so it is intermittent — but the common ancestor is the MCDM mode-switch warning, not a code change.2. numba-cuda-mlir on Linux rtxpro6000, CUDA 13.4.2 wheels — Oct 27
Job log. Two tests in
tests/test_cuda_array_interface_launch_cache.pyboth die withcupy_backends.cuda.api.driver.CUDADriverError: CUDA_ERROR_INVALID_CONTEXT: invalid device context:test_cupy_array_signature_cache_tracks_dtype_and_ndimtest_cupy_launch_does_not_reconstruct_device_arraysLooks like test-ordering sensitivity under
pytest-randomly— an earlier test tears the primary context that cupy then inherits.3. standard linux-aarch64 Python 3.14t, CUDA 13.4.2 local — Oct 27
Job log.
cuda_bindings_13/tests/test_cuda.py::test_coredump_bool_uses_single_byte_storagefails withassert True is False, labeledPARALLEL FAILED. The test is@pytest.mark.thread_unsafe-marked but agent-authored; the process-globalLIGHTWEIGHTcoredump round-trip is not surviving concurrent test execution on free-threaded 3.14t.(Related: the Oct 22 aarch64 run saw the same four
standardjobs all failtests/test_load_nvidia_dynamic_lib.py::test_load_nvidia_dynamic_lib[cudss]withChild process failed for libname='cudss' with exit code 0. Has not recurred since.)4. Oct 28 — only failure is infra, not test
Nightly numba-cuda linux-64 CUDA 13.4.2 wheelsfails at host NVIDIA driver install (580.65.06 on kernel 6.8.0-147):ERROR: Building kernel modules→ERROR: The nvidia kernel module was not created. Job log.#3263 was merged as the fix and auto-closed this issue, but reopening because:
/proc/version's build-time GCC major differs from the host's defaultgcc -dumpversion. If 6.8.0-147 is built with gcc-13 (same as the Noble default), the patch is a no-op and the DKMS failure persists..runinstaller picks up the exportedCC/CXXfor the kernel module build; passing--cc=to the installer explicitly would be safer./var/log/nvidia-installer.logis not uploaded as an artifact, so the actual compile error — and whether it really is "GCC 13 rejects GCC 14 flags" — has not been shown.Letting tomorrow's scheduled run speak before re-closing.
5. Earlier context
Oct 16-19 wiped the entire
numba-cudamatrix (six jobs) withRuntimeError: NumPy only supports stream=None.from thenumpy==2.4.6+numba-cuda==0.30.4combination. Resolved upstream by Oct 20.-- Leo's bot
github-actions commentedon Oct 29, 2026
Another unhealthy run
CI: Nightly optional-deps run #232, attempt 1 concluded with failure.
schedulemaind4c71ef2026-10-29T03:44:49Zgithub-actions commentedon Oct 30, 2026
Another unhealthy run
CI: Nightly optional-deps run #233, attempt 1 concluded with failure.
schedulemain03b41532026-10-30T02:51:44Z[no-ci] Use 580.126.18 for compatibility test on new ubuntu. (#3295)