test: handle partial NVML support on Jetson Orin by rwgk · Pull Request #2947 · NVIDIA/cuda-python

rwgk · 2026-09-24T00:01:07Z

Description

fixes Orin failures (cuDLA nightly testing)

CUDA Toolkit 13.4 exposes partial NVML support on Jetson Orin: system-level
queries work, while parts of the device API remain unavailable. This caused
tests that were skipped with CUDA Toolkit 13.3 to run and fail.

This change:

distinguishes basic NVML availability from device API availability, keeping
supported bindings and cuda.core coverage enabled;
skips only cuda.core tests that require unavailable NVML device APIs;
treats the PCI lookup used by device_discover_gpus as an optional device
capability; and
allows bounded driver bookkeeping in the VMM leak regression while still
detecting the repeated leak that the test covers.

Testing

The full Linux QA build and test workflow was run from scratch on a Jetson AGX
Orin board with CUDA Toolkit 13.4. A clean test rerun completed without
failures:

jetson:~/wrk/forked/cuda-python $ grep_pytest_summary `nlog`
/home/rgrossekunst/wrk/logs/cuda-python_qa_bindings_linux_2026-09-24+005744+0000_tests_log.txt
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_pathfinder
======================= 1618 passed, 2 skipped in 13.23s =======================
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
=========== 544 passed, 79 skipped, 18 warnings in 63.24s (0:01:03) ============
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
=========== 544 passed, 79 skipped, 18 warnings in 62.27s (0:01:02) ============
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
============================== 9 passed in 0.99s ===============================
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_core
= 3960 passed, 464 skipped, 3 xfailed, 7 warnings, 8 subtests passed in 536.62s (0:08:56) =
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_core
============================== 1 passed in 0.33s ===============================

Log inspection confirms that bindings NVML tests were collected and executed,
unsupported device-dependent cuda.core tests were skipped with the intended
reason, and both test_vmm_allocate_close_does_not_leak[allocate] and
test_vmm_allocate_close_does_not_leak[grow] passed.

Checklist

New or existing tests cover these changes.
The documentation is up to date with these changes (no user-facing documentation change).

copy-pr-bot · 2026-09-24T00:01:10Z

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

rwgk · 2026-09-24T02:18:40Z

/ok to test

github-actions · 2026-09-24T04:06:25Z

Doc Preview CI
Preview removed because the pull request was closed or merged.

mdboom · 2026-09-30T19:54:12Z

-    assert baseline - free < aligned_size
+    # The broken path leaks aligned_size per iteration. Allow one allocation's
+    # worth of driver bookkeeping/caching while still detecting repeated leaks.
+    assert baseline - free < 2 * aligned_size


I think it would be clearer / less brittle to not leak this by making allocate_and_close only run once. Maybe make it a global (non-nested) function and add the @functools.cache decorator?

Done in f2b7822. I moved the allocation/close operation to a module-level helper and added a cached module-level warm-up wrapper, so the one-time driver bookkeeping happens outside the measurement. The eight measured calls remain uncached so the regression still detects a repeated leak, and the strict < aligned_size assertion is restored. The from-scratch Orin rerun at that commit passed both variants.

GPT-6.1-Sol ultra running on Orin:

Retained the cached module-level warm-up from Ralf's earlier reply. It is keyed by device ID and growth mode; the eight measured allocation/close calls remain uncached, and the assertion stays baseline - free < aligned_size. Warm-up and measurement now share VMM_LEAK_TEST_REQUESTED_SIZE. Current implementation.

Both variants passed the focused TestVenv run. The grow case emitted a cleanup warning that also reproduced with the pre-change test; this change does not resolve that warning. Ralf's latest from-scratch rerun at the current head also completed without test failures.

rwgk · 2026-09-30T21:06:14Z

Converting this PR back to Draft mode, to avoid triggering the full CI. — I want to push here to retest on Orin first.

rwgk · 2026-09-30T21:43:02Z

Retesting from scratch on Orin @ f2b7822 was successful:

