# DF-4968 — radeon GART table_size/num_gpu_pages 32-bit wrap (DF-2012's radeon twin): power-of-two validation forces the wrapped size to 0, so init fails closed — missing consistency check in radeon_gart_table_{vram,ram}_alloc

**File:** `sys/dev/drm/radeon/radeon_gart.c:127-140,68-87,345-350`
**Class:** integer wrap → undersized GART table (hardening; fail-closed in the current code)
**Severity:** Info (defense-in-depth gap; no demonstrated runtime impact)
**Status:** untested on this guest (no radeon hardware); arithmetic validated by `gart_math.c`.

## Build / Run / Expected

```
cc -O2 -Wall -o gart_math gart_math.c && ./gart_math
```
`ALL CHECKS PASSED (0 failures)` — shows `gart_size=2097152` MB passing `radeon_check_arguments`,
`num_gpu_pages = 2^29`, and `table_size = num_gpu_pages * 8` wrapping to **0** (and the ×4
asic variant wrapping at 4 TiB, plus `num_gpu_pages` itself truncating to 0 at ≥ 16 TiB).

## Why Info and not Medium (unlike DF-2012)

DF-2012 (amdgpu) had a *usable* small wrapped table (2048 bytes) because `amdgpu.gart_size`
is not constrained to powers of two. The radeon validator
(`sys/dev/drm/radeon/radeon_device.c:1126-1134`) **requires a power of two**, so the wrapped
`table_size` is always exactly **0** for every accepted value ≥ 2 TiB (×8 asics) / ≥ 4 TiB
(×4 asics). A 0-size table yields a failed/zero-length BO (`radeon_gart_table_vram_alloc`
→ `radeon_bo_create(0)`) or a NULL `pci_alloc_consistent(0)` — gart init fails and the
device fails to initialize (fail-closed). The residual hazard: nothing rejects the
configuration *before* allocation, and `radeon_gart_table_vram_pin`'s restore loop
(`radeon_gart.c:178-179`) would write `num_gpu_pages` PTEs through whatever (possibly
0-length) mapping `radeon_bo_kmap` returned, if that ever succeeded. The consistency check
that upstream added for amdgpu-style bugs is simply absent here.