[Detector Support]: Hailo-8 hailo_pci 4.21.0 driver causes kernel oops (hailo_vdma_buffer_map) — request HailoRT 5.x upgrade

[CharlesJ-1975]

Describe the problem you are having

The hailo_pci 4.21.0 kernel driver crashes with a kernel oops in
hailo_vdma_buffer_map during active inference. This occurs when Frigate
sends frames to the Hailo-8 for object detection, typically within minutes
of startup or when a detection event occurs.

The oops causes filesystem I/O errors (Errno 5) on the recordings volume,
leading to filesystem corruption and Frigate becoming unable to write
recordings or access clips.

The bug is fixed in hailort-drivers 5.x, however Frigate's container
bundles libhailort.so.4.21.0 internally. This creates a hard version
dependency — the host driver must match the bundled library version exactly,
so upgrading the host driver to 5.x is not possible without Frigate also
upgrading its bundled HailoRT.

This issue has been present and reproducible across multiple kernel versions
(6.12.74, 6.12.85, 6.12.86) and persists after clean reinstallation of the
driver. The only workaround is an automated rmmod/modprobe cycle via a
systemd watchdog service to reset the driver after each oops event.

Requesting that Frigate upgrade its bundled HailoRT from 4.21.0 to 5.x to
allow users to run the fixed host driver stack.

Version

0.17.1-416a9b7

Frigate config file

logger:
  default: info
  logs:
    frigate.record: info
    frigate.events: info

mqtt:
  enabled: true
  host: 192.168.2.14
  user: frigate-svc
  password: '{FRIGATE_MQTT_PASSWORD}'   # The one created in HAOS Mosquitto
  client_id: frigate-hailo

auth:
  enabled: false

# Use detectors, CPU for vCPU use, USB for Coral, or M.2 for Hailo-8
detectors:
  hailo8:
    type: hailo8l
    device: PCIe
    model:
      width: 320
      height: 320
      input_tensor: nhwc
      input_pixel_format: rgb
      input_dtype: int
      model_type: yolo-generic
      labelmap_path: /labelmap/coco-80.txt
      path:
        https://hailo-model-zoo.s3.eu-west-2.amazonaws.com/ModelZoo/Compiled/v2.14.0/hailo8/yolov6n.hef

# Facial recognition active; add images to /mnt/frigate/clips/faces/<person>
face_recognition:
  enabled: true
  model_size: large
#  recognition_threshold: 0.85

ffmpeg:
  hwaccel_args: preset-nvidia

go2rtc:
  streams:
    front_floodlight:
      - rtsp://admin:{FRIGATE_CAM_PASSWORD}@192.168.40.6:554/h265Preview_01_main#backchannel=0
      - ffmpeg:front_floodlight#video=h264
    front_floodlight_sub:
      - rtsp://admin:{FRIGATE_CAM_PASSWORD}@192.168.40.6:554/h264Preview_01_sub#backchannel=0

    reolink_doorbell:
      - rtsp://admin:{FRIGATE_CAM_PASSWORD}@192.168.40.5:554/h264Preview_01_main#backchannel=0
    reolink_doorbell_sub:
      - rtsp://admin:{FRIGATE_CAM_PASSWORD}@192.168.40.5:554/h264Preview_01_sub#backchannel=0
  webrtc:
    candidates:
      - 192.168.2.11:8555
      - 192.168.40.2:8555
      - stun:8555

