QNX4 Multiple Cores


We’ve got a slew of P4 computers running QNX4 that are starting to die. So we need to buy replacements.

Does QNX4 run on multiple core CPUs? Does it use the extra cores or does it just use 1? Are there any stability issues on either the AMD or Intel platforms? Has anyone had experience with Intel’s i3,5,7 models?


It will use one core only. I do not know of any stability problem related to a specific CPU model/brand.

I also never heard of any stability issues regarding QNX4 on newer CPUs. It’s true that it only will use one core, QNX4 never was written to scale to multiple cores.

However, a Virtualization solution (RTS Hypervisor, Tenasys eVM) could make it possible to run one QNX4 per core, e.g. if you have a dual core system it could run two QNX4’s, and you could spread you apps among them.

Or, migrate to QNX6. There is a good migration guide from QNX. And QNX6 runs on multi cores and distributes ready threads automatically.

Yes, and it might run rather nicely, but doesn’t running any RT system virtually make it non RT? I guess if you wanted more throughput from QNX 4 it would be a way to get it from a dual core.

What if I wanted to use an Intel i3, i5 or i7? What graphics drivers would I have to use?

As far as I know only i3 and i5 series 6000 have integrated graphics controller, i7 is external so that depends on your motherboard. As for i3 and i5 my guess is you need to use the vga driver. I doubt any of the accelerated driver would work ( maybe the one for the 830 ?

Virtualizing QNX4, or any other RTOS, does not take away realtime capability, depending on the virtualization solution. Of course VmWare won’t do it. But Tenasys eVM or the RTS Hypervisor will. They will add very small, but deterministic latencies in some cases, but those solutions are designed to be realtime capable.

I’m actually testing the upcoming SIEMENS 847C industrial PC and it looks really good!
The onboard graphic is working (Pg.flatdc, no PG.ia830), both onboard network cards are running and there is still the ability to spend 2 PCI slots separat interrupts. The graphic outpus is a DVI but even the DVI signal is really supported.

With the upcomming 6.5.0 which support APIC sharing of interrupts should be a thing of the past.

Is there somebody (Foundry27) making a backport for QNX4?
Is the atapi driver for QNX6 similar to the Fsys.atapi?
(I enjoyed the USB pack very much! now there is also no interrupt problem any more)

Backport of QNX4 ?

Mario, I’m guessing he means to support multiple cores.
The answer to which is NO!

If desperate you could run multiple QNX 4 OS’s under a VM. I’m guessing that Virtual Net Card to Virtual Net Card communication might be quite speedy.

Dear QNX Masters,

I’m even dont think of a backport of multi core support for QNX4.
May be I’m a little stupid but this is I never will expect.

My question about backport was based on Marios statement about APIC in 6.5.0.
I have to test hardware for the usage with QNX4 and I’m always positively surprised if I can find one. And with the newest SIEMENS I’m really glad. I never have seen a DVI digital output working in QNX4 (Not the analog pins on the DVI connector).

By the way:
Running QNX4 in Xen4 is working. Even with the PCI passthrough.

Yeah forget about QNX4, all that you can expect in the future is new drivers.

Hi Mario,

do you know whether there is a possibility to change the IRQ routing in QNX4. The BIOSes are becoming more and more stupid (or “plug and play”). And it is not a problem to use on the same PC model several years.

This question was already posted, but it was not really for QNX4.

I think that the only option for QNX 4 was to specify which priority on each of the two chained interrupt controllers was highest. This was a kernel option you could send as a parameter at boot time, but only once. So for example you could have interrupt 3 be the highest, and then the order would be 3, 4, 5, 6, 7, 0, 1, 2. Since 2 was the cascade, 8-15 would then have lowest priority. You could also specify which of these interrupts had the highest priority.