+1 on this exact issue, with additional fine-grained data that may help narrow down the root cause.
## Environment
- Raspberry Pi 5 (8GB), Pi OS Trixie, kernel **6.12.47+rpt-rpi-2712** (16K page)
- HAILO10H AI HAT, PCIe Gen3 8 GT/s **x1 (downgraded from x4)** — matches OP
- ASPM off, swiotlb=65536 attempted (no effect)
- HailoRT 5.3.0 **and** 5.1.1 full stack (host driver + lib + SoC FW) — both reproduce
- All hailort-pcie-driver / hailort packages from dev-public.hailo.ai
## Decisive new datapoint: input-size threshold
Wedge is **not** a blanket “vision fails” — it’s bound to input tensor size:
| HEF | Input | Contexts | Result |
|—|—|—|—|
| resnet_v1_50_h10 | 224×224×3 (~150 KB) | 2 | 
307 fps, dmesg clean |
| ssd_mobilenet_v1 | 300×300×3 (~270 KB) | Single | 189 fps, dmesg clean |
| Qwen2-VL `qwen2_vl_encoder` | 336×336×3 (~330 KB) | 135 | 
wedge |
| nanodet_repvgg | 416×416×3 (~520 KB) | Single | wedge |
| yolov11m_h10 | 640×640×3 (~1.2 MB) | 4 | wedge |
| Qwen2-VL `base_model__prefill` | ~2.3 MB | 161 | wedge |
**Threshold lives between ~270 KB and ~330 KB of input.** Context count is not the driver — single-context 416 also wedges, multi-context 2-ctx 224 works.
Text LLM via `hailo-ollama` (qwen2:1.5b) works fine (1.4 s/response). So SoC and control plane are alive — only the host→SoC vDMA pathway with input above the threshold wedges.
## Wedge signature (16K kernel)
```
hailo1x 0001:01:00.0: Failed to launch transfer (repeated)
hailo1x 0001:01:00.0: Timeout waiting for soc control (timeout_ms=1000)
hailo1x 0001:01:00.0: soc_close failed with err=-110 (ETIMEDOUT)
hailo1x 0001:01:00.0: Device disconnected while opening device
```
Recovery requires `sudo reboot` — modprobe reload fails because the PCIe BARs are torn down (`Failed reading device BARs`).
## What I tried (no effect on wedge)
1. HEF compiler version aligned to runtime: v5.0.0 / v5.1.0 / v5.1.1 / v5.2.0 / v5.3.0 (parse-hef confirmed) — all same wedge.
2. `force_desc_page_size` modprobe option: 2K / 4K (default) / 16K — all same wedge.
3. `swiotlb=65536` (128 MB bounce buffer confirmed in dmesg) — no effect.
4. `cma=512M` cmdline — no effect (and Pi 5 may silently ignore it).
5. `hailortcli run2 --scheduler-threshold 1 --framerate 1` (`–batch-size` and `–mode raw_sync/full_sync` are `HAILO_NOT_IMPLEMENTED(7)` on H10 — “use InferModel instead”).
6. Physical PCIe FFC cable reseat.
7. PCIe link is already Gen3 8 GT/s after `dtparam=pciex1_gen=3` + `pcie_aspm=off` in /boot/firmware (those changes do hold).
## 4K page kernel attempt — different failure mode, also blocked
Switched to `kernel=kernel8.img` (kernel `6.12.47+rpt-rpi-v8`, `getconf PAGESIZE` → 4096). Rebuilt `hailo1x_pci.ko` from `/usr/src/hailort-pcie-driver/linux/pcie/` against the v8 kernel headers — module loads, driver init OK, SoC FW boots.
But `fw-control identify` now fails immediately with:
```
[HailoRT] [error] Ioctl HAILO_VDMA_BUFFER_MAP failed due to invalid address
[HailoRT] [error] CHECK_SUCCESS failed with status=HAILO_INVALID_OPERATION(6)
dmesg: hailo: get_user_pages failed with -14 (EFAULT)
dmesg: hailo1x 0001:01:00.0: failed to set sg list for user buffer -14
```
The `mmap_read_lock` fix from [#19001]( Bug report: find_vma() called before mmap_read_lock() issued in /usr/src/hailo_pci-4.23.0/linux/vdma/memory.c ) is already applied in the 5.x driver source at `linux/vdma/memory.c:175-177`. The EFAULT we see is from `get_user_pages_compact()` at `memory.c:637`, not the `find_vma` path.
To rule out the 16K page assumption in libhailort, I went further: cloned `hailo-ai/hailort` at tag `v5.3.0`, ran `cmake -DCMAKE_BUILD_TYPE=Release && cmake --build` on the 4K kernel host, replaced the installed `/usr/lib/libhailort.so.5.3.0` + `/usr/bin/hailortcli` with the natively built binaries. **Same EFAULT.** So the failure is not in user-space page assumptions either — it sits between `get_user_pages_compact` and the SG ring on the SoC side.
## Summary
- 16K page kernel + any compiler / driver / PCIe / desc page size combo: vDMA wedge for input > ~270 KB.
- 4K page kernel + matched-page driver + source-built libhailort: `get_user_pages` EFAULT, no inference possible.
- Text-only path (hailo-ollama qwen2:1.5b) works on both — so the device, control plane, and small-burst vDMA are fine.
The input-size cleavage is the strongest hint I can offer: something in the host↔SoC vDMA pipeline can’t handle SG descriptor counts beyond what ~270 KB of input generates on a Pi 5 16K-page host.
Is there an ETA on the fix Michael mentioned earlier in this thread? Happy to provide further dmesg traces, lspci dumps, or run reproducer commands you specify.