jetson:~/wrk/forked/cuda-python $ grep_pytest_summary `nlog`
/home/rgrossekunst/wrk/logs/cuda-python_qa_bindings_linux_2026-09-30+212544+0000_tests_log.txt
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_pathfinder
======================= 1618 passed, 2 skipped in 13.86s =======================
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
=========== 578 passed, 80 skipped, 18 warnings in 68.46s (0:01:08) ============
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
=========== 578 passed, 80 skipped, 18 warnings in 65.74s (0:01:05) ============
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
============================== 9 passed in 0.99s ===============================
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_core
= 4003 passed, 465 skipped, 3 xfailed, 7 warnings, 8 subtests passed in 681.52s (0:11:21) =
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_core
============================== 1 passed in 0.33s ===============================

rwgk · 2026-09-30T21:50:54Z

@mdboom could you please take another look?

The fixes and the individual replies to your feedback were generated by GPT-5.6-Sol medium.

kkraus14 · 2026-10-01T02:00:44Z

+skip_if_nvml_device_apis_unsupported = pytest.mark.skipif(
+    _should_skip_nvml_tests() or not hardware_supports_nvml_device_apis(),
+    reason="NVML device APIs are incomplete or unavailable on this platform",
+)


Instead of skipping if the device API is unsupported, I wonder if it makes sense to instead allow catching the specific nvml.NotSupportedError exception or whatever we would expect the behavior to be when the underlying used APIs aren't supported?

Since users would presumably get that exception if they tried to use the cuda.core.system APIs, it would be good to test that we're delivering the desired / expected user experience?

I gave this as a task to codex GPT-6.1-Sol ultra. It looks like it found an existing bug, which it fixed, and then it made the changes as suggested by @kkraus14. It's now a much bigger PR. @mdboom what do you think about that direction?

The unsupported_before helper function already catches NotSupportedError in order to skip the test. We could use that everywhere.

I asked codex to backtrack, but to preserve genuine improvements. The resulting commits are:

7554cd7 test(cuda.core): restore skips for unsupported NVML APIs

4ed9dd0 fix(cuda.core): remove NVLink state preflight

497203c test(cuda.core): share VMM leak test allocation size

GPT-6.1-Sol ultra running on Orin:

The corrective commits Ralf listed restore accurate skip reporting after my broader rewrite accepted unsupported operations without checking their intended result. The conservative device capability gate is back on the affected hardware tests.

Mike is right that unsupported_before already converts NotSupportedError into a skip in its optional-support branches. There is a nuance for Orin: it reports AMPERE, so a call guarded with a KEPLER minimum reaches the branch that propagates errors. Replacing the gate with that existing usage everywhere would therefore still fail here. Helper branches.

Keith's caller-behavior coverage remains in focused, deterministic regressions: CUDA-to-NVML lookup must propagate injected NotFoundError and NotSupportedError, and NVLink count/iteration must propagate injected per-field errors. These tests assert the exceptions rather than treating unsupported hardware queries as successful operation coverage. Lookup regression, NVLink regressions. Supported NVML-to-CUDA UUID mapping is also asserted on this Orin host, with its unsupported optional PCI check reported as a separate skipped subtest.

There is a nuance for Orin: it reports AMPERE, so a call guarded with a KEPLER minimum reaches the branch that propagates errors. Replacing the gate with that existing usage everywhere would therefore still fail here.

As I said here, we need to update that logic, so that on Orin we ignore the passed-in architecture.

Preserve UUIDs reported without a prefix and propagate unsupported NVLink queries before reading unpopulated field results. Keep zero-count behavior for devices without link zero, and cover UUID normalization, lookup errors, and NVLink error propagation with regressions.

Replace the UUID-based device-wide skip with narrow checks of the actual API result. Exercise supported Orin queries, validate precise unsupported errors, preserve CUDA visibility and MIG coverage, and require successful UUID matching when a CUDA counterpart exists.

rwgk · 2026-10-01T04:53:24Z

