[comp.protocols.nfs] PC-NFS and 386SXs

GEustace@massey.ac.nz (Glen Eustace) (02/14/90)

We are having problems with PC-NFS and all of our 386SX machines.  All of
these machines have Expanded Memory, a 2Meg machine being the smallest
configuration we can buy.

We make extensive use of Russ Nelson's Freemacs editor but have found
that when editting files on network drives the machines hang when the
file is saved.  This does not happen on any other type of machine and
does not always happen on the 386SXs either.  The frequency of hangs is
probably about 80% of saves.

Russ has been very helpful at trying to help us solve this problem as we
haven't found any other software which fails.  However, it is starting to
look like the problem is not Freemacs but PC-NFS.  We run the BLIP option
of PC-NFS all the time as an indication of network activity.  When one
types the ^X^S, the BLIP blinks a couple of times then comes on solid -
the machine is now hung.  Russ assures me that Freemacs is doing all of
its IO through standard DOS calls.

Has anyone experienced any kind of problem with PC-NFS and 386SX
machines, or had specific applications that seem to fail in this
configuration.  My suspisions are that PC-NFS may be having a problem
with the Expanded memory, why or how I have no idea.
-- 
-----------------------------------------------------------------------
  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
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

geertj@philica.ica.philips.nl (Geert Jan de Groot) (02/19/90)

In article <557@massey.ac.nz> GEustace@massey.ac.nz (Glen Eustace) writes:
>We make extensive use of Russ Nelson's Freemacs editor but have found
>that when editting files on network drives the machines hang when the
>file is saved.  This does not happen on any other type of machine and
>does not always happen on the 386SXs either.  The frequency of hangs is
>probably about 80% of saves.
>
>Russ has been very helpful at trying to help us solve this problem as we
>haven't found any other software which fails.  However, it is starting to
>look like the problem is not Freemacs but PC-NFS.  We run the BLIP option
>of PC-NFS all the time as an indication of network activity.  When one
>types the ^X^S, the BLIP blinks a couple of times then comes on solid -
>the machine is now hung.  Russ assures me that Freemacs is doing all of
>its IO through standard DOS calls.

I had a similar problem with an application using the PC-NFS programmer's
toolkit. After quite some experimenting, I discovered by accident that
my problem was caused by a stack overflow, causing the machine to crash.
You might try EXEMOD to increase the stack of Freemacs.
Apperently, PC-NFS uses quite some stack (seems reasonable for the amount
of work involved).
I don't know who is at fault in my situation, but since I changed the stacksize,
I don't have had a single crash, while I used to suffer one or 2 crashes per 
day!

Hope this helps,

Geert Jan


--8<--nip-nip---------------------------------------------------------------

Geert Jan de Groot,		Email: geertj@ica.philips.nl
Philips ICA,			       ..!hp4nl!philica!geertj
Room T-214,			Ham: PE1HZG 
Weisshausstrasse,		
5100 Aachen, West-Germany	"Programs are like waffles:
phone: +49 241 6003 714		you should always throw the first one out"
[Standard disclaimers apply]	 - Sutherland

GEustace@massey.ac.nz (Glen Eustace) (02/23/90)

As many may have noted on the net recently, we have purchased about 70
386SX PCs which are being used to equip a Computing Laboratory.  These
machines are networked to a DECStation 3100 as a File Server using
PC-NFS.

For those that have seen my questions about Russ Nelson's Freemacs editor
and PC-NFS on the above machines, you may be interested in current
progress.  The suggestion was made by another on the net that the problem
could be insufficient stack in Freemacs.  Russ has confirmed that the
version of Freemacs we are using does not have a Stack Segment and thus
can not be changed with EXEMOD.  The Stack is 256 Bytes.  This may not be
enough.  We have yet to try a version of Freemacs with a larger stack,
courtesy of Russ.

Anyway another question about PC-NFS and 386 machines.

We are playing with the Quarterdeck QEMM memory manager.  It suggests
that various device drivers can be loaded high.  What governs the choice
of suitable candidates.  Which of the PC-NFS drivers will run correctly
when loaded high, if any ?


-- 
-----------------------------------------------------------------------
  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
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (02/23/90)

