Xref: utzoo comp.protocols.tcp-ip.ibmpc:1563 comp.protocols.nfs:335
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!texsun!newstop!east!hinode!geoff
From: geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs
Subject: Re: NFS Support for DOS
Message-ID: <727@east.East.Sun.COM>
Date: 21 Aug 89 15:15:39 GMT
References: <606@UALTAVM.BITNET> <409@datran2.uunet> <26558@amdcad.AMD.COM> <653@east.East.Sun.COM> <4554@uhccux.uhcc.hawaii.edu> <457@wet.UUCP>
Sender: news@east.East.Sun.COM
Reply-To: geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Followup-To: comp.protocols.tcp-ip.ibmpc
Organization: Sun Microsystems, Billerica MA
Lines: 23

In article <457@wet.UUCP> epsilon@wet.UUCP (Eric P. Scott) writes:
>[....] PC-NFS's 3C503
>driver will not run when I do this; it wants shared memory
>disabled.  [...]  Why does PC-NFS insist on an inefficient operating mode?

The choice was 3Com's, not ours. In PC-NFS 3.0, we added support for the
3C503, 3C523 and 3C505 cards. Rather than doing drivers for each one, we
wrote a single driver to interface to 3Com's "vector" interface (one of the
precursors to today's NDIS) and obtained vector drivers for each
card from 3Com. In theory, this allowed PC-NFS to coexist with 3+
and share the board. In practice, out-of-sync software revisions by
Sun and 3Com have made this a somewhat hit-or-miss affair, and in PC-NFS
3.0.1 support for coexistence is officially withdrawn pending further
study. 

I have no idea why 3Com's software uses the 3C503 with shared memory
disabled. Maybe it was to minimize software differences between the
501, 503, 505 and 523.

Geoff Arnold,                              Internet: geoff@East.Sun.COM
PCDS Group, Sun Microsystems Inc.
---------------------------------------------------------------------------
My disclaimer is available via anonymous FTP as a compressed tar archive....