@alexc Hi, thanks for the response and for the patch! Just to clarify — we actually used your PCIe BSP fix (commit a9eaa51d) and the stock, unmodified hailo_pci 4.21.0 driver from the official Hailo GitHub (v4.21.0 tag). No changes were made to the Hailo driver side at all. Earlier in the process we had experimented with workarounds on the Hailo driver (INTx bypass + polling thread), but those were reverted completely before the final test. The report describes the end state: your kernel patch + stock driver. Result with your fix: hailo 0000:04:00.0: Enabled MSI interrupt No INTx fallback, no polling. Load average dropped from 18+ to ~12, Frigate CPU from ~485% to ~83% (real inference on 9 cameras). Regarding the GitHub PR / kernel patch — that would be great. The fix is clearly in the right place (PCIe driver), and a proper patch submission would help other Allwinner A733 users with PCIe devices.

There is only this overlay for vendor kernel: /usr/lib/linux-image-6.1.115-vendor-rk35xx/rockchip/overlay/radxa-zero3-rpi-camera-v1.3.dtbo The mainline based kernel, what you use, there is none. So you would need to port it, from this radxa03 SBC or look at other devicetree overlay files, maybe from RadxaOS, maybe from RPiOS See 'man dtc' as a start, it might be a complete renaming of a lot of the .dtso file is needed, maybe it is just an enable line.

I put image 7.1 for humanus here but now it ihas been removed due to running of space on my drive

@Sand_Death Really interesting read! Would it be possible to submit these changes through GitHub or as a kernel patch? We'd love to see the full context of the changes—the code actually provides such a clear picture of what's happening (even more so than the docs!), so a proper review of the diff would be great. EDIT: Looking at the description, it seems Claude addressed the issue on the Hailo driver side rather than fixing it in the PCIe driver. Personally, I don't think that's the ideal approach, since the BSP PCIe driver appears to be the root cause. If you get a chance to try my patch instead, I'd be interested to hear how it works for you.

@alexc I tested the modified kernel and asked Claude to report it, he reported it like this. System Refinement and Build Optimization Report Feedback 1. MSI Fix Confirmed Working Details: The MSI fix has been verified and successfully tested on Hailo8L (sun60iw2/A733 platform). Result: Massive reduction in system load: load avg dropped from 18+ to ~12, and Frigate CPU usage plummeted from 485% to 83% during real-world inference. High Priority 2. sunxi-autogen.h in .gitignore Issue: This file is currently ignored by .gitignore, yet it is strictly required for the build to succeed and is not automatically generated. Solution: Either implement automatic generation of this file inside the Makefile OR properly document the creation steps in the README. 3. Undocumented LOCALVERSION Behavior Issue: Building from a dirty Git tree automatically appends a + suffix to the kernel version string, leading to a critical vermagic mismatch for compiled modules. Solution: Document this behavior in the README or enforce proper default behavior in the default configuration file. Medium Priority 4. Missing BSP_TOP Export Issue: Running make olddefconfig crashes unless BSP_TOP=bsp/ is explicitly passed as an environment variable. Solution: Add path auto-detection directly into the root Makefile to make the build self-contained. 5. Missing DKMS Config for hailo_pci Issue: Since this is an out-of-tree module, users must manually rebuild it after every routine kernel update. Solution: Provide a DKMS configuration to automate the rebuild process on the OS level. Low Priority 6. hailo_pci Driver Integration in initramfs Issue: The module is not automatically included in the initramfs image during the build phase. Solution: Create a dedicated hook script or add a section in the documentation explaining manual configuration via modules-load.d and update-initramfs. 7. Overly Permissive /dev/hailo0 Permissions (World-Writable) Issue: The device node permissions are set to crw-rw-rw- (anyone can write to it), which poses a security risk. Solution: Deploy a standard udev rule to restrict permissions and grant access safely via a dedicated system group. !!! At the moment, I confirm that it works with these edits.