Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!amdahl!nsc!voder!blia!ted From: ted@blia.BLI.COM (Ted Marshall) Newsgroups: comp.os.vms Subject: Results on: Ethernet software problems on LAVC systems Message-ID: <3596@blia.BLI.COM> Date: Mon, 9-Nov-87 13:56:13 EST Article-I.D.: blia.3596 Posted: Mon Nov 9 13:56:13 1987 Date-Received: Wed, 11-Nov-87 19:52:04 EST References: <3589@blia.BLI.COM> Organization: Britton Lee, Los Gatos, CA Lines: 61 Keywords: Ethernet, DEBNT, LAVC, SYSTEM-F-INSFMEM Summary: Looks like the solution is found In article <3589@blia.BLI.COM>, I wrote about a problem installing our Ethernet software on an 8350 already running LAVC, LAT and DECnet through the same DEBNT. Already, I have received two very meaty replies and it looks like the problem is solved. Bob Craig from DEC DSM Technical Programs Group writes: >I believe the problem you are having with the 8350 BI Ethernet >controller returning a SS$_INSFMEM (Insufficient Dynamic Memory) >error is due to a newly discovered bug in the controller. A patch has >been issued, and you should contact your local DEC office to have it >installed. Today, I called DEC TSC and confirmed the existance of the patch. It is titled: "ETDRIVER patch for insufficient dynamic memory and/or no I/O channels available errors". As Bob wrote, people who need this patch should contact their local DEC office. I have advised my customer to do this. I will let the net know if this fixes the problem. Also, a bit of trivia: the ETDRIVER, though shipped with VMS, is maintained by the DECnet group. I descovered this because my site accedentally let the DECnet liscense lapse on the machine whose access number I was calling on (soon to be corrected) and so TSC was balking on giving the patch to me. Now this is all fine and good, but there still may be a problem, because Jerry Toporek of Network Research Corp. <...ncrvax!minnie!jt> also wrote: >If you haven't gotten an explanation yet, read this sitting down, it's going >to make you sick. > >We went through this with our first DEBNT customer some time ago. Fortunately, >he had good connections at DEC, so we got decent support. > >It seems that the ETDRIVER allocates a fixed number of buffers to be shared >amongst all clients. I don't remember the number, and don't have 4.5 fiche, >but I do remember that after loading up on DECnet, LAT, etc., there were >only TWO buffers left for us. This was too bad, since we were trying to >register for three protocols. If you are trying to get just XNS, you may >be able to squeeze in using the NMA$C_PCLI_BFN buffer count specifier. Our >customer had to get a patch from DEC to change the number of buffers to >ET will get. That worked fine, except that if we requested any more than >four buffers, the request would succeed, but no data would ever flow. It >seems that the ETDRIVER has some problem allowing anyone, other than DECnet >of course, more than four buffers. > >I should point out that none of this is first-hand, but after adding the >provision to specify the number of buffer we want, we have been able to >successfully get going at a large number of ET sites. Another disclaimer: >some sites never seemed to have this problem at all. I wonder if it is >fixed in a newer version of the ETDRIVER, perhaps. I suspect but cannot be sure that the problem Jerry saw was actually the fixed by the patch Bob reported. Anyway, if the patch does not solve the problem, I will explore this some more. Again, thanks to everyone. -- Ted Marshall ...!ucbvax!mtxinu!blia!ted mtxinu!blia!ted@Berkeley.EDU Britton Lee, Inc., 14600 Winchester Blvd, Los Gatos, Ca 95030 (408)378-7000 The opinions expressed above are those of the poster and not his employer.