Quoth GEustace@massey.ac.nz (Glen Eustace) (in <582@massey.ac.nz>):
#Anyway another question about PC-NFS and 386 machines.
#
#We are playing with the Quarterdeck QEMM memory manager.  It suggests
#that various device drivers can be loaded high.  What governs the choice
#of suitable candidates.  Which of the PC-NFS drivers will run correctly
#when loaded high, if any ?

My standard PC is an NEC Powermate Portable SX, a nice little 386SX
which, though a tad slow, has the most accessible slots in the business :-)

I occasionally run with QEMM386 to save space, using a CONFIG.SYS of
the following form:

BUFFERS = 20
SHELL=C:\COMMAND.COM /P /E:800
FILES=20
DEVICE=C:\NFS\SOCKDRV.SYS
DEVICE=C:\NFS\<link-level-driver>.SYS
DEVICE=\QEMM386\QEMM.SYS FRAME=NONE RAM
DEVICE=\QEMM386\LOADHI.SYS C:\NFS\PCNFS.SYS  /M /S /R0 /F16
DEVICE=\QEMM386\LOADHI.SYS C:\GAMES\NANSI.SYS
LASTDRIVE=V

Note that you cannot load the link level driver or SOCKDRV.SYS high; these
bugs will be addressed in a future release of PC-NFS. (I know why the link
level drivers won't work; I haven't yet worked out why SOCKDRV.SYS doesn't.)

I have encountered one obscure glitch with a third-party board driver
in this configuration, but apart from this things look pretty solid.

Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM)
-----------
News software that enforces a four-line .signature limit is responsible for
the fact that these postings just go on and on and on and seem to end in mid-

pcm@bby.oz (Paul C. McLeish) (02/23/90)

In article <1615@east.East.Sun.COM> geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:

   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

   Quoth GEustace@massey.ac.nz (Glen Eustace) (in <582@massey.ac.nz>):
   #We are playing with the Quarterdeck QEMM memory manager.  It suggests
   #that various device drivers can be loaded high.  What governs the choice
   #of suitable candidates.  Which of the PC-NFS drivers will run correctly
   #when loaded high, if any ?

   My standard PC is an NEC Powermate Portable SX, a nice little 386SX
   which, though a tad slow, has the most accessible slots in the business :-)

   I occasionally run with QEMM386 to save space, using a CONFIG.SYS of
   the following form:

   BUFFERS = 20
   SHELL=C:\COMMAND.COM /P /E:800
   FILES=20
   DEVICE=C:\NFS\SOCKDRV.SYS
   DEVICE=C:\NFS\<link-level-driver>.SYS
   DEVICE=\QEMM386\QEMM.SYS FRAME=NONE RAM
   DEVICE=\QEMM386\LOADHI.SYS C:\NFS\PCNFS.SYS  /M /S /R0 /F16
   DEVICE=\QEMM386\LOADHI.SYS C:\GAMES\NANSI.SYS
   LASTDRIVE=V

   Note that you cannot load the link level driver or SOCKDRV.SYS high; these
   bugs will be addressed in a future release of PC-NFS. (I know why the link
   level drivers won't work; I haven't yet worked out why SOCKDRV.SYS doesn't.)

   Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM)
   -----------

We use a various AT pc's, running Windows286, and PC-NFS.  Whilst
their are some limitations using this combination, we have found it to
be successful.  The only consistant problem occurs when copying files
from the fileserver to a PC (either 286 or 386), the file is copied but
with a size of 0K bytes.

That is until we introduced the 386SX and PC-NFS 3.01, at the same
time.  Then various problems surfaced with the SX's:
	1. 'COM in use', followed by 'Out of Memory' When trying to
	   execute applications from windows this error would occur,
	   at other times the same application would execute happily.
	2. 'Insufficient Disk Space' 
	   When attempting to copy or save files to the network
	   fileserver, this error occasionally appears.
The existing problem with file copying, has also continued to plague us.

Following various calls etc., we were advised that the position of the
lines in the config.sys was crucial (???).  Having tested some
combinations, we have found that the following will work, but with
limited occurences of 'Insufficient Disk Space'. Note that file copying
is still very iffy, and must be done twice to ensure validity.

