GEustace@massey.ac.nz (Glen Eustace) (02/26/90)
I am beginning to wonder if I will ever get anything right! I have been
fighting a room full of 386SX machines for over a week and seem to be
losing every round.
Can anybody throw some light on the following behaviour. I have no idea
what components are part of the problem, my only clues are as follows.
1. I am using the Quarterdeck QEMM.SYS 386 memory manager v4.23,
I have version 3.0.1 of PC-NFS.
The machines have an AMI BIOS and MS-DOS 3.3
Case 1.
Put system disk in A: without QEMM, turn power on, boot machine.
Everything is OK.
Put system disk in A: with QEMM, reboot with Alt-Ctrl-Del.
Everything is OK, System goes beautifully in fact.
Case 2.
Put system disk in A: with QEMM, turn power on, boot machine.
System locks up immediately after running the NET START command.
must reboot with Hard-Reset.
The above is 100% reproducable.
The config.sys file is;
BUFFERS=30
FILES=70
DEVICE=A:\QEMM\QEMM.SYS RAM
DEVICE=A:\NFS\PCNFS.SYS /I0 /F70 /S
DEVICE=A:\NFS\WD8003E.SYS /i3 /p280 /md0000A
DEVICE=A:\NFS\SOCKDRV.SYS
DEVICE=A:\QEMM\LOADHI.SYS A:\ANSI.SYS
DEVICE=A:\QEMM\LOADHI.SYS A:\GENIUS\GMOUSE.SYS /11
DEVICE=A:\QEMM\LOADHI.SYS A:\CCNET\NETINFO.SYS
LASTDRIVE=V
I don't understand why it works in case 1 and not case 2......
This is how things happened.
I built my usually A:boot disk with no QEMM. I installed QEMM on the
disk, editted the config file and rebooted with Alt-Ctrl-Del. Wow!! All
of a sudden I have lots of memory. Everything worked great. Boy are our
users going to love this new environment. Turn machine off, go home for a
well earned sleep. Come in the next day and turn the machine on. Things
seem OK until it gets to the network startup and it hangs???. Who's been
fiddling with my machine, nobody. Edit out QEMM from CONFIG.SYS, reboot
and all is fixed.
--
-----------------------------------------------------------------------
Glen Eustace, Software Manager, Computer Centre, Massey University,
Palmerston North, New Zealand. Phone: +64 63 69099 x7440 GMT+12
E-Mail via Internet: G.Eustace@massey.ac.nz
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>eric@mks.com (Eric Gisin) (02/27/90)
In article <587@massey.ac.nz>, GEustace@massey.ac.nz (Glen Eustace) writes: > [...] > Case 2. > Put system disk in A: with QEMM, turn power on, boot machine. > System locks up immediately after running the NET START command. > must reboot with Hard-Reset. The WD8003 has shared memory that is mapped somewhere above 640K. This memory does not appear after power up, but does survive reboots. QEMM automatically determines whether memory above 640K is RW, ROM, or unused. This explains why you get different behaviour in case 1 and 2. In case 1 after the reboot, QEMM sees the WD8003 shared memory. In case 2 after power up, QEMM does not see it, and maps in some high memory which conficts with the shared memory the WD driver later tries to map in. All you need to do is add an EXCLUDE statement to the QEMM.SYS line, for example ...\QEMM.SYS MEM EXCLUDE=CC00-CDFF.
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (02/27/90)
In response to Glen's queries about weird QEMM behaviour, Tom Dinger (a consultant working in our SQA group) came up with the following analysis that looks very persuasive. ------------------------------------------------------------------ ASSUMPTIONS: 1. The Western digital board actually uses the on-board RAM memory, but it must be enabled by the software before it is "addressable" -- this is done by the wd80003e driver. 2. Once the memory is enabled, it remains enabled even through a system reboot (warm boot, or Ctrl-Alt-Del). Here is what I think happens: >> Case 1. >> Put system disk in A: without QEMM, turn power on, boot machine. Running without QEMM, PCNFS.SYS and WD8003E.SYS load, and enable the on-board RAM at D000:0000. >> Everything is OK. Yup. >> Put system disk in A: with QEMM, reboot with Alt-Ctrl-Del. The wd8003e keeps the on-board RAM enabled at D000:0; after the reboot, when QEMM loads, it finds RAM at that address and leaves it alone. Then PCNFS.SYS and WD8003E.SYS load, and "re-initialize" the board, also leaving the RAM alone -- everything should work. >> Everything is OK, System goes beautifully in fact. Yup. >> Case 2. >> Put system disk in A: with QEMM, turn power on, boot machine. At power up, the wd8003e card has the on-board RAM *disabled*. When QEMM starts, it does *not* find any RAM there, so it remaps extended memory to fill in the hole, using the GDT and/or LDT. Next, PCNFS.SYS and WD8003E.SYS load, and RAM on the wd8003e is enabled, but it is not mapped to any logical address in the GDT/LDT. >> System locks up immediately after running the NET START command. >> must reboot with Hard-Reset. Well, I don't know about the hard reboot, but the on-board RAM is probably not addressable, so how can any data be read/written to the board? SUGGESTED FIX: I am not familiar with QEMM, but 386MAX has CONFIG.SYS switches to exclude portions of memory, and I am sure QEMM has the same. On the QEMM.SYS line, add a switch to exclude the memory at address D000:0 from "filling," so that it remains free for the wd8003e. Hope this helps -- TD ---------------------------------------------------------------- He also bnoted that the WD driver line in CONFIG.SYS looks suspicious: >> DEVICE=A:\NFS\WD8003E.SYS /i3 /p280 /md0000A The last "A" is probably wrong... I haven't got a WD to try this on (we're waiting for systems to get shipped back from Connectathon), so interested readers may be able to confirm this analysis. Geoff Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) ------------------- On suitably-equipped systems, my .signature may be viewed as a full colour holographic image. On others, it will appear only as rather unconvincing text.