cameras:
  front_floodlight:
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/front_floodlight
          roles:
            - record
          input_args: preset-rtsp-restream
        - path: rtsp://127.0.0.1:8554/front_floodlight_sub
          roles:
            - detect
          input_args: preset-rtsp-restream
    detect:
      enabled: true
      width: 1920   # Reolink Duo 180° Sub-stream width
      height: 576   # Reolink Duo 180° Sub-stream height
      fps: 5
      max_disappeared: 40
    objects:
      track:
        - person
      filters:
        person:
          min_score: 0.65
          threshold: 0.72
    record:
      enabled: true
      alerts:
        retain:
          days: 14
          mode: active_objects
      continuous:
        days: 7
      motion:
        days: 0
    zones:
      visitor_zone:
        coordinates:
          0.232,0.324,0.527,0.23,0.745,0.272,0.968,0.743,0.917,1,0.487,1,0.082,1,0.037,0.874
        loitering_time: 0
        inertia: 3
        objects: person
    motion:
      threshold: 30
      contour_area: 15
      improve_contrast: true
    review:
      alerts:
        required_zones:
          - visitor_zone
  reolink_doorbell:
    best_image_timeout: 120
    enabled: true
    ffmpeg:
      inputs:
        # The HIGH res stream for recording
        - path: rtsp://127.0.0.1:8554/reolink_doorbell
          roles:
            - record
          input_args: preset-rtsp-restream
        # The LOW res stream (Sub) for AI detection
        - path: rtsp://127.0.0.1:8554/reolink_doorbell_sub
          roles:
            - detect
          input_args: preset-rtsp-restream
    detect:
      enabled: true
      width: 640
      height: 480
      fps: 5
    objects:
      track:
        - person
      filters:
        person:
          min_score: 0.65
          threshold: 0.72
    record:
      enabled: true
      alerts:
        retain:
          days: 14
          mode: active_objects

      continuous:
        days: 7
      motion:
        days: 0
    zones:
      porch_zone:
        coordinates:
          1,1,0,1,0,0.715,0.334,0.627,0.334,0.79,0.424,0.726,0.487,0.745,0.57,0.624,0.834,0.63,0.822,0.786,0.99,0.784
        inertia: 3
        loitering_time: 0
        objects: person
    motion:
      mask:
        - 0.496,0.077,0.508,0.467,0.569,0.468,0.569,0.319,0.797,0.167,0.756,0.022
      threshold: 30
      contour_area: 10
      improve_contrast: true
    review:
      alerts:
        required_zones:
          - porch_zone
version: 0.17-0
record:
  enabled: true
  sync_recordings: true
detect:
  enabled: true
semantic_search:
  enabled: false
  model_size: small
lpr:
  enabled: false
classification:
  bird:
    enabled: false
snapshots:
  enabled: true
  retain:
    default: 14

docker-compose file or Docker CLI command

services:
  frigate:
    container_name: frigate
    privileged: false # Required for hardware acceleration access
    restart: unless-stopped
    env_file:
      - /opt/frigate/.env
    image: ghcr.io/blakeblackshear/frigate:stable
    shm_size: "512mb"  # Increased for 4K frames
    # ... your volumes and ports stay the same ...
    network_mode: host
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - FOWNER
      - SETUID
      - SETGID
      - DAC_OVERRIDE
    group_add:
      - "988"
    devices:
      - /dev/hailo0:/dev/hailo0
    runtime: nvidia

    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /opt/frigate/config:/config
      - /mnt/frigate:/media/frigate
      - type: tmpfs # Helps reduce wear on the NAS for small cache files
        target: /tmp/cache
        tmpfs:
          size: 1000000000
    environment:
      - PUID=1003
      - PGID=1003
      # PLUS_API_KEY: "" # Only if you have a Frigate+ subscription
      # LIBVA_DRIVER_NAME: i915 # Likely for your Intel hardware

Relevant Frigate log output

[Errno 5] Input/output error: '/media/frigate/recordings/2026-05-14/13'
OSError: [Errno 5] Input/output error: '/media/frigate/clips/faces/Charles'

Install method

Docker Compose

Object Detector

Other

Screenshots of the Frigate UI's System metrics pages

Any other information that may be helpful

Hardware: Hailo-8 full (26 TOPS, not 8L) via M.2 PCIe on Ryzen 5 3400G / B450M Pro4
Host OS: Debian Trixie, kernel 6.12.86+deb13-amd64
Installed packages: hailort 4.21.0, hailort-pcie-driver 4.21.0