Retesting from scratch on Orin @ 2ed2554 was successful:

jetson:~/wrk/forked/cuda-python $ grep_pytest_summary `nlog`
/home/rgrossekunst/wrk/logs/cuda-python_qa_bindings_linux_2026-10-01+043322+0000_tests_log.txt
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_pathfinder
======================= 1618 passed, 2 skipped in 13.89s =======================
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
=========== 578 passed, 80 skipped, 18 warnings in 68.62s (0:01:08) ============
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
=========== 578 passed, 80 skipped, 18 warnings in 66.02s (0:01:06) ============
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
============================== 9 passed in 0.98s ===============================
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_core
= 4033 passed, 446 skipped, 3 xfailed, 7 warnings, 32 subtests passed in 630.37s (0:10:30) =
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_core
============================== 1 passed in 0.34s ===============================

mdboom · 2026-10-01T13:58:24Z

+        system_device = device.to_system_device()
+    except system.NotFoundError:
+        # Orin enumerates NVML devices but does not support lookup by UUID.
+        return


If this should only fail on Orin, we should assert that here.

GPT-6.1-Sol ultra running on Orin:

Removed the blanket NotFoundError early return in 7554cd70d37. The integration test now uses the restored capability probe and records a skip when the probe finds incomplete device APIs; once the probe passes, an unexpected conversion error fails the test. Separate deterministic tests explicitly assert propagation of injected NotFoundError and NotSupportedError. Integration test, Error propagation tests.

This solution is so much broader than my suggestion, I'm not sure why it did that and what it was trying to accomplish.

mdboom · 2026-10-01T14:05:26Z

+  now raise :class:`system.NotSupportedError` when Orin does not support
+  NVLink queries, instead of reading an unpopulated NVML field result.


The check isn't actually Orin-specific.

Suggested change

now raise :class:`system.NotSupportedError` when Orin does not support

NVLink queries, instead of reading an unpopulated NVML field result.

now raise :class:`system.NotSupportedError` when the device does not support

NVLink queries, instead of reading an unpopulated NVML field result.

GPT-6.1-Sol ultra running on Orin:

Removed this release-note entry together with the state preflight in 4ed9dd0350d. Requiring link-zero state support could reject an otherwise valid zero count, so the count again comes from its own field API. The replacement regression asserts zero count and empty iteration with an unsupported state API. Regression.

A fresh probe on this Orin driver still shows the field call returning successfully without changing supplied output sentinels. That driver/binding issue remains unresolved; the restored hardware-test gate avoids claiming a runtime repair.

I don't understand how your solution flows from my suggestion.

mdboom · 2026-10-01T14:27:15Z

+            try:
                affinity = device.get_cpu_affinity(typing.AffinityScope.NODE)
+            except nvml.NotSupportedError:
+                continue


This turns a skip (when nvml.NotSupportedError is raised) into a silent pass. This seems like an undesirable test regression to me (and this pattern is repeated ~20 times in this file).

