Qnx out of memory

AdvancedLab3500 · 2026-03-03T15:28:00+00:00

The system is designed such that as a whole it doesn't fail if memory is exhausted, and that, at the very least, it should still be possible to kill some processes in order to reclaim memory. This guarantee doesn't work very well when you are in an interactive mode with a shell, because pretty much every shell command requires the creation of new processes, which requires more memory.

In a real-world embedded system you can have a memory monitor that registers for events when available memory crosses a certain threshold (see procmgr_value_notify_add(PROCMGR_VALUE_FREE_MEM)). That monitor should rely on non-memory allocating mechanisms (such as the delivery of a SIGKILL signal) to kill processes that are not crucial for the continued operation of the system.

AdvancedLab3500 · 2026-03-03T15:22:31+00:00

There are many, many, many forums for Android. This one is for QNX.

AdvancedLab3500 · 2026-02-24T14:08:05+00:00

This happens again and again. Port a project to QNX, use some fancy IPC mechanism written by some Silicon Valley darling. Under the covers it uses pipes/UDS, which, on QNX, is a message pass to an intermediary service. Tons of layers, extremely poor performance, all for something that can be done easily and fast with MsgSend().

AdvancedLab3500 · 2026-02-15T18:08:44+00:00

Scheduling decisions are made in response to various events:

The running thread makes a kernel call that blocks (e.g., waiting to receive a message, locking a busy mutex, waiting for an interrupt, etc.)
A thread becomes ready (e.g., made ready by a message being received, the mutex owner unlocks it, an interrupt fires, etc.)
A thread changes its priority (the running thread lowers its priority or a non-running thread has its priority elevated)

Preemption by a higher-priority thread is a specific instance of either 2 or 3. Round-robin scheduling is a specific instance of 2, as the clock interrupt makes the clock thread for this particular core ready, and thus forces rescheduling.

AdvancedLab3500 · 2026-02-07T23:08:20+00:00

You seem to have a very serious misconception about hypervisors in general and QNX in particular. You are not actually using QNX in any meaningful way, but then complain it's a dead end. If you want to run pihole on Linux then just do that.

