Path: utzoo!utgpu!watserv1!watmath!att!rutgers!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!cwlim!ernie From: ernie@cwlim.CWRU.EDU (Ernie L. Ellenberger) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: SU-PC/IP (Was: Re: Where can I get the PCIP spec?) Summary: SU-PC/IP lockups eliminated Message-ID: <1990Jul17.011117.13081@usenet.ins.cwru.edu> Date: 17 Jul 90 01:11:17 GMT References: <1990Jul7.035507.23173@usenet.ins.cwru.edu> <1990Jul15.064627.17824@midway.uchicago.edu> Sender: news@usenet.ins.cwru.edu Reply-To: ernie@po.CWRU.Edu Organization: Case Western Reserve University, Information Network Services Lines: 36 In article <1990Jul15.064627.17824@midway.uchicago.edu> cjdb@midway.uchicago.edu (Charles Blair) writes: >>[SU-PC/IP info...] >> >My experience with this product is that it inevitably hangs the >machine if you use it long enough in a session (both its ftp and >telnet implementations). Others at the University of Chicago have had >this experience (disclaimer: I am not speaking as a representative of >the University, but as an end-user only). SU-PC/IP's well-known lock up problem seems to have been cured by the replacement of Stanford's Ethernet driver with a packet driver interface. I used it all last week to program a UNIX box and had no hang ups. This morning I set up a PC with Telnet reading an infinite loop of cat jobs and sleeps; it's been running for eight hours so far. There were also some questionable operations in the SU-PC/IP code that we fixed, e.g. unlinking a file before closing it (ftp) and failing to set binary mode in a write to the configuration device driver (mh). > I should point out that Stanford's documentation says >that one shouldn't run their product with any TSR's in memory -- in >this day and age that's an unreasonable requirement. I would say that _no_ TSR's is either overprotective or a requirement of the original Ethernet driver. I'm able to run the TSR's I normally use -- ced, filec, ipx/net3, and of course packet drivers -- but there probably are many TSR's that don't coexist. Loading order is often important with TSR's; TCPIP loads and unloads fine when loaded _after_ Novell drivers, but hangs the system if it's given an unload command after being loaded _before_ Novell. (there's gotta be some way to turn that into a Feature...) This is rather obscure and doesn't happen in the midst of a Telnet or FTP session, however. -Ernie (ernie@cwlim.ins.cwru.edu) #include