(I wonder if this is due to responding to @kkraus14's comment about checking for NotSupportedError and not realizing that unsupported_before already does that).

We may need to extend unsupported_before with a new argument "on_orin", that when True would happily skip if NotSupportedError is raised on the Orin platform. (Rather than just a too-old architecture as passing typing.DeviceArch.KEPLER currently does).

GPT-6.1-Sol ultra running on Orin:

Agreed; this was a regression in my rewrite. The affected inline NotSupportedError catches that passed, returned, or continued without validating the operation are rolled back, and the device capability gate is restored. The retained mapping test asserts UUID conversion in one subtest and uses unsupported_before(device, None) for optional PCI validation in another. The focused Orin run reports those as SUBPASSED and SUBSKIPPED, respectively. Mapping test.

The proposed on_orin extension is not included in this correction. Orin's AMPERE architecture does bypass the helper's older-than-KEPLER branch, so finer coverage needs an explicit capability/platform policy. The restored gate provides conservative skip reporting now; that finer policy remains follow-up work. Ralf's fresh current-head Orin rerun also completed without test failures.

Ok, I'm willing to accept this given that the tests passed on Orin, but this contradicts the agents statement here: #2947 (comment)

mdboom · 2026-10-01T14:36:05Z

+        assert resolved_device.uuid == device.uuid
        assert resolved_device.index == device.index

+        # PCI lookup can work even when the PCI information query is unsupported.


I don't understand this comment -- it seems to be skipping things when the information query is unsupported.

GPT-6.1-Sol ultra running on Orin:

The removed fallback distinguished obtaining a handle by PCI bus ID from querying its PCI information. The final continue did omit the information assertions when that query was unsupported. I rolled back this event-test rewrite in 7554cd70d37, including the misleading comment.

Hardware device resolution and event registration again use the capability gate; synthetic event wrapping and packed PCI-ID conversion remain enabled. Restored event tests.

mdboom · 2026-10-01T14:37:48Z

+        device,
+        config=VirtualMemoryResourceOptions(handle_type="win32_kmt" if IS_WINDOWS else "posix_fd"),
+    )
+    return _vmm_allocate_and_close(mr, 8 * 1024 * 1024, grow)


NIT: Put 8 * 1024 * 1024 in a global constant so the two mentions of it stay in sync.

GPT-6.1-Sol ultra running on Orin:

Done in 497203c78d1: warm-up and measured allocations both use VMM_LEAK_TEST_REQUESTED_SIZE. The cached warm-up, eight uncached measured calls, and strict leak threshold are preserved. Updated VMM test.

Why was this file completely removed?

Restore the conservative device capability gate and the original device and event test bodies instead of accepting unsupported calls as successful tests. Keep positive UUID mapping checks, report unsupported PCI validation as a separate skipped subtest, restore the process-name NotFound skip, and preserve affinity cleanup and fan serialization.

Read the NVLink count from its own field API without requiring support for the link-zero state API. Replace the preflight regressions with valid zero-count and typed per-field error assertions, regenerate the public stub, and retain only the verified UUID release note with the requested wording.

Use one module constant for the cached warm-up and uncached measured allocations. Preserve eight measured iterations and the strict one-allocation leak threshold.

rwgk · 2026-10-01T17:03:32Z

/ok to test

rwgk · 2026-10-01T17:26:03Z

Retesting from scratch on Orin @ 497203c was successful:

jetson:~/wrk/forked/cuda-python $ grep_pytest_summary `nlog`
/home/rgrossekunst/wrk/logs/cuda-python_qa_bindings_linux_2026-10-01+170946+0000_tests_log.txt
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_pathfinder
======================= 1618 passed, 2 skipped in 13.87s =======================
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
=========== 578 passed, 80 skipped, 18 warnings in 67.18s (0:01:07) ============
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
=========== 578 passed, 80 skipped, 18 warnings in 65.98s (0:01:05) ============
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
============================== 9 passed in 0.99s ===============================
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_core
= 4016 passed, 464 skipped, 3 xfailed, 7 warnings, 9 subtests passed in 602.18s (0:10:02) =
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_core
============================== 1 passed in 0.34s ===============================

Preserve the Orin device-API skip while adopting cuda.core's bindings floor, simplify now-obsolete test guards, and move the UUID fix note to the upcoming release.

rwgk · 2026-10-01T22:07:05Z

Retesting from scratch on Orin @ 66bf6bb was successful:

jetson:~/wrk/forked/cuda-python $ grep_pytest_summary `nlog`
/home/rgrossekunst/wrk/logs/cuda-python_qa_bindings_linux_2026-10-01+214213+0000_tests_log.txt
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_pathfinder
======================= 1618 passed, 2 skipped in 13.92s =======================
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
=========== 586 passed, 80 skipped, 18 warnings in 68.40s (0:01:08) ============
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
=========== 586 passed, 80 skipped, 18 warnings in 66.87s (0:01:06) ============
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
============================== 9 passed in 1.01s ===============================
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_core
= 4076 passed, 463 skipped, 3 xfailed, 7 warnings, 9 subtests passed in 694.83s (0:11:34) =
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_core
============================== 1 passed in 0.34s ===============================

