DOBEIRNE@IRLEARN.BITNET (Dermot O'Beirne) (04/24/89)
Thanks to all who have helped and commented on the use of packet drivers, especially in relation to coexisting wit Novell. In particular John's(Proteon) explanation of ECONFIG and Novells cock-up. I had just waded through setting it all up and coexisting the NCSA stuff with Novell (the BYU drivers). Just by the way, the ECONFIG stuff, is reasonably documented in the Netware for VMS: Managers Guide which I borrowed from our distributor. BUT there is problem which seems to be related to a conflict within the packet driver. When I logon to Novell I can Telnet and FTP OK to and from the Novell server. But when I try to copy from my hard disk and sometimes floppy, part of the file is copied to the server drive and then everything hangs. I thought I had discovered enough about I/O, DMA etc but this problem looks exactly like I have seen before with IRQ conflicts. Is this likely and is there a way around this? It happens with the 3c501, wd8003 and NI5010 cards, and in one case a CGA screen went into a multi-coloured flip? I am keen to get the FTP software to work with Novell. James: should I get a copy of the FTP software for the packet driver to achieve this best and most flexibly; and what is the status of FTPs NFS, and other products talking through the packet driver? Do the packet drivers come with the software? Getting all these to work together is not trivial and if anyone wants to contact me as to how we even got this far please do. Thanks, Dermot O'Beirne Computer Centre UCD, Dublin
jbvb@VAX.FTP.COM (James Van Bokkelen) (04/25/89)
I haven't tried to use the BYU Netware with the Clarkson drivers myself, since we don't use Netware in-house. We've used the Clarkson drivers with PC/TCP quite a bit, and they seem to work fine (modulo the MTU problem in the NI5210 as it was first released). The notable difference between NCSA FTP and DOS COPY is probably the size of the data blocks written: NCSA will be doing about 4K, and COPY will use as much as it can (65K or more?). It sounds like the problem is related to the write size and/or the rate at which the data is presented. Thus, the first place I'd look is at re-entrancy in the packet driver; what happens if it is re-entered from a hardware interrupt? Can it stand being asked to send a packet while it is in the receiver upcall? Can it handle the case where the protocol stack has no buffer for an incoming packet? LANWatch (or NETWATCH or another protocol monitor) and a hardware debugger would be useful here, as would some knowledge of the internal structure of Netware. Has NCSA been loaded before the crashes happen? Try it without running NCSA at all... Has anyone else seen these problems? Kelly? James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
nelson@sun.soe.clarkson.edu (Russ Nelson) (04/28/89)
In article <8904251438.AA00802@vax.ftp.com> jbvb@VAX.FTP.COM (James Van Bokkelen) writes:
... (modulo the MTU problem in the NI5210 as it was first released).
Which will be fixed with the next release thanks to Brad Clements.
Thus, the first place I'd look is at re-entrancy in the packet
driver; what happens if it is re-entered from a hardware interrupt?
Can't happen -- interrupts are held off.
Can it stand being asked to send a packet while it is in the
receiver upcall?
I just examined the code and the packet interrupt servicer seems to be
re-entrant.
Can it handle the case where the protocol stack has no buffer for
an incoming packet?
I'm pretty sure of this. Karn's code lets you specify how many buffers
are to be used, and shelling to DOS will hold off packet processing so
that they pile up, and sooner rather than later it will refuse packets.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
S&Ls get bailouts and that's okay, but poor people get welfare and that's not.