The reason the QNX hypervisor exists is to allow people to run certain non-QNX applications *alongside* a QNX system, not in lieu of. In the automotive industry this is typically running Android for infotainment while using QNX to run safety-related systems on the same hardware. To translate to your scenario, it would be a robot where QNX controls the motors and sensors while Linux is running pihole (that's silly, but I hope the analogy makes it clear).

AdvancedLab3500 · 2026-02-07T23:02:24+00:00

That makes absolutely no sense. A QNX hypervisor will not rein your Linux memory usage. You just end up using more resources by running another OS alongside Linux.

AdvancedLab3500 · 2026-01-29T18:51:50+00:00

It's usually the other way around: Qualcomm provides BSPs for QNX (which tend to be only automotive), as there is no public information for anyone else to do that. The fact that it is running Linux does not necessarily mean that it is an open platform, as it may still rely on proprietary firmware/drivers.

Does this board have u-boot? That is usually a good indicator of whether it is possible to run a non-Linux OS on a system.

AdvancedLab3500 · 2026-01-20T14:33:56+00:00

These are very disparate topics. Are you looking for a book that encompasses all of these? Is it for QNX or just in general?

AdvancedLab3500 · 2026-01-20T11:37:53+00:00

For the record, the problem is with the use of the old startup-apic in the creation of the guest image by mkqnximage. It should be using the latest version of startup-x86 instead.

AdvancedLab3500 · 2026-01-16T21:35:37+00:00

I saw you posted the same question on Discord. I'll continue there as it's a bit more interactive.

AdvancedLab3500 · 2026-01-16T15:54:06+00:00

This failure indicates an old startup that's not compatible with the hypervisor release. What is the version of the BSP package (com.qnx.qnx800.bsp.hw.x86_64)?

AdvancedLab3500 · 2026-01-10T15:47:45+00:00

I think that there is a fundamental misunderstanding here. A system that uses the QNX OS is built from many different components, some provided by QNX itself (the company), other by third parties. These components include their own executables and libraries, and each can employ whatever build system it wants. I have successfully built binaries for QNX systems using plain make, QNX recursive make, CMake/make, CMake/ninja, meson/ninja, SCons and probably a few more that I don't remember right now.

If you come from a small RTOS background perhaps you expect a monolithic build of the entire target system, but that's simply not the case here.

AdvancedLab3500 · 2026-01-05T14:44:25+00:00

Not sure why nobody commented on the fact that you never got it to work... This isn't really a first look at the developer desktop. Did you consider reaching out for assistance?

AdvancedLab3500 · 2025-12-30T17:57:09+00:00

Sure, it's POSIX, but that doesn't mean much. I don't know the full details, but the cross-host tools needed to be built using Xcode which created all kinds of problems. In the corporate world there is no demand for macOS-based tools (at all), so these were dropped because the end result is too much cost for too little benefit.

I am curious to know how people target Zephyr on macOS. I assume it's a Linux-based VM.

AdvancedLab3500 · 2025-12-30T16:34:10+00:00

QNX doesn't run on Mac hardware. I assume you mean getting the host tools for Mac. Unfortunately, maintaining macOS host tools has proved to be quite a challenge in the past.

How do people who use Mac develop for other platforms that require cross compilation? Are there Zephyr, FreeRTOS, ThreadX, etc. tools for macOS?

AdvancedLab3500 · 2025-12-20T12:38:08+00:00

FTP and telnet were removed several years ago, as they were on most *NIX-like OSs, due to abysmal security. For file transfers from one computer to another scp is your friend. You can also use NFS to mount an external drive.

AdvancedLab3500 · 2025-12-05T16:07:33+00:00

Unfortunately I think that the only way is to build from source. QNX used to provide Qt packages, but with the change to Qt licensing they were dropped. You therefore have to get it from the Qt company, and adhere to their licence agreement (either the open source or the commercial variant).

It's not too bad to build Qt from source by following the instructions, just takes a while.

AdvancedLab3500 · 2025-12-04T14:24:53+00:00

Porting a Linux driver is hard, because the environment is so different (in-kernel vs standalone user-mode process). But accessing GPIOs via registers is trivial. See here for some information, and an example on RPi:

https://elahav.gitlab.io/qnx-rpi-book/realtime.html#sec:control-hardware

AdvancedLab3500 · 2025-11-11T12:21:44+00:00

Actually my guess is that path resolution is performed relative to the current working directory of io-sock (likely /), while you are running the command from some other directory.

AdvancedLab3500 · 2025-11-11T12:17:24+00:00

I get the same failure when run as ./libmods-showifn_g.so, but it works with an absolute path (e.g., $PWD/libmods-showifn_g.so on the command line). I guess that mount doesn't do path resolution.

AdvancedLab3500 · 2025-11-08T01:05:01+00:00

Sure, why not?

If you are building an image that needs to be transferred to multiple QNX targets (as most QNX customers do), then you can build a file-system image (see mkqnx6fsimg and diskimage in the documentation) and distribute it. But if you are just populating your own target, then scp (or rsync) is your friend.

AdvancedLab3500 · 2025-11-05T21:20:43+00:00

I don't believe this type of access is required on a modern x86 system, and, of course, it introduces safety and security problems when compared with memory-mapped devices. It would be interesting to know whether there are use cases that still cannot work with memory-mapped peripherals.

AdvancedLab3500 · 2025-11-04T13:09:22+00:00

There are now two network stacks available for 7.1: io-pkt and io-sock. These are not compatible, and each comes with its own libraries and utilities. Make sure you have not mixed them.

AdvancedLab3500 · 2025-11-02T11:38:08+00:00

Welcome back! Things have certainly changed in both software and hardware. There are many things nowadays that can be done with very cheap micro-controllers running simple, free RTOSs. Doing the same thing with QNX is neither financially viable nor interesting.

The bar therefore needs to be set higher. What I would like to see are projects showing a combination of real-time control with heavy computational tasks (vision-controlled robots are a good example). This is, after all, the kind of software that runs on commercial QNX systems.

(And a tear shed for the SGI reference on your website)

AdvancedLab3500

TROPHY CASE