Kernel Dump msg S/C/F 11/2/11 - Page fault

Right now the io-display uses devg-vga.so. Should i use devg-intelHd.so as my pci output shows
Class = Display (VGA)
Vendor ID = 8086h, Intel Corporation
Device ID = 116h, Unknown Unknown

device ID 0116h is:
Chip Number: intel core i3
Chip Description: Intel HD Graphics 3000

Or should i use devg-i830 or devg-i810? Has anyone tried this before?

Run the

$ pci

command.

Look up the Vendor-ID:Device-ID in QNX’s hardware web resource. This will tell you which if any native driver to use. Or just try them all and see which works.

Also I don’t see any utilisation in io-display driver.
So you are using “gf”. What display driver? vesa? svga?

pidin mem shows devg-svga.so

The “svga” driver is switching the processsor to “real” (16-bit) mode and back (to 32-bit) whenever it needs to run svga BIOS code. I suspect that is behind the kernel crash.

You should try the intelhd driver. Try specifying the vid/did on the command line if it does not automatically load. (i830/i810.gma9xx drivers are mostly for Atom parts - unlikely to work on i3).

In Qt are you using widgets or QML? QML tends to be more efficient than the traditional widgets from my experience.

Does making the processor switch between real mode and 32bit mode causes more overhead?

And intelhd does not do the switching to real mode?

Qt is base on widgets.

Yes, quite a bit.

That is right. The switching to real mode is to take advantage of the real mode BIOS code which is on the video card. Since QNX is running in virtual mode, to execute this code requires switching modes. A native driver knows how to talk to the hardware directly so it doesn’t need the BIOS and therefore doesn’t need to switch.

Most Qt programming is based on widgets, yes. But QML is language provided with Qt that allows programming outside of widgets.

en.wikipedia.org/wiki/QML

Does making the processor switch between real mode and 32bit mode causes more overhead?
Not only does it cause overhead, it introduces jitter to the real-time scheduling. BIOS code can never be pre-empted since 32-bit QNX interrupt-handlers (and the scheduler) can’t run during real mode.

After using Intelhd the gui utilization reduced atleast by 24%. But the intelhd driver that came with 6.5 sp1 installation showed a black screen, downloaded the experimental driver and it worked. So far haven’t seen the issue.

Thanks the inputs.

Is svga driver not safe to use? Does Intelhd affect 3d rendering?(for now I have tested only 2d rendering)

Switching back and forth between virtual and real mode requires BIOS support. It’s possible your crash problem is related in a deficiency in the BIOS.

[/quote]
If by 3d rendering, you mean using Open GL ES, the Open GL ES code either works purely in software or takes advantage of hardware acceleration. If the video chip you are using is supported, then you will get much faster 3d rendering then if not. I don’t know if the intelhd is supported.

Running the application binaries from disk(CFast card read speed 200MB/s) vs from RAM (also my GUI process is like 19MB). Can this contribute to page faults when the CPU utilization is high?

Not unless there is a kernel bug (unlikely) or a hardware problem (more likely).