Xref: utzoo comp.protocols.nfs:724 comp.sys.ibm.pc.programmer:129
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!lll-winken!sun-barr!newstop!east!hinode!geoff
From: geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.nfs,comp.sys.ibm.pc.programmer
Subject: Re: QEMM 386 and PC-NFS
Message-ID: <1623@east.East.Sun.COM>
Date: 26 Feb 90 19:41:54 GMT
References: <587@massey.ac.nz>
Sender: news@east.East.Sun.COM
Reply-To: geoff@East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Followup-To: comp.protocols.nfs
Organization: Sun Microsystems PC-NFS Engineering
Lines: 75

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.