Is this a duplicate?
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 |
+-----------------------------------------+------------------------+----------------------+
Is this a duplicate?
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_NUMApool 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:
CU_DEVICE_ATTRIBUTE_HOST_NUMA_MEMORY_POOLS_SUPPORTEDCU_DEVICE_ATTRIBUTE_HOST_MEMORY_POOLS_SUPPORTEDHOST_NUMApools have been supported since CUDA 12.6 (see thecuMemPoolCreatedocscheck_numa_pool.py
, which state that a host NUMA pool requires
CUmemLocation::type = CU_MEM_LOCATION_TYPE_HOST_NUMA, and thatCU_MEM_LOCATION_TYPE_HOSTyieldsCUDA_ERROR_INVALID_VALUE).On a 12.6–12.8 driver, querying ordinal 142 returns
CUDA_ERROR_INVALID_VALUE. cuda.core surfaces that as a confidentFalserather than "unknown", soDevice(0).properties.host_numa_memory_pools_supportedreturnsFalsewith no exception. The #2487 pre-check reads thatFalseand raises. The net effect is that on drivers 12.6–12.8 there is currently no way to obtain a NUMA host pool throughcuda.core.PinnedMemoryResource, even though the driver supports it.All three constructor paths fail on such a driver, but only one is a defect:
options=NoneRuntimeError: Getting the current memory pool requires CUDA 13.0 or laterPinnedMemoryResourceOptions()CUDAError: CUDA_ERROR_INVALID_VALUEPinnedMemoryResourceOptions(numa_id=0)RuntimeError: device does not support the requested host memory poolThis 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_NUMApool 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:
The equivalent raw-driver sequence —
cuMemPoolCreatewithCUmemLocation::type = CU_MEM_LOCATION_TYPE_HOST_NUMAandid = 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_NUMApools 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/exceptcurrently sees a confidentFalseon precisely the drivers where that answer is wrong.Operating System
Ubuntu Linux, kernel 6.8.0-139-generic (x86_64)
nvidia-smi output