Kernel oops from dmesg during inference:
hailo_vdma_buffer_map+0x90/0x500 [hailo_pci]
hailo_vdma_buffer_map_ioctl+0xc0/0x1b0 [hailo_pci]
hailo_pcie_fops_unlockedioctl+0x196/0x450 [hailo_pci]

Root cause: hailo_pci 4.21.0 bug in vdma buffer mapping, fixed in hailort-drivers 5.x.
Frigate bundles libhailort.so.4.21.0 internally, preventing host driver upgrade to 5.x due to version mismatch.

Workaround: rmmod/modprobe hailo_pci cycle restores inference. Automated via systemd watchdog.

Request: Upgrade bundled HailoRT to 5.x to allow users to run the fixed host driver stack.

[hawkeye217]

The Hailo is a community supported detector, the Hailo team may have more to say and you may be able to engage with them further on their community forums.

@giladnah @OmriAx @ronithailo @mikehailodev @hailocs

[CharlesJ-1975]

Thanks for the quick response. To clarify — the underlying bug is in the hailo_pci 4.21.0 kernel driver (hailo_vdma_buffer_map), which is fixed in hailort-drivers 5.x. The Frigate side of the fix would simply be upgrading the bundled libhailort from 4.21.0 to 5.x, which would allow users to also run the fixed host driver. Happy to engage with the Hailo team directly if they need additional diagnostic information.

[NickM-27]

As far as I understand the Hailo Driver 5.X does not support the Hailo8. In any case, we keep our driver version in line with HomeAssistant OS to ensure compatibility, and that would need to say the case unless they have solved the backwards compatibility issue.

[CharlesJ-1975]

I found the answer — HailoRT 5.x release notes explicitly state Hailo-8 support ends with 4.x. So upgrading to 5.x is not an option for Hailo-8 users.
So the fix will need to come from Hailo as a 4.x patch release addressing the hailo_vdma_buffer_map kernel oops. I'll file a bug report directly with Hailo's developer support, referencing this discussion.
For Frigate's part, no action needed unless Hailo releases a 4.22.x. I'll update this thread if a fix emerges from Hailo's side.

https://hailo.ai/developer-zone/documentation/hailort-v5-3-0/?sp_referrer=changelog/changelog.html

[mikehailodev]

Hi @CharlesJ-1975 @NickM-27 @hawkeye217,

I'm from Hailo.
Thanks for raising this topic!

We actually finishing our work to bump Frigate to a newer Hailo-8 runtime and driver versions - The upstream PR submission is very close.
I'll post here updates.

The bug itself looks like related to: https://community.hailo.ai/t/bug-report-find-vma-called-before-mmap-read-lock-issued-in-usr-src-hailo-pci-4-23-0-linux-vdma-memory-c/19001

[NickM-27]

We are not aware of any widespread issues with using a Hailo device, we have not seen any reports of this issue besides the few here.

[dskaplan]

We are not aware of any widespread issues with using a Hailo device, we have not seen any reports of this issue besides the few here.

We are not aware of any widespread issues with using a Hailo device, we have not seen any reports of this issue besides the few here.

I am a little worried that I, another user in this discussion, and this have found their system to be potentially broken by an adapter? I don't know, this is far from my area of expertise, but I do know that my unit won't stay online (not even running any containers) after removing the M.2 and replacing the boot disk.

[scyto]

I have seen no evidence this breaks anything, it appears to be just noise. I patched it on my install / drivers for truenas.

[giladnah]

Hy guys, this issue is fixed in 4.24
Sorry for the slow response you can find the updated code here:
https://github.com/hailo-ai/hailort/releases/tag/v4.24.0
https://github.com/hailo-ai/hailort-drivers/releases/tag/v4.24.0

It was released yesterday, will take time to waterfall to Rpi, HA and off course Frigate.

[antiphotom]

Interim workaround for anyone on Frigate 0.17.x, plus a separate PCIe gotcha

First — thanks to @giladnah for the fix in hailort-drivers 4.24.0, and to everyone earlier in this thread who diagnosed the mmap_lock problem. None of the kernel diagnosis below is mine — I just applied it and can confirm it works.

