Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!VAX.FTP.COM!jbvb
From: jbvb@VAX.FTP.COM (James Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: TCP/IP
Message-ID: <8808021423.AA25226@vax.ftp.com>
Date: 2 Aug 88 14:23:24 GMT
References: <880730-104324-713@Xerox>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 27


   Date: 30 Jul 88 13:43:14 EDT (Saturday)
   From: marty <Leisner.Henr@xerox.com>

   I've noticed the KA9Q package doesn't restore the ethernet interrupt
   vector when it exits.

   So after running KA9Q if I do anything on the XNS net, the interrupt
   vectors to KA9Qs old space in ram and barfs big time.


Whether you can do this or not depends a great deal on the network card in
use.  With PC/TCP, we seem to be able to get away with saving the old vector
and restoring it on exit (3+ survives it) with the 3C501 and 3C503.  We can't
with the 3C505 or the 3C523.  On cards like the 3C501, where there is little
on-board state information, it is relatively likely that this will work.
That it works on the 3C503 is perhaps an indication of 3+'s willingness to
reset the card when the on-board state is changed.  Both the 3C523 and the
3C505 have even more on-board state, which gets changes when we start up
(and we can't save/restore it).

This is the kind of situation that our Packet Driver spec is meant to deal
with - two packages which both want to use the same interface.  Phil has
a KA9Q which uses it, but you'd need the XNS vendor's attention to make
their code support it as well.

James VanBokkelen
FTP Software Inc.