rwgk · 2026-10-01T22:11:31Z

How the merge conflicts were resolved in `66bf6bb`

Git reported one content conflict, in cuda_core/tests/test_device.py::test_to_system_device. The PR side had changed the test to use the init_cuda fixture and to skip if NVML cannot look up a device by UUID, which is the specific Orin limitation. main removed the older CUDA_BINDINGS_NVML_IS_COMPATIBLE check because its new minimum cuda-bindings requirement makes that flag always true.

The resolution keeps the PR's init_cuda fixture, authorship marker, and hardware_supports_nvml_device_apis() probe. It takes main's removal of the obsolete compatibility check and _system import. A platform with incomplete UUID lookup is recorded as skipped; on a supported platform the test still checks the conversion and UUID match.

Resolve the VMM test conflict by adopting the upstream handle-layer regressions. Their exact mapping and reservation release checks supersede the cached warm-up and device-wide free-memory measurement. Preserve the Orin NVML fixes and UUID release note.

rwgk · 2026-10-02T15:35:12Z

GPT-6.1-Sol ultra running on Orin:

How the merge conflict in `e2ae412` was resolved

The only conflicted file was cuda_core/tests/test_memory.py. I resolved it by adopting main’s version, which accompanies the move of VirtualMemoryResource to the Cython/C++ _rt handle layer in #2917.

The upstream tests replace device-wide free-memory sampling with checks that the exact CUDA mappings and address reservations are released. This supersedes our cached allocator warm-up, shared allocation-size constant, and old free-memory comparison.

The tests also reflect the new ownership behavior: modify_allocation() returns a new buffer while the original remains open. They explicitly close all buffers and cover allocation, ordinary growth, and growth requiring relocation, while checking for cleanup warnings. Updated leak regression.

The Orin NVML changes and UUID release note were preserved.

After rebuilding the merged implementation in TestVenv:

VMM tests: 39 passed, 1 skipped, 1 expected failure. All three leak modes passed without cleanup warnings.
System/device tests: 66 passed, 41 skipped, 9 subtests passed.
Pre-commit checks passed except the existing all-files TruffleHog crash (-11); scanning the resolved file separately passed.

rwgk · 2026-10-02T16:01:26Z

Retesting from scratch on Orin @ e2ae412 was successful:

jetson:~/wrk/forked/cuda-python $ grep_pytest_summary `nlog`
/home/rgrossekunst/wrk/logs/cuda-python_qa_bindings_linux_2026-10-02+154404+0000_tests_log.txt
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_pathfinder
======================= 1618 passed, 2 skipped in 13.64s =======================
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
=========== 600 passed, 80 skipped, 18 warnings in 67.06s (0:01:07) ============
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
=========== 600 passed, 80 skipped, 18 warnings in 66.66s (0:01:06) ============
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_bindings
============================== 9 passed in 0.99s ===============================
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_core
= 4117 passed, 463 skipped, 3 xfailed, 5 warnings, 9 subtests passed in 638.17s (0:10:38) =
rootdir: /home/rgrossekunst/wrk/forked/cuda-python/cuda_core
============================== 1 passed in 0.33s ===============================

mdboom

This looks good enough now.

The agent's responses to my comments were really weird, I suspect because it rolled back so many changes from the last version. So on a point-by-point basis it doesn't seem ok, but re-reading it from scratch, I think it's fine.

rwgk · 2026-10-02T21:38:34Z

To close the loop here, the scheduled testing on the Orin board passes again:

cuda-python tests on L4T (Orin) [PASSED] - 20261003_003002

cuda-python Test Report
=======================
Board  : local_l4t
Date   : Sat Oct  3 12:52:20 AM IST 2026
Result : PASSED

