Are there any known issues in running QNX 4.25 on Pentium 4 processors running at 2.8GHz?
What I am trying to gauge is whether the issues I am having are hardware-related, or issues with the operating system.
Issues:
The clock speed on boot-up is not reported correctly. Is this something to worry about? (It can be anywhere from 18Mhz to 907MHz- random)
Sometimes it stalls during boot-up without even getting to QNX loader message. Ideas?
There are also intermittant problems with networking (using ethernet card w/ Intel 82559ER chip and one with a DEC 21041 chip). Sometimes the PC can’t be telnet’ed to (freezes after IP address identification).
The PC is brand new (industrial), this is a foray into new & modern equipment (fastest PC to date is 750Mhz - which runs the same applications just fine.).
Any ideas or similar experiences would be appreciated…
How aer you reading the “clock speed”? The counter shown on ‘sin info’ is not the clock speed although I would not expect it to vary that much.
If you are not getting the “Press ESC to load alternate OS” (or whatever), I suspect you may have hardware problems - that message comes from the primary boot loader (before QNX is loaded) and it would indicate that something else (hardware) is broken.
Miss calculation of CPU clock is not an issue unless you are using that value in your program, available from qnx_osinfo().
We are having some problem with SBC that for some strange reason required the OS to support ACPI which QNX4 doesn’t. All PCI device get assigned the same interrupt number which seems to create havoc.
Is there an official stance as to whether the qnx_osinfo clock speed is used by any of the QNX supplied (or third party supplied) drivers for hardware - we use network cards, graphics cards, PCL818HG analogue interface cards, etc. If the speed is misreported this may cause problems similar to the QNX2 problems years ago I guess.
Are QSSL still supplying patches for Qnx4? e.g. photon doesn’t appear to support the onboard 3d graphics card on some newer boxes, and vga mode is painful to watch as its extremely slow (particularly with 32bit colours) and flickers a lot while updating.
The “cpu speed” is calculated figuring out how many times a short loop can be run in as close to 3ms as can be determined. The #clocks taked by the short loop is known by cpu type (386,486,586,…), so if the newer cpus haven’t been accounted for in the table, it won’t be able to detect the speed. Of course, this was in the days before cpu timestamp counters; so for newer cpus:
wait until timer changes.
save tsc
wait for n ticks of timer to pass
save ntsc
cpuspeed = (ntsc-tsc)/(TimerPeriod*n)
would fix it up.
So I should assume then that if the OS clock speed (noted on bootup at loader stage, and using sin info) is wrong, that it is hardware that is definately unsupported by QNX for QNX4 (currently and in foreseeable future) and there could potentially be all sorts of problems with QNX4 drivers that use the estimated clock speed in timing loops, but nobody has found anything concrete in this regard.
I’m not aware of any driver that use this value. I’ve beeing using a P4 and AMD machine that have their CPU clock miscalculated and have had NO problem so far.
Personaly I’ve got bitten by problem when my own software used that value.
As for update to QNX4 I wouldn’t hold my breath… As for graphics drivers, support is there for somewhat recent graphics chip, (Radeon being one of them).
hehe, that was the reason we chose to use the industrial standard GUI system: X Window
Now we have a much better graphics card support, and are in a much better position if we want to switch to QNX 6 or other Unix. The GUI part will be just a matter of recompile