shell=c:\command.com /p /e:200
buffers=5
FILES=20
LASTDRIVE=V
DEVICE=C:\NFS\PCNFS.SYS /f32 /r10 /l0 /i0
DEVICE=C:\NFS\WD8003E.SYS /i3 /mb000
device=c:\386max.sys norom ram=b000-b200 use=b200-b800 include=c400-e000 use=f500-f900 nolow frame=e000 resetkeyb
device=c:\386load.sys prgreg=1 prog=c:\desktop\dos\ansi.sys
device=c:\386load.sys prgreg=2 prog=c:\desktop\drivers\mouse.sys
DEVICE=c:\386load.sys prgreg=1 prog=C:\NFS\SOCKDRV.SYS
device=c:\386load.sys prgreg=1 size=13840 prog=c:\desktop\drivers\smartdrv.sys 128 /a

Moving the max and load requests to the top of the config.sys results
in an un-useable machine, due to the errors noted previously.

What gives????  Are we suffering from 386MAX, or could this be related
to loading SOCKDRV.SYS high ?  Should we try loading PCNFS.SYS high
instead of or as well as SOCKDRV.SYS ?

As you may have guessed, we are by no means expert in this area, and
have become tired of the suck-it-and-see approach, so any assistance
is greatly appreciated.















--
------------------------------------------------------------------------------
Paul McLeish, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: pcm@melba.bby.oz.au    non-MX: pcm%melba.bby.oz@uunet.uu.net
Uucp: {uunet,mnetor,pyramid,ubc-vision,ukc,mcvax,...}!munnari!melba.bby.oz!pcm
Phone: +61 3 614 8922
Fax: +61 3 614 8742

     "It takes 3 pigs with dermatitis to make one packet pork scratchings"
			Who Dares Wins

bryan@intvax.UUCP (Jon R Bryan) (02/23/90)

From article <582@massey.ac.nz>, by GEustace@massey.ac.nz (Glen Eustace):
> 
> We are playing with the Quarterdeck QEMM memory manager.  It suggests
> that various device drivers can be loaded high.  What governs the choice
> of suitable candidates.  Which of the PC-NFS drivers will run correctly
> when loaded high, if any ?
> 
I load PCNFS.SYS and VECIE6.SYS high with no problems.  I load
VECIE6.SYS with option /i2 so that it uses interrupt 2.  If I don't
change the interrupt then Telnet won't run from Desqview reliably.  It's
still dangerous to push Telnet to the background.  My experience has
been that it crashes the machine within a minute or so, and I assume the
problem is with the "keep-alive" ping from the net generating an
interrupt that Desqview can't handle.  Desqview doesn't like interrupts
unless they're from the COM ports.

-- 
Jon R. Bryan	<=>	bryan@intvax.UUCP
Sandia National Laboratories
Intelligent Machine Principles Division
Albuquerque, New Mexico

geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (02/25/90)

Try putting sockdrv.sys low. If it fixes it, let me know. As I said,
I'm still trying to figure out why I can't put this driver high.

Geoff

Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM)
-----------
News software that enforces a four-line .signature limit is responsible for
the fact that these postings just go on and on and on and seem to end in mid-

infotech@rupert.misemi (Ross Bannerman) (02/27/90)

In article <1615@east.East.Sun.COM> geoff@East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) writes:
>I occasionally run with QEMM386 to save space, using a CONFIG.SYS of
>the following form:
>DEVICE=C:\NFS\SOCKDRV.SYS
>DEVICE=C:\NFS\<link-level-driver>.SYS
>DEVICE=\QEMM386\QEMM.SYS FRAME=NONE RAM
>DEVICE=\QEMM386\LOADHI.SYS C:\NFS\PCNFS.SYS  /M /S /R0 /F16
>Note that you cannot load the link level driver or SOCKDRV.SYS high; these
>bugs will be addressed in a future release of PC-NFS. (I know why the link
>level drivers won't work; I haven't yet worked out why SOCKDRV.SYS doesn't.)
 
Using 386MAX (Qualitas s/w) you can indeed load the SOCKDRV.SYS into high
memory... Loading the ethernet card driver into high memory doesn't work,
but you can also load the PRT program into high memory using their 386load
utility... I can't use the PC NFS.sys in high memory because of lack of 
space... 386max maps ROMS in this area as well... One nice thing about 386max
is that you can tell it to stay away from your ethernet card shared memory
address...
 Email me if you want more details...
 We use ver 3.0.1 of PC-NFS... 
================================================================================
Ross Bannerman              |  uunet!mitel!infotech
Mitel Corp.                 +---------------------------------------------------
KANATA, Ont. Canada         | Insert standard legalese here....
================================================================LEAFS #1========