Skip to content

[BUG]: PinnedMemoryResource rejects usable HOST_NUMA pools on CUDA 12.6-12.8 drivers #2795

Description

@carterbox

Is this a duplicate?

  • I confirmed there appear to be no duplicate issues for this bug and that I agree to the Code of Conduct

Related but distinct: #2486 (the original unusable-buffer bug) and #2487 (the fix that introduced this regression).

Type of Bug

Runtime Error

Component

cuda.core

Describe the bug

#2487 added a capability pre-check before allocating a pinned host memory pool. On CUDA 12.6–12.8 drivers that check produces a false negative and rejects a HOST_NUMA pool that the driver creates and uses successfully.

This is a regression introduced in cuda.core 1.2.0 (released 2026-09-03, the first release containing #2487, which merged 2026-08-07). cuda.core 1.1.0 predates the pre-check and is unaffected.

The problem is that the capability attributes are newer than the capability itself:

Attribute Ordinal First defined in
CU_DEVICE_ATTRIBUTE_HOST_NUMA_MEMORY_POOLS_SUPPORTED 142 CUDA 12.9
CU_DEVICE_ATTRIBUTE_HOST_MEMORY_POOLS_SUPPORTED 144 CUDA 13.0

HOST_NUMA pools have been supported since CUDA 12.6 (see the cuMemPoolCreate docs

check_numa_pool.py

, which state that a host NUMA pool requires CUmemLocation::type = CU_MEM_LOCATION_TYPE_HOST_NUMA, and that CU_MEM_LOCATION_TYPE_HOST yields CUDA_ERROR_INVALID_VALUE).

On a 12.6–12.8 driver, querying ordinal 142 returns CUDA_ERROR_INVALID_VALUE. cuda.core surfaces that as a confident False rather than "unknown", so Device(0).properties.host_numa_memory_pools_supported returns False with no exception. The #2487 pre-check reads that False and raises. The net effect is that on drivers 12.6–12.8 there is currently no way to obtain a NUMA host pool through cuda.core.PinnedMemoryResource, even though the driver supports it.

All three constructor paths fail on such a driver, but only one is a defect:

Path Result on CUDA 12.6 Assessment
options=None RuntimeError: Getting the current memory pool requires CUDA 13.0 or later deliberate version gate — correct
PinnedMemoryResourceOptions() CUDAError: CUDA_ERROR_INVALID_VALUE driver correctly rejects a HOST-location pool — correct
PinnedMemoryResourceOptions(numa_id=0) RuntimeError: device does not support the requested host memory pool this bug

This was verified against driver ground truth: a standalone C reproducer compiled against 12.6 headers, using only the raw driver API with no cuda.core in the path, creates that exact HOST_NUMA pool and round-trips verified data through it on the same machine. So the rejection originates in the cuda.core capability layer, not in the driver.

Probing by raw ordinal rather than by enum name is necessary to see this: on 12.6 headers the enum names do not exist, so a name-based probe cannot distinguish "the driver rejected the query" from "my headers are too old".

How to Reproduce

On a machine with a CUDA 12.6–12.8 driver:

from cuda.core import Device, PinnedMemoryResource, PinnedMemoryResourceOptions

dev = Device(0)
dev.set_current()

# False because the driver cannot answer the query, not because the
# capability is genuinely absent:
print(dev.properties.host_numa_memory_pools_supported)  # -> False

PinnedMemoryResource(options=PinnedMemoryResourceOptions(numa_id=0))
# RuntimeError: device does not support the requested host memory pool

The equivalent raw-driver sequence — cuMemPoolCreate with CUmemLocation::type = CU_MEM_LOCATION_TYPE_HOST_NUMA and id = 0 — succeeds on the same machine, and memory allocated from the resulting pool is usable and verifiable.

Confirmed on an NVIDIA A10M, driver 560.35.05 (cuDriverGetVersion -> 12060), cuda.core 1.2.0, cuda-bindings 12.9.7, cuda-version 12.6, Python 3.14.7 (conda-forge).

As a baseline, the same probes on a CUDA 13.2 driver report all attributes queryable and both pool kinds working, with no detection gap.

Expected behavior

An attribute that cannot be queried should be treated as unknown, not as unsupported.

On drivers where ordinal 142 is unqueryable but HOST_NUMA pools are documented as supported (12.6+), PinnedMemoryResource(options=PinnedMemoryResourceOptions(numa_id=...)) should either attempt the allocation and surface a genuine driver error if it fails, or determine the capability from the driver version rather than from an unanswerable attribute query. It should not pre-emptively reject a configuration the driver demonstrably supports.

More generally, it would help consumers if cuda.core distinguished "queried and got no" from "could not ask" — code that tries to tell those apart with try/except currently sees a confident False on precisely the drivers where that answer is wrong.

Operating System

Ubuntu Linux, kernel 6.8.0-139-generic (x86_64)

nvidia-smi output

+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 560.35.05              Driver Version: 560.35.05      CUDA Version: 12.6     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA A10M                    Off |   00000000:61:00.0 Off |                    0 |
|  0%   42C    P0             41W /  150W |       1MiB /  19190MiB |      3%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   1  NVIDIA A10M                    Off |   00000000:DB:00.0 Off |                    0 |
|  0%   50C    P0             53W /  150W |       1MiB /  19190MiB |      2%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions