I didn’t start Photon on both machines. So the problem is not related to Photon.
I plug the hardisk of the 2nd computer to the first computer.
The problem still exists. So the problem is not related to the QNX operating system, but the hardware, CPU, BIOS, ISA, video card… The computer is a Trenton industrial computer. It has an internal video card. I didn’t find mode setting of the video card.
Here’s another theory, but no obvious way to check. The video hardware has no text mode, but processor is used in supervisor mode to emulate it.
The industrial single-board computer is Trenton T4G. It has an internal video card, Intel 845GV. The 845GV has a DVMT (Dynamic Video Memory Tech) feature, which will dynamic allocates memory for the video card. I am afraid the feature causes the problem. I don’t know how to disable it yet. I have disabled the Hyperthreading in P4 CPU. Don’t know about its supervisor modes.
Other possiblities include watchdog and system hardware monitor (monitor voltage, temperature, fan speed, etc).
I will post update later if there is any.
Hyperthreading, to my knowledge doesn’t cause such problems.
maschoen could be right. what about disabling video all together and redirecting shell to serial port? or just disable integrated video and install real video card (if it has ISA you may be lucky to find old VGA adapter)
I did install a real video card. But I didn’t find a way to disable the internal video card. It didn’t solve the problem.
I find out that there is one procnto thread at priority 255r in receive mode, when I restart the computer (no Photon). It is always the second thread out of 8 procnto threads. I guess this information is not surprising though.
Just a guess here, but I think that thread is the one that last processed the timer interrupt.
Do you guess that the timer interrupt is caused by the video driver? I saw the high-priority pronto before I run the Timer test program.
If there is a piece of hardware generating the interrupt, the hardware drivers must have long interrupt service codes or ask the CPU to emulate sth, as you suggested. Otherwise it will not affect the Timer.
Not at all. The timer interrupt is caused only by the on board timer firing.
The firing of this interrupt allows the OS to keep track of what time it is, and also provides an opportunity to schedule another thread.
Interrupt handlers should have as little code as possible. You and QNX have control over the interrupt service routines in QNX and your code.
You have no control over what happens in a supervisor call, except by trying to avoid it occuring at all. If your hardware happens to be a poor choice for a real-time OS, there is probably not much you can do.