NV on Intel Mac Pro 2019 with RTX 3060 in internal PCIe slot (no Thunderbolt) fails with GSP halt before RPC queue and no panic, plus dext caps DMA at 32 segments

Related: #16097 (Intel MBP 2019 + 3060 Ti eGPU, TB3, panic), #16534 (Intel MBP 2020 + 3080 eGPU, TB3, CATERR panic). New information: this is an internal PCIe slot, not Thunderbolt, and it does not panic.

Setup

• MacPro7,1 (Intel Xeon W, T2), macOS 15.6.1 (24G90). RTX 3060 12 GB (GA106, 10de:2504, subsys 1458:4074) in Slot 3, x16 @ 8 GT/s, one 8-pin aux.
• TinyGPU zip commit c0d024f9ff0e1dc8fdf217f255da7101d91e8323 and dext org.tinygrad.tinygpu.driver2 (1.0.0/3) [activated enabled], bound to the card.
• tinygrad master 2cfb421, branch with 3 local patches (diff attached): CUDA_DOCKER_IMAGE env for the compile server (the upstream image is arm64 only, so I built an amd64 one), a failure-path GSP state dump in nv/ip.py, and a truncated-scatter-list check + NV_SYSMEM_CONTIG in system.py.
• Compile path verified end to end (nvcc shim + NVRTC compile server in docker/colima). Firmware ga102 570.144 pre-cached.

Runs (each from a full power cycle)

Run 1 & 2 (default, VT-d on): DEBUG=2 DEV=NV python3 test/test_tiny.py TestTiny.test_plus gives TimeoutError: RPC queue not initialized. Timed out after 10000/60000 ms, condition not met: 0 != 4096 (ip.py NVRpcQueue.__init__). Deterministic. No panic, no VT-d/PCIe messages in the unified log.

Everything before that succeeds with hardware acknowledgement:

• dext: BAR0/1/3 mapped, cfg reads correct, 9 PrepareDMA … segs=1 sysmem buffers (large_bar False, all boot mem is sysmem).
• FRTS ran, WPR2_ADDR_HI = 0x02ffee00 (assert at ip.py:194 passes).
• Booter on SEC2 returned mailbox 0, meaning the SEC2 falcon DMA'd the 63 MB GSP-RM image out of sysmem and verified it.
• GSP RISC-V active_stat == 1 (ip.py:210).

Post-mortem (dumped after the timeout):

GSP RISCV_CPUCTL: 0x00000010      -> halted=1, active_stat=0
GSP MAILBOX0:     0x80000000      (tinygrad wrote the libos_args addr 0x5b8e4000 here and the firmware overwrote it. nouveau treats 0x80000000 as "GSP-RM halted/unloaded")
GSP MAILBOX1:     0x00000000
SEC2 MAILBOX0:    0x00000000
WPR2_ADDR_HI:     0x02ffee00
BSI_SECURE_SCRATCH_14: 0x13100000
LOGINIT/LOGINTR/LOGRM/LOGMNOC/LOGKRNL: all zero (no libos log entries, put pointers untouched)
stat queue header: all zero

So the GSP core starts running GSP-RM from WPR2, never lands a single write in host memory (no libos logs, no queue header), and halts. The SEC2 falcon's DMA reads from sysmem work. The RISC-V core's accesses do not. Leading hypothesis: RISC-V-side DMA through AppleVTD on Intel (the dext has only been exercised on Apple Silicon DARTs).

Run 3 & 4 (dart=0, SIP off, to test that hypothesis): cannot be run with this dext. Without DMA remapping the dext maps sysmem page-by-page and caps PrepareDMA at 32 segments, silently truncating (PrepareDMA size=63676416 segs=32, and with contiguous=1 even a 0x81000-byte alloc gives segs=32 covering 0x20000 bytes). Upstream tinygrad then fails with ValueError: memoryview assignment: lvalue and rvalue have different structures in init_gsp_image (radix3 build). The contiguous flag is not honoured. Two asks for the dext: return the full scatter list (or fail) instead of truncating at 32, and honour contiguous.

Attached

preflight.sh output, test_tiny-*.log, dext unified-log captures (tinygpu-*.log), run2.log (NV_DEBUG=4 register trace + dump), gsp-logbuf-*.bin, macpro-intel.diff.

gsp-statq-20260826-165205.hex.txt gsp-logbuf-20260826-165205.hex.txt

run4-dart0.log run3-dart0.log run2.log tinygpu-20260826-172440.log tinygpu-20260826-171123.log tinygpu-20260826-165059.log tinygpu-20260826-163645.log test_tiny-20260826-172440.log test_tiny-20260826-171123.log test_tiny-20260826-165059.log test_tiny-20260826-163645.log preflight-output.log