Ghost Solution Suite

Hi,

Is there a way for you to get the Ghosterr.txt file? It could be difficult since PXE maps floppy out, but you may be able to copy it to a USB or HD.

If this is not possible, could you see the fist few lines of the error file?

Krish

From reviewing the source, 19903 is an internal error in Ghost when trying to set up some internal resources to begin the multicast transfer; the most likely reason it would happen is running out of memory, but to find exactly which path leads to this happening you'll need to use an additional logging switch on the Ghost command line.

If you set this switch via "-JL:E=neterror.txt" then a more detailed internal error log will be written to a file named "neterror.txt". You'll want to get this file for us as well.

When Ghost connects to GhostCast, it does a short TCP/IP phase to get some basic data about the session then disconnects the TCP/IP connection and switches to multicast. This error is happening during that switchover, and the reason seems to be that Ghost is out of memory - this is something we do see on some machines.

The thing with DOS PXE boot packages is that the boot package contains a hard-disk or floppy-disk emulation driver, and the image data gets stored in "extended" memory usually between the 1Mb and 16Mb boundary. There are a set of about three BIOS information APIs from different vintages of the PC era that describe the amount of installed memory, and one from the PC/AT era covers the 1Mb-16Mb memory range.

The disk emulation in the boot package typically hooks this API and then returns fake numbers from it to try and fool other code into thinking the memory it's using isn't there at all.

There's also a second BIOS API from a later era that describes more memory (from 16Mb to about 64) and then yet another much later API that can describe all the memory installed in the system. Sorting out all this confusion is ... quite complex, and it does appear that some BIOSes may behave differently as well to add to the mix.

The net result is that on some machines, both Ghost and the PXE package only see the first 16Mb of memory (or at least, some rather smaller amount than what's really installed) based on the interaction of the chipset and BIOS with them. The information in the GHOSTERR.TXT will tell us more about what Ghost thinks is installed based on the BIOS APIs that it uses, and from that we might be able to work out what our options are.

I've been working on this with QA and there are some things to confirm, along with an idea of a possible workaround. Something that may be useful in addition to the GHOSTERR.TXT is some data from this DOS utility I whipped up to help investigate this.

Here's some sample output from this for a 32Mb VMware VM - it's best to run this from a boot floppy or bootable USB keyring without HIMEM.SYS installed so it can see the raw BIOS numbers.

1588         30656kb = 0x01df0000
15e801 low   15360kb = 0x00f00000
15e801 high  15296kb = 0x00ef0000
E820 memory table:
00000000 0009f800 00000001
0009f800 00000800 00000002
000dc000 00024000 00000002
00100000 01df0000 00000001
01ef0000 0000f000 00000003
01eff000 00001000 00000004
01f00000 00100000 00000001
fec00000 00010000 00000002
fee00000 00001000 00000002
fffe0000 00020000 00000002
15E820 total 31680kb = 0x01ef0000

Now, on to the theory. It turns out that with the 3COM PXE server, our QA folks found that the 3COM boot packages did not work well with Ghost - running it corrupted the in-memory copy of the boot filesystem. The reason for this turns out to be a design error in the 3COM Floppy emulation that doesn't interact with protected-mode DOS programs well, but our QA people found a workaround for this by using HIMEM.SYS (which it does notify of the memory it uses) in the boot packages we build....

...which works, but it turns out that the IBM PC-DOS version of HIMEM.SYS has a design limit of its own, which is that it's unaware of the more recent BIOS APIs for determining all the memory in a system. It uses the first two APIs my tool reports on, so it's effectively limited to 64Mb of memory. This isn't normally a problem, except that...

...a few machines have design flaws in their BIOSes, which means that although they support all the various memory-reporting APIs, their implementation of the oldest one (INT15/AH=88) for some reason reports only 16Mb of extended memory instead of the 64Mb it is capable of reporting. If you look at my sample above, the first line being reported is 32Mb, but some BIOSes never report more than 16Mb even though they could report more.

Because reporting less memory through this API is also a well-established convention for disk emulators (like the IBM RIS system, as well as PXE) to hide their memory from DOS extenders and HIMEM.SYS, the PC-DOS version of HIMEM.SYS on these machines only registers 16Mb of usable extended memory.

The end result of this cascade of small faults can be problems like the one you are observing. I've done some work on how we can resolve this fully in future versions, but for now it would be good to confirm which of the above factors are really at play in your environment.

In the short term, if you are using PC-DOS then using MS-DOS may help; the reason is that the HIMEM.SYS used in MS-DOS V7 (the Windows 9x editions) is aware of the INT15/AX=E820 BIOS API because Windows was itself reliant on that. Indeed using the MS-DOS HIMEM.SYS by itself in the PC-DOS boot packages may well be all you need. Unfortunately we can't supply that for you but it's something to try.