I'm posting because there's a gap while 4.24 waterfalls down to Raspberry Pi OS, HA and Frigate: Frigate 0.17.2 bundles libhailort 4.21.0, and the host driver has to match the bundled library exactly. Installing the 4.24 driver today gives you Driver version (4.24.0) is different from library version (4.21.0). So anyone hitting this bug right now can't simply take the official fix — they either build a custom Frigate image, or backport the one-line change into 4.21. This post is the second option, plus a completely separate hardware problem that 4.24 doesn't address.

Setup

Raspberry Pi 5 (8GB), Raspberry Pi OS Lite 64-bit, kernel 6.18.34+rpt-rpi-2712
Hailo-8 M.2 2242 module (26 TOPS, HM218B1C2FAE) — not an 8L, and not the official AI HAT+. Mounted on a Waveshare PoE M.2 HAT+, an M.2 carrier intended for NVMe SSDs
hailort-drivers 4.21.0 via Frigate's docker/hailo8l/user_installation.sh
Frigate 0.17.2 (Docker), 6 cameras, 1280x720 detect streams @ 5fps
Part 1: backporting the 4.24 mmap_lock fix into 4.21

Symptoms: detection works for a few frames, then inference pegs at ~1005ms, detector memory climbs, detector CPU flatlines, per-camera detect toggles revert themselves to off. /tmp/cache fills to 100% within ~5 minutes because the recording maintainer dies with the detector, producing No space left on device from ffmpeg on every camera. The container then becomes unkillable (tried to kill container, but did not receive an exit event).

task:frigate.detecto state:D
  rwsem_down_write_slowpath
  down_write
  exit_mmap
  mmput
  do_exit
INFO: task frigate.detecto is blocked on an rw-semaphore, but the owner is not found.

The fix is to hold mmap_lock around find_vma() in linux/vdma/memory.c. One thing worth noting if you're applying this by hand: the vma pointer is also dereferenced after the find_vma() call (is_dmabuf_vma, create_fd_from_vma), so the lock needs to be held across the whole block rather than just the call itself:

diff
     if (HAILO_DMA_DMABUF_BUFFER != buffer_type) {
+        mmap_read_lock(current->mm);
         vma = find_vma(current->mm, addr_or_fd);
         if (IS_ENABLED(HAILO_SUPPORT_MMIO_DMA_MAPPING)) {
             if (NULL == vma) {
                 dev_err(dev, "no vma for virt_addr/size = 0x%08lx/0x%08zx\n", addr_or_fd, size);
+                mmap_read_unlock(current->mm);
                 ret = -EFAULT;
                 goto cleanup;
             }
         }
 
         if (is_dmabuf_vma(vma)) {
             dev_dbg(dev, "Given vma is backed by dmabuf - creating fd and mapping as dmabuf\n");
             buffer_type = HAILO_DMA_DMABUF_BUFFER;
             ret = create_fd_from_vma(dev, vma);
             if (ret < 0) {
                 dev_err(dev, "Failed creating fd from vma in given dmabuf\n");
+                mmap_read_unlock(current->mm);
                 goto cleanup;
             }
             // Save original dmabuf user address in dmabuf_from_pointer_addr and override addr_or_fd with fd
             dmabuf_from_pointer_addr = addr_or_fd;
             addr_or_fd = ret;
         }
+        mmap_read_unlock(current->mm);
     }

Rebuild with cd hailort-drivers/linux/pcie && sudo make all && sudo make install && sudo reboot. The version string stays 4.21.0 either way, so compare md5sums of the .ko to confirm which build is loaded.

⚠️ Placement matters — this bit me. On my first attempt I put the final mmap_read_unlock() inside the if (IS_ENABLED(HAILO_SUPPORT_MMIO_DMA_MAPPING)) block. That macro isn't defined on Pi 5, so the unlock compiled out entirely and every inference leaked a read lock — hard deadlock in exit_mmap, reboot required, worse than the original bug. The final unlock must be the last statement inside the if (HAILO_DMA_DMABUF_BUFFER != buffer_type) block. Sanity check after editing: exactly 1 mmap_read_lock and 3 mmap_read_unlock in that block.

