WIN/TCP gives panic doing ftp

[Thaddeus P. Floryan]

jim at syteke.be (Jim Sanchez) in <1792 at syteke.be> writes:

	I have had the WIN/TCP package and ethernet card for my 3b1 for
	about nine months now and it has had problems from day one.  I use
	it to transfer files from my DOS pc which runs FTP's TCP/IP package
	(version 2.03).  With fairly high probability when I try transfering
	files to/from the 3b1 I get a kernel panic - something about a NMI.
	This means a reboot and it pretty frustrating.  I have played around
	with the window values on the pc but going from 512 to 2048 doesn't
	seem to change anything.  Any ideas will be appreciated.  I have a
	combo card w/ram if that matters and use 3.51m version of unix.

MS-DOS vadanya.  :-)

Seriously, have you considered the possibilty the PC could be the culprit?
Most of the stuff in comp.protocols.tcp-ip and related newsgroups suggests
that PC-based Ethernet products suck dead bunnies through a straw.

You and I bought our Ethernet cards at the same time from the same source, and
I personally checked your card so I'm convinced your hardware is OK.  The ONLY
difference between your setup and mine is that I have 3B1s, Amiga, and some
other CT products on my net, and your net has a 3B1 and the PC.

HOWEVER: I did have a lot of problems at first (tossed the WIN/3B sendmail
crap due to excessive defunct processes) and ported some of the 4.3BSD
networking stuff over to replace the "stock" stuff, but there is one more
thing you should check: the /etc/lddrv/drivers file.  From my experience,
the "ether" MUST BE THE LAST ENTRY.  NO EXCEPTIONS.  My file is:

	lipc
	cmb
	[...]
	starlan
	voice
	ether

and the output of "/etc/lddrv/lddrv -s" is:

	 DEVNAME  ID  BLK CHAR  LINE   SIZE    ADDR     FLAGS
	    wind   0   -1    7   -1  0x9000   0x53000 ALLOC BOUND 
	    lipc   1   -1   -1   -1  0x7000  0x360000 ALLOC BOUND 
	     cmb   2   -1   -1   -1  0x3000   0x5c000 ALLOC BOUND 
			[...]
	 starlan   5   -1   11   -1 0x14000  0x3de000 ALLOC BOUND 
	   voice   6   -1   13   -1  0xa000  0x33e000 ALLOC BOUND 
	   ether   7   -1   14   -1 0x13000  0x348000 ALLOC BOUND 

Absolutely NO OTHER COMBINATION would work on my system.  I transfer over
1MB a day between systems over the Ethernet, and lookee here:

	thadlabs ksh 7432/7652> date
	Tue Feb 19 03:12:52 PST 1991
	thadlabs ksh 7432/7652> who -b
	   .       system boot  Nov 12 03:44
	thadlabs ksh 7432/7652> uptime
	up 98 days 23:36:52   booted Mon Nov 12 03:36:08 1990
	thadlabs ksh 7432/7652> ruptime
	thadlabs         up ??:??,     2 users,  load    0.06,    0.05,    0.00
	tlabs3        up  7+20:07,     0 users,  load    0.01,    0.00,    0.00
	tlabs4        up 19+31:23,     0 users,  load    0.00,    0.00,    0.00
	tlabs9        up 42+22:31,     0 users,  load    0.00,    0.00,    0.00

Sheesh, another bug in Wollongong software; I guess they never expected a
system could remain up so long.  I thought I first saw that "??:??" shortly
after the 90-day period but forgot about it 'til just now.  Sigh, guess I
gotta write my own ruptime (or find a 4.3BSD version).

Thad Floryan [ thad at btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]