--- Suite Results ---
cuda_pathfinder  : 1618 passed, 0 failed, 2 skipped, 0 xfailed
cuda_bindings    : 600 passed, 0 failed, 81 skipped, 0 xfailed
cuda_core        : 4106 passed, 0 failed, 469 skipped, 3 xfailed

Total            : 6324 passed, 0 failed, 3 xfailed
Note             : xfailed = expected failures (known issues, marked xfail in tests)

Removed preview folders for the following PRs: - PR #2880 - PR #2917 - PR #2947 - PR #2965 - PR #2996 - PR #2998 - PR #3003 - PR #3005 - PR #3008 - PR #3010

rwgk added 3 commits September 22, 2026 12:25

test: fix Orin coverage with CUDA 13.4

cc51b13

Merge branch 'main' into orin_fixes

b8924e6

test: preserve partial NVML coverage on Orin

bcbf823

rwgk added this to the cuda.core 1.2.1 milestone Sep 24, 2026

rwgk added the test Improvements or additions to tests label Sep 24, 2026

rwgk self-assigned this Sep 24, 2026

github-actions Bot added cuda.bindings Everything related to the cuda.bindings module cuda.core Everything related to the cuda.core module labels Sep 24, 2026

leofang modified the milestones: cuda.core 1.2.1, cuda.core 1.3.0 Sep 29, 2026

rwgk marked this pull request as ready for review September 30, 2026 19:45

rwgk requested a review from mdboom September 30, 2026 19:45

mdboom requested changes Sep 30, 2026

View reviewed changes

rwgk added 2 commits September 30, 2026 13:58

Merge branch 'main' into orin_fixes

139fc14

test: address Orin review feedback

f2b7822

rwgk marked this pull request as draft September 30, 2026 21:06

Merge branch 'main' into orin_fixes

c390f89

rwgk marked this pull request as ready for review September 30, 2026 21:44

kkraus14 reviewed Oct 1, 2026

View reviewed changes

rwgk added 2 commits October 1, 2026 04:26

Merge branch 'main' into orin_fixes

c128ca7

mdboom requested changes Oct 1, 2026

View reviewed changes

rwgk added 3 commits October 1, 2026 16:42

test(cuda.core): share VMM leak test allocation size

497203c

Use one module constant for the cached warm-up and uncached measured allocations. Preserve eight measured iterations and the strict one-allocation leak threshold.

rwgk marked this pull request as draft October 1, 2026 16:56

rwgk marked this pull request as ready for review October 1, 2026 17:56

Merge main into orin_fixes

66bf6bb

Preserve the Orin device-API skip while adopting cuda.core's bindings floor, simplify now-obsolete test guards, and move the UUID fix note to the upcoming release.

github-actions Bot added the CI/CD CI/CD infrastructure label Oct 1, 2026

mdboom approved these changes Oct 2, 2026

View reviewed changes

rwgk enabled auto-merge (squash) October 2, 2026 16:43

rwgk merged commit a52068d into main Oct 2, 2026
304 of 312 checks passed

rwgk deleted the rwgk/orin-ctk-13-4-tests branch October 2, 2026 17:45

		now raise :class:`system.NotSupportedError` when Orin does not support
		NVLink queries, instead of reading an unpopulated NVML field result.

Conversation

rwgk commented Sep 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing

Checklist

Uh oh!

copy-pr-bot Bot commented Sep 24, 2026

Uh oh!

rwgk commented Sep 24, 2026

Uh oh!

github-actions Bot commented Sep 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rwgk commented Sep 30, 2026

Uh oh!

rwgk commented Sep 30, 2026

Uh oh!

rwgk commented Sep 30, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rwgk commented Oct 1, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rwgk commented Oct 1, 2026

Uh oh!

rwgk commented Oct 1, 2026

rwgk commented Sep 24, 2026 •

edited

Loading

github-actions Bot commented Sep 24, 2026 •

edited

Loading

rwgk commented Oct 1, 2026 •

edited

Loading

How the merge conflicts were resolved in `66bf6bb`

How the merge conflict in `e2ae412` was resolved