Obviously once Frigate ships a container with 4.24 bundled, throw this away and run the official driver — a local kernel patch isn't something you want to maintain across kernel upgrades.

Part 2: PCIe Gen 3 instability on a third-party M.2 carrier (separate issue, not fixed by 4.24)

With the patch applied, detection ran cleanly for several hours — then failed differently:

hailo 0001:01:00.0: Device disconnected while opening device
...
hailo 0001:01:00.0: Probing: mapped bar 0 / bar 2 / bar 4   (all succeed)
hailo 0001:01:00.0: Probing: Failed reading device BARs, device may be disconnected
hailo 0001:01:00.0: Probing: Failed init pcie resources

lspci still listed the device (config space intact) but it stopped responding to register reads. /dev/hailo0 disappeared and wouldn't return on rmmod/modprobe or a warm reboot — only a full power cycle recovered it. Frigate then crash-looped because the compose file hard-requires /dev/hailo0.

This is not the mmap bug: no hung tasks, no find_vma warnings, and vcgencmd get_throttled was 0x0 throughout, so not a power problem either.

I had dtparam=pciex1_gen=3 in /boot/firmware/config.txt. Changing it to:

dtparam=pciex1_gen=2

fixed it. 24+ hours of continuous detection since, RestartCount 0, and zero PCIe correctable errors (CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- across 400+ samples logged at 1-minute intervals). Inference unchanged at ~12ms — Gen 2 x1 is ~500MB/s and the detector only moves 320x320 tensors at 5fps, so there's nothing to lose.

My guess is that a bare M.2 module on a PoE carrier board designed for NVMe has less signal margin than the official AI HAT+, and Gen 3 was marginal. If you're on a third-party M.2 carrier and seeing "Failed reading device BARs", try Gen 2 before assuming it's a driver bug. I spent a day chasing this as a software problem.

Two other Pi 5 gotchas, in case anyone is stuck before they reach either of the above

1. /etc/modprobe.d/hailo_pci.conf containing options hailo_pci force_desc_page_size=4096 — without it the detector dies at startup with max_desc_page_size given 16384 is bigger than hw max desc page size 4096. This is in the Frigate docs.
2. The model must be the 8L-compiled HEF even on Hailo-8 hardware. Frigate's auto-select downloads the hailo8 HEF when it detects a Hailo-8, and that model can't be configured on a Pi 5 (same 16KB descriptor page limit). Pinning it explicitly:

yaml
detectors:
  hailo:
    type: hailo8l
    device: PCIe

model:
  width: 320
  height: 320
  input_tensor: nhwc
  input_pixel_format: rgb
  input_dtype: int
  model_type: yolo-generic
  labelmap_path: /labelmap/coco-80.txt
  path: https://hailo-model-zoo.s3.eu-west-2.amazonaws.com/ModelZoo/Compiled/v2.14.0/hailo8l/yolov6n.hef

The resulting HEF was compiled for Hailo8L device, while the device itself is Hailo8 warning is then expected and harmless (~3ms of inference).

Caveats

• Soak testing: ~22 hours with one camera detecting, then rolled out to all six. /tmp/cache oscillates 3–24% with a clean hourly sawtooth (no monotonic climb), shm steady, SoC 52–60°C, zero restarts, zero PCIe errors throughout.
• I changed two things (the patch and the PCIe generation), so I can't fully isolate which fixed what — but the failure modes were clearly distinct: the mmap bug produced hung tasks within minutes, the Gen 3 problem produced BAR read failures after hours.
• I'm not a kernel developer, and the backport above is just the 4.24 change applied to 4.21 — if anyone spots a reason create_fd_from_vma() isn't safe to call under mmap_read_lock, please say so.
• Diagnosis worked through with AI (Claude) assistance; all testing and measurements on my own hardware.