Here is the problem I am running into....
Environment is vxWorks 6.4, Workbench 3.0
I have a Corvalent systems motherboard "http://www.corvalent.com/02b_ind_boards/q35atx.shtml" with Intel® Core™ 2 Duo E6400 processor and 2 Gig RAM.
I used to run on another motherboard with a Pentium 3 processor and i Gig RAM. No issues.
On the new Corvalent board, I have built my bootrom and vxWorks image for a pentium 4 (single core) and the image builds and runs with no issues until the following:
The system boots ok, downloads the image and vxWorks starts initializing when I get a "Virtual Memory Overlap at sysPhysMemDesc[9]" error and dies.
I have two PCI cards that gets mapped. One is an in house developed data acquisition card and the other is an off-the-shelf NI GPIB card. Both are not new cards and used to have no problems in other earlier mother boards like the pentium 3.

It appears that vxWorks is trying to map these inside sysHwInit () and ends up with the error I mentioned above and dies.
If I map only one of the boards inside sysHwInit () during start up(does not matter which one), then everything is ok but I don't have one of the boards unavailable.
I also swapped the order in which they are mapped and it has no effect, I still get the error and the system dies.
The memory requirements for the two PCI boards is as follows:
In-house dev data acquisition board requires - 0x80000 bytes of memory space.
The NI GPIB board requires - 0x4000 bytes of memory.

A vxWorks 6.4 bootrom and images built for a pentium 3 board comes up and maps both boards successfully and no issues. The Pentium 3 board has 1 Gig RAM and the newer Corvalent board has 2 Gig RAM.

The other problem I have is a lack of debug info to help me see what is happening during vxWorks startup.
I tried using both logMsg() as well as printf() as well as other debug print calls without success.

Is there something in my config.h that needs to be modified ?
I looked in sysHwInit () and it appears that these are the only two PCI cards that look like being mapped last. Who/what else could be doing the virtual memory overlap...?

Thanks for the help/info in advance...

Chuchu...