Hello, we have been running the application code example for testing purposes. To be more specific,
is the one that we have been toying with.
It has been built fine and operating without any problem but every time the program terminates with the last return statement at the last line of code,
return HAILO_SUCCESS;
the same error message keeps popping up. It doesn’t cause any visible harm or malfunction since it only happens when the application actually finishes its job, but since it keeps showing up, I got wondered what causes it and how to remove it.
The error message is following:
[HailoRT] [error] CHECK failed - Mapped buffer 1844674407212661 3728 281473381280392 not found
[HailoRT] [error] Failed unmapping dmabuf -1582937888 with stat us HAILO_NOT_FOUND(61)
I looked into the hailort codes and it seems to be from vdevice_internal.hpp, virtual hailo_status dma_unmap(void *address, size_t size, hailo_dma_buffer_direction_t direction) override
We are using hailort 4.18.0 and related drivers, firmwares and libraries FYI.
Hi @ksj,
What is the Hailo device you are using? and what platform are you running it on?
The error message comes from the DMA buffer transferring, and it might be that it’s related to the device or to the platform you are using,
The device in question is Hailo8, connected to the board with PCI-E bus and the SoC that we are using is i.MX8QM from NXP.
We are using Yocto Linux distribution that NXP offers and have added the meta-hailo layer on it to run HailoRT.
The buffer mapping errors you’re seeing during shutdown are fairly common with HailoRT and, while they might look concerning, they typically don’t affect runtime performance. Before we dive into solutions, could you first run these diagnostic commands to help us verify your setup?
This will help us confirm your device is being recognized properly and check which HailoRT version you’re running.
Once we have that information, here are the main approaches we can try:
Update to the latest HailoRT version - recent releases have improved buffer cleanup handling, especially during program termination.
Review your cleanup sequence - sometimes these errors occur when there’s an extra buffer unmap or release happening. Try checking for any redundant cleanup calls before your HAILO_SUCCESS return statement.
A simple approach that often works is to modify your return handling. Instead of returning directly from main, you could structure it like this:
int main() {
hailo_status status = run_application(); // Wrap your main logic here
return (status == HAILO_SUCCESS) ? 0 : 1;
}
This ensures more orderly resource cleanup.
If the errors persist but aren’t causing actual issues, you could adjust the logging level to suppress these non-critical shutdown messages.
Could you share the output of those diagnostic commands? That will help us determine which of these solutions would be most appropriate for your situation or should we move into other direction to solve this.
@omria Hello, I am going to share the output of the device scan, firmware identity and the version output first and then the result of the changed return statement.
Unfortunately, the error still persists.
Again, this is the result from the un-edited code, built with ./build.sh and CMakeList.txt on the source directory.
in case of adjusting the logging level, could you guide me through it? I found hailo_set_fw_logger on the document, but isn’t what I’m seeing from the library itsef rather than firmware? How should I lower the logger level for the HailoRT?
and called it on main, but the error still persists.
I think the DMA buffer driver on the platform side has its own logic to unmap the buffer whenever the application terminates -some sort of reference count logic is working? Since I’ve never seen the actual code for it, I’m not so sure, but let’s just suppose it does something like it- and HailoRT is doing the same thing.
It can be confirmed with running the same sample application with the official EVK, but since we don’t have it, there’s no way for us to confirm it…
Right now, lowering the logger level is the only option for us, I think.
@omria
I think I figured out. Turns out, ./build.sh and CMakeLists.txt are pointing to the header files of the lower version while the library is being linked with the Linux image’s current version -4.18- I took care of the discrepancy and the error has